MongoDB高效存储方案及客户关联文档集合结构选型咨询

Hey there! Let's tackle your MongoDB questions one by one—first covering general best practices for efficient storage, then diving into your specific schema design dilemma.

Here are key practices to optimize your MongoDB data storage:

• Align your model with access patterns first: MongoDB’s strength lies in matching how your app actually uses data. Instead of forcing relational-style normalization, start by listing your most frequent queries and updates. For example, if you almost always pull a customer and their related docs together, nested structures might make sense; if you often query docs independently, separate collections are better.
• Use indexes strategically: Indexes speed up queries drastically, but each one adds overhead to writes. Create indexes only for fields you regularly filter or sort on—like customerId, documentDate, or companyName. You can create an index with:

  db.collection.createIndex({ targetField: 1 }) // 1 for ascending order
  

• Avoid over-nesting: While nesting is powerful, deep arrays or large embedded documents can hit MongoDB’s 16MB document limit and slow down targeted updates. If a sub-dataset needs to be queried/updated on its own, or could grow large over time, split it into a separate collection.
• Leverage sharding for large datasets: When your data scales to millions of records, sharding distributes data across multiple nodes to boost read/write performance and storage capacity. Pick a shard key that aligns with your common queries (like customerId for your use case).
• Enable data compression: MongoDB’s WiredTiger storage engine supports compression (snappy, zlib, etc.) which reduces disk usage and improves I/O performance. You can configure it when creating a collection:

  db.createCollection("documents", {
    storageEngine: { wiredTiger: { configString: "block_compressor=snappy" } }
  })
  

• Implement read-write separation: If your app has way more reads than writes, use a replica set to offload read requests to secondary nodes, easing the load on your primary write node.

Let’s break down your specific scenario: ABC Accounting (a Customer) has linked Users (already in a separate collection), owns multiple Companies, and each Company has its own Documents. Here’s how the two options stack up:

方案A：将Companies和Documents作为数组嵌套在Customers集合 #

Pros: #

• Single query for full customer data: Fetching a customer’s entire profile (including all companies and docs) only needs one findOne call, no joins required.
• No orphaned data: Since everything is embedded, deleting a customer automatically removes their associated companies and docs.

Cons: #

• Document size limits: If a customer has dozens of companies or hundreds/thousands of docs, you’ll quickly hit MongoDB’s 16MB cap, making it impossible to add more data.
• Poor query flexibility: Trying to filter docs for a specific company (e.g., "find all 2024 audit docs for ABC’s XYZ Company") would require fetching the entire customer document and filtering the array manually—slow and unindexable.
• Concurrent update conflicts: Multiple users editing different companies under the same customer would trigger document-level locks, causing delays.

方案B：单独创建Companies和Documents集合，通过Customer ID关联 #

Pros: #

• Scalable document sizes: Each company and doc is a small, independent document, so you never hit the 16MB limit even as data grows.
• Fast, targeted queries: You can create indexes on companies.customerId, documents.companyId, documents.createDate, etc., making complex queries (like filtering docs by date or type) lightning fast. For example:

  db.documents.find({
    companyId: ObjectId("xyz123"),
    createDate: { $gte: new Date("2024-01-01") }
  })
  

• Better concurrency: Updating a single company or doc only locks that specific document, so multiple users can make changes without blocking each other.
• Future-proof scalability: If you later need to add relationships (e.g., linking companies to vendors) or add permissions to docs, modifying separate collections is far easier than reworking nested structures.

My Recommendation: Go with方案B #

Given your use case—accounting firms likely have large numbers of documents that need to be filtered by company, date, or type—separate collections are the clear choice. Plus, since you’re already using a separate Users collection linked by customerId, keeping Companies and Documents consistent with this pattern will make your schema easier to understand and maintain for your team.

The only time方案A might make sense is if every customer has very few companies and docs (like 2-3 total), but for long-term growth,方案B is much more adaptable.

内容的提问来源于stack exchange，提问作者Ozan