【问题标题】:120 mongodb collections vs single collection - which one is more efficient?120 个 mongodb 集合与单个集合 - 哪个更有效?
【发布时间】: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


【解决方案1】:

单个分片集合

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

在这种情况下,我认为您最好使用单个集合并利用 MongoDB 的 auto-sharding 功能根据需要将数据和工作负载分配到多个服务器。多个集合仍然是一种有效的方法,但与利用核心 MongoDB 功能相比,它不必要地使您的应用程序代码和部署复杂化。假设您是choose a good shard key,您的数据将在您的分片之间自动平衡。

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

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

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

固定数量的集合(原始答案)

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

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

使用单独集合的动机是:

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

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

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

  • MongoDB 2.4(和 2.2)当前具有数据库级别的写入锁定粒度。在实践中,这对于绝大多数用例来说都不是问题,但是如果需要,多个集合可以让您更轻松地将高活动集合移动到单独的数据库中。

  • 更进一步说......

【讨论】:

    【解决方案2】:

    这里的主要问题是,如果您将集合分离到同一个数据库中,那么在当前 MongoDB 版本中您将获得非常少的性能。要在单个集合设置上获得任何类型的额外性能,您需要将集合移到单独的数据库中,然后您将有操作开销来判断您应该查询的数据库等。

    所以是的,您可以轻松获得 120 个集合,但是,您目前不会真正获得任何东西,因为:https://jira.mongodb.org/browse/SERVER-1240 没有被实施(很快)。

    在一个集合中容纳数十亿个文档还不错。我认为即使您将其存放在单独的集合中,它也可能不会在单个服务器上,就像对单个集合进行分片一样,因此在这种情况下,由于多服务器设置而导致的任何速度降低也无关紧要。

    在我个人看来,使用单个集合更容易处理所有事情。

    【讨论】:

    • 好的,我明白了。谢谢,我会去单一收藏。多数据库方法处理起来会非常复杂。
    • @user2297996:您的问题是关于多个数据库还是多个集合?到目前为止,答案与单一与多重收集的好处有关,但使用单一数据库(至少一开始是这样)。
    • @user2297996 Stennies 的回答提供了一些我实际上没有考虑到的好观点,有些可能适用于您的情况。
    猜你喜欢
    • 2012-11-27
    • 2012-07-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-03-06
    • 1970-01-01
    相关资源
    最近更新 更多