【发布时间】:2013-04-12 12:26:44
【问题描述】:
我是 mongodb 的新手,我在 DB Schema 设计方面面临两难:
我应该创建一个集合还是将我的数据放入多个集合中(我想我们可以称之为这些类别)。
现在我知道有人问过很多这样的问题,但我相信我的情况有所不同,原因有两个:
- 如果我要收集很多系列,我将不得不创建大约 120 个,仅此而已。这在未来不会增长。
- 我知道我永远不需要查询或插入多个集合。我总是只需要查询一个,因为集合 X 中的文档与存储在其他集合中的任何文档都不相关。文档可能包含对数据库其他部分的引用(例如 userId 等)。
所以我的问题是:这 120 个集合能否提高查询性能?在我的情况下,这是一个有用的优化吗?
或者我应该只使用单个集合 + 分片?
每个集合都应包含数百万个文档。如果只使用一个,它将存储数十亿个文档。
提前致谢!
------- 编辑:
感谢您的精彩回答。
事实上,120 个集合只是一个自制的限制,并不是真正的最优:
集合中的数据与网络发布者有关。可能有数百万个(任何网站都可以加入)。
我想理想的情况是我可以为每个发布者创建一个集合(仅保存他们的数据)。但显然,由于 mongo 的限制,这是不可能的。
所以我想出了固定数量的集合的想法,以至少以某种方式分发数据。比如:集合“A_XX”将保存名称以“A”开头的发布者的 XX 平台相关数据。等等。我们只支持其中的几个平台,所以 120 个集合应该绰绰有余。
在另一个网站上,有人建议使用多个数据库而不是多个集合。但这意味着开销,然后我将不得不使用/管理许多不同的连接。
您对此有何看法?有更好的解决方案吗?
抱歉,我最初的问题不够具体。
提前致谢
【问题讨论】:
-
文档在此页面上讨论它:docs.mongodb.org/manual/core/data-modeling 在标题“大量收藏”下。您应该考虑您可能需要的查询和索引类型的影响。例如,您是否需要运行非索引覆盖的查询?或者 MapReduce... 有很多因素使这个问题难以充分回答。
-
@WiredPrairie 我不认为 120 并且永远不会增长真的算作一个“大量”的集合,而且如果你仔细阅读这个问题,他会考虑他的查询和索引
-
@Sammaye - 问题中的任何地方都没有使用“索引”这个词。 :)
标签: mongodb collections sharding