120个mongodb系列与单个系列 - 哪一个更有效？

Question

我是mongodb的新手,我的DB Schema设计面临两难选择:

我应该创建一个单独的集合还是将我的数据放入多个集合中(我想可以称之为这些类别).

现在我知道很多这样的问题已被提出,但我认为我的情况有所不同有两个原因:

• 如果我去了很多收藏品,我将不得不创造大约120个,就是这样.这将不会在未来增长.
• 我知道我永远不需要查询或插入多个集合.我将始终只查询一个,因为集合X中的文档与存储在其他集合中的任何文档无关.文档可以保存对DB的其他部分的引用(如userId等).

所以我的问题是:120个集合可以提高查询性能吗？在我的情况下,这是一个有用的优化吗？

或者我应该去单一收集+分片？

预计每个集合都会保存数百万份文档.如果只使用一个,它将存储数十亿个文档.

提前致谢!

-------编辑:

谢谢你的答案.

事实上,120个系列只是一个自制限制,它不是真正的最佳:

集合中的数据与Web发布者相关.可能有数百万(任何网站都可以加入).

我想理想的情况是,如果我可以为每个发布者创建一个集合(仅保存他们的数据).但显然,由于mongo的限制,这是不可能的.

所以我提出了一个固定数量的集合的想法,至少以某种方式分发数据.喜欢:集合"A_XX"将为名称以"A"开头的出版商提供XX平台相关数据等.我们只支持其中的一些平台,因此120个集合应该绰绰有余.

在另一个网站上有人建议使用许多数据库而不是许多集合.但这意味着开销,然后我将不得不使用/管理许多不同的连接.

你怎么看待这件事？有更好的解决方案吗？

很抱歉我原来的问题不够具体.

提前致谢

Answer 1

单一碎片收藏

该问题的编辑版本使实际需求更加清晰:您有一个可能会变得非常大的集合,并且您需要一种方法来对数据进行分区.人工收集限制是您自己计划的分区方案.

在这种情况下,我认为您最好使用单个集合并利用MongoDB的自动分片功能,根据需要将数据和工作负载分发到多个服务器.多个集合仍然是一种有效的方法,但与利用核心MongoDB功能相比,不必要地使应用程序代码和部署复杂化.假设您选择了一个好的分片键,您的数据将在分片中自动平衡.

你不必立即碎片; 您可以推迟决定,直到您看到您的工作负载实际上需要更多的写入规模(但在您需要时知道该选项).在决定进行分片之前,您还有其他选择,例如升级服务器(特别是磁盘和内存)以更好地支持您的工作负载.相反,您不希望等到系统在分片之前被工作负载压碎,因此您肯定需要监控增长.我建议使用10gen提供的免费MongoDB监控服务(MMS).

在另一个网站上有人建议使用许多数据库而不是许多集合.但这意味着开销,然后我将不得不使用/管理许多不同的连接.

多个数据库将显着增加管理开销,并且可能过度使用并且可能对您的用例有害.存储在数据库级别分配,因此120个数据库比具有120个集合的单个数据库消耗更多空间.

固定数量的收藏(原始答案)

如果您可以计划固定数量的集合(根据您的原始问题描述120),我认为采用这种方法而不是使用单一集合更有意义.

注意:下面的设计注意事项仍然适用,但由于问题已更新以阐明多个集合是一个尝试的分区方案,因此对单个集合进行分片将是一种更直接的方法.

使用单独收集的动机是:

• 单个大型集合的文档可能必须包含一些集合子类型的指示,可能需要将其添加到多个索引中,并且可能会显着增加索引大小.对于单独的集合,子类型已隐含在集合名称空间中.

• 在集合级别启用了分片.单个大型集合仅为您提供"全有或全无"方法,而单个集合允许您控制需要分片的数据子集并选择更合适的分片键.

• 您可以使用compactto命令对单个集合进行碎片整理. 注意: compact是阻塞操作,因此HA生产环境的正常建议是部署副本集并使用滚动维护(即先压缩辅助节点,然后逐步压缩并压缩主节点).

• MongoDB 2.4(和2.2)目前具有数据库级写锁定粒度.实际上,对于绝大多数用例而言,这并未证明是一个问题,但是如果需要,多个集合将允许您更轻松地将高活动集合移动到单独的数据库中.

• 继上一点之后..如果您将数据放在单独的集合中,这些将能够利用集合级锁定的未来改进(请参阅MongoDB Jira问题跟踪器中的SERVER-1240).