Table of Contents
🌏 中文版
MongoDB stores BSON documents in collections. Nested objects and arrays can mirror application objects and colocate data read together. This is a modeling choice, not an absence of schema: validation, indexes, document size, update frequency, and ownership boundaries still require design.
Embed or reference is the central question
Embed data that is read together, shares a lifecycle, and remains bounded; one document then has atomic writes. Reference entities that are shared, grow without bounds, or update independently. Embedding every relationship creates duplication and oversized documents. Referencing everything rebuilds relational joins through round trips or aggregation pipelines.
MongoDB supports multi-document transactions, but the documentation notes their performance cost and requires a replica set or sharded cluster. Transactions are an escape hatch, not a substitute for domain boundaries. Queries must also match index prefixes; flexible queries without suitable indexes become collection scans.
The hard part of sharding is the shard key
Replica sets provide availability; sharding distributes collections across machines. The shard key controls distribution, targeted queries, and write hotspots. Queries without it may scatter across all shards. Resharding is possible, but not a free correction. A managed replica set is simpler until horizontal partitioning is genuinely necessary.
Selection boundary
Choose MongoDB for aggregate-oriented products with evolving nested data and a useful MongoDB ecosystem. PostgreSQL or MySQL is usually more direct for extensive cross-entity constraints, join-heavy reporting, or standard SQL interoperability. DuckDB fits local analytics. AI emits JSON naturally but can also invent unvalidated fields; constrain input at both API and database layers, then test indexes with real query distributions.
References
Loading...