【问题标题】:MongoDb Database vs CollectionMongoDb 数据库与集合
【发布时间】:2012-12-05 22:40:18
【问题描述】:

我正在设计一个使用 MongoDb(64 位版本)的系统来处理大量用户(大约 100,000)并且每个用户将拥有大量数据(大约 100 万条记录)。

最好的设计策略是什么?

  1. 转储单个集合中的所有记录

  2. 为每个用户创建一个集合

  3. 为每个用户建立一个数据库。

非常感谢,

【问题讨论】:

  • 从数据库架构的角度来看,我建议使用单个集合,但我不确定当您拥有数百 十亿 条记录时它们是否仍然可以很好地扩展.

标签: mongodb


【解决方案1】:

关于每个用户的收藏:

默认配置下,MongoDB 的集合限制为 12k。您可以使用 --nssize 增加它的大小,但它不是无限的。 而且您必须将索引计入这 12k 中。 (检查 mongo 文档中的“命名空间”概念)。

关于每个用户的数据库:

从模型的角度来看,这非常奇怪。 对于技术而言,mongo 没有限制,但您可能对文件描述符有限制(来自您的操作系统/设置的限制)。

正如@Rohit 所说,最后两个不好。 也许你应该更多地解释你的情况。 也许您可以将用户分成不同的集合(例如:每个名称的第一个字母等,或公司的每个服务......)。 而且,当然要使用分片

编辑:也许 MongoDb 不是您用例的最佳数据库。

【讨论】:

    【解决方案2】:

    因此,您正在查看大约 1000 亿条记录(100 万条记录 * 100,000 个用户)的区域。

    处理大量数据的首选方法是创建一个分片集群,将数据拆分到多个服务器上,这些服务器通过 mongo 客户端呈现为单个逻辑单元。

    因此,您的问题的答案是将所有记录放在一个分片集合中。

    集群所需的分片数量和配置与数据的大小以及读写的数量和分布等其他因素有关。这些问题的答案可能非常适合您的独特情况,所以我不会试图猜测它们。

    我可能会首先确定您有多少分片以及有多少机器可用于在这么多机器的集群上设置和测试系统。根据性能,您可以决定集群中需要更多还是更少的分片

    【讨论】:

    • 虽然分片架构在这种情况下肯定是相关的,但您的帖子没有解决 OP 的问题,即是使用一个集合、多个集合还是多个数据库。
    • 啊,是的,选项 2 和 3 对我来说太反直觉了,以至于我忘了明确说明您应该将其放入单个集合和分片中
    • @chrisbunney 仅出于安全和简化访问控制管理的目的而使用“每个用户的数据库或集合”模式,您的 2 便士是多少?
    【解决方案3】:

    所以您要为 10 万用户寻找总共 100,000,000 条详细记录?

    很多人似乎不明白的是,MongoDB 擅长水平扩展。水平扩展通常被归类为跨大型集群中的许多(许多)服务器扩展庞大的单个数据集合。

    因此,如果您对公共数据使用单个集合(即一个名为 user 的集合和一个名为 detail 的集合),那么您已经适合 MongoDB 的核心用途和构建。

    正如其他人所提到的,MongoDB 并不擅长在许多集合中垂直扩展。它一开始就有一个 nssize 限制,尽管由于索引大小实际上估计有 12K 个初始集合,但您的数据库中可能只有 5K 个集合。

    因此,每个用户的集合根本不可行。它将违背其核心原则使用 MongoDB。

    每个用户拥有一个数据库与每个用户拥有单个集合涉及相同的问题,甚至可能更多。

    我从来没有遇到过有人无法在优化的设置上将 MongoDB 扩展到数十亿甚至接近 100 亿(甚至更多),但是,我不明白为什么它不能;毕竟 Facebook 能够让 MySQL 扩展到每个用户上千亿的规模(跨越 32K+ 分片),并且两个数据库之间的分片概念是相似的。

    所以这样做的理论和可能性是存在的。这一切都是关于选择正确的架构和分片概念和密钥(以及服务器和网络等等等)。

    如果您遇到问题,您可以拆分存档集合,或从主集合中删除项目,但我认为这太过分了,相反,您希望确保 MongoDB 知道您庞大数据集的每个部分的位置主节点上的任何给定时间点并确保此数据始终是热数据,这样不执行全局和分散 OP 的查询应该非常快。

    【讨论】:

      猜你喜欢
      • 2014-02-08
      • 2013-04-18
      • 2015-12-25
      • 1970-01-01
      • 2017-12-04
      • 2017-01-11
      • 1970-01-01
      • 1970-01-01
      • 2014-05-27
      相关资源
      最近更新 更多