开发电商平台遇文档大小/集合数量限制，该如何处理？

先纠正你的核心误解 #

• 你提到的「把所有商品存入单个文档」「每个商品创建新集合」都是错误的设计思路，完全不符合文档型数据库的使用规范。正确的做法是：每个商品作为独立的文档，全部存入同一个products集合。

关于MongoDB的限制你无需担心 #

• 文档20MB限制：单个商品的元数据（标题、描述、价格、库存、卖家ID等）通常只有几KB到几十KB，远达不到20MB的上限。如果商品包含图片、视频这类大文件，业内都不会存在数据库里，而是把文件存到对象存储服务，数据库文档只保留文件的访问URL。
• 集合数量1000个限制：这个是早期MongoDB版本的旧限制，现在新版本支持的集合数量远多于1000。就算按旧限制算，电商平台一般只需要products、users、orders、categories、recommendations等十几个集合，完全不会触及上限。

高并发写入的应对方案（对应eBay的30万次/秒写入） #

如果平台需要支撑极高的写入并发，业内常规做法是：

• 采用MongoDB分片集群：把products集合分片到多个数据库节点，分散写入压力，实现横向扩展存储和处理能力。
• 优化索引：针对常用查询维度（比如卖家ID、商品分类、创建时间）建立索引，保证写入和查询的效率。
• 引入消息队列缓冲：用Kafka、RabbitMQ这类工具缓冲瞬间的高并发写入请求，避免直接打崩数据库，实现削峰填谷。
• 热点数据缓存：对访问量极高的商品，用Redis做缓存，减少数据库的读写次数。

业内标准的商品存储架构 #

1. 核心商品元数据：每个商品一个文档，存入products集合，文档结构示例：

{
  "_id": "商品唯一ID",
  "seller_id": "卖家用户ID",
  "title": "商品标题",
  "description": "商品描述",
  "price": 99.99,
  "stock": 100,
  "category_id": "分类ID",
  "image_urls": ["https://xxx.com/img1.jpg", "https://xxx.com/img2.jpg"],
  "create_time": ISODate("2024-05-20T10:00:00Z")
}

2. 大文件存储：商品的图片、视频等大文件存对象存储，仅在数据库文档中保留访问链接。
3. 关联数据处理：用户的商品、分类下的商品等关联关系，通过查询条件（比如find({seller_id: "xxx"})）结合索引来快速获取，不需要嵌套在单个文档里。

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