MongoDB高性能设计咨询：架构选型与查询优化

回答 #

1. 架构选择与最佳实践

不推荐全嵌套架构，因为remarks（最多10万条/房间）和discussions（无限增长）会导致房间/酒店文档体积迅速超过MongoDB单个文档16MB的限制，且大文档的查询、更新效率极低。

扁平架构本身可行，你之前的性能问题大概率是索引缺失或查询逻辑不合理导致的。推荐采用混合架构，结合查询需求做针对性设计：

• 将hotels、rooms（以及resorts/apartments、campings对应单元）设为独立集合，存储主体/单元的核心属性；
• remarks和discussions设为独立集合，通过roomId/apartmentId、userId做手动关联（直接存储对应文档的_id即可，无需使用DBRef）；
• 针对核心查询“查找带特定remarks的房间所属酒店”，给remarks集合建立复合索引，比如{content: 1, roomId: 1}（可根据实际查询条件调整），确保能快速筛选出符合条件的roomId；
• 给rooms集合的hotelId字段建立索引，让从roomId映射到hotelId的查询更高效；
• 如果高频查询某个用户对房间的remarks，可以给remarks集合添加{userId: 1, roomId: 1}的复合索引。

核心原则是数据跟着查询走：优先优化你最常用的查询路径，避免为了“范式化”牺牲查询性能。

2. 最大化查询速度的最佳实践

优先选择单次请求通过聚合管道获取所需数据，而非分多请求在Python端拼接，原因如下：

• 聚合管道在数据库端执行，减少了客户端与数据库之间的网络IO开销；
• 数据库端的聚合操作可以利用索引优化，比客户端拼接效率高得多。

具体优化手段：

• 索引优先：所有查询、聚合中用到的过滤字段、关联字段都要建立合适的索引，用db.collection.explain().aggregate(...)检查聚合计划，确保索引被正确使用；
• 先过滤再关联：在聚合管道中先通过$match过滤掉不需要的数据，再执行$lookup关联，减少关联的数据量；
• 只返回需要的字段：用$project剔除不需要的字段，减少数据传输体积；
• 避免大文档操作：绝不把无限增长的内容（比如discussions）嵌套到父文档中，防止查询时加载冗余数据；
• 缓存高频查询结果：对于访问量极高的固定查询（比如热门酒店列表），可以用Redis或MongoDB的TTL索引做缓存，减少数据库查询压力；
• 分片扩容：如果未来数据量持续增长（比如rooms突破千万级），可以考虑按hotelId或地理位置（如果有相关需求）对集合分片，分散查询负载。

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