我需要将 66 亿个二元组加载到一个集合中，但我找不到任何有关执行此操作的最佳方法的信息。
将这么多文档加载到单个主键索引上需要很长时间，但据我所知，mongo 不支持分区？
分片有用吗？我是否应该尝试将数据集拆分为多个集合并将该逻辑构建到我的应用程序中？
【问题讨论】：
标签： mongodb
很难说最佳的批量插入是什么——这部分取决于您插入的对象的大小和其他不可估量的因素。您可以尝试几个范围，看看什么可以为您提供最佳性能。作为替代方案，有些人喜欢使用 mongoimport，它非常快，但您的导入数据需要是 json 或 csv。如果数据是 BSON 格式，显然有 mongodrestore。
Mongo 可以轻松处理数十亿个文档，并且可以在一个集合中拥有数十亿个文档，但请记住 maximum document size is 16mb。许多人在 MongoDB 中拥有数十亿个文档，并且在 MongoDB Google User Group 上有很多关于它的讨论。这是一个document，如果您改变主意并想要拥有多个集合，那么您可能想阅读大量集合。您拥有的集合越多，您将拥有的索引也就越多，这可能不是您想要的。
这是来自 Craigslist 的presentation，关于将数十亿个文档插入 MongoDB 和该人的 blogpost。
看起来分片对你来说是一个很好的解决方案，但通常分片用于跨多个服务器进行扩展，很多人这样做是因为他们想要扩展他们的写入或者他们无法保留他们的工作集（数据和索引）在 RAM 中。从单个服务器开始，然后随着数据的增长或您需要额外的冗余和弹性而转移到分片或副本集是完全合理的。
但是，还有其他用户使用多个 mongod 来绕过具有大量写入的单个 mongod 的锁定限制。这很明显，但仍然值得一提，但多 mongod 设置比单个服务器更复杂。如果您的 IO 或 cpu 没有在这里达到最大值，您的工作集小于 RAM，并且您的数据很容易保持平衡（相当随机分布），您应该会看到改进（在单个服务器上进行分片）。作为一个仅供参考，内存和 IO 争用的可能性是存在的。随着 2.2 改进了 concurrency 和 db locking，我怀疑这种部署的理由会少得多。
您需要正确计划分片，即仔细考虑选择分片键。如果您采用这种方式，那么最好预先拆分并关闭平衡器。移动数据以保持平衡会适得其反，这意味着您需要预先决定如何拆分它。此外，有时在设计文档时考虑到某些字段可用于分片或作为主键非常重要。
这里有一些不错的链接 -
【讨论】：
您绝对可以shard data in MongoDB（在shard key 上跨N 个服务器进行分区）。事实上，这是它的核心优势之一。在您的应用程序中无需这样做。
对于大多数用例，我强烈建议对 66 亿个文档执行此操作。根据我的经验，MongoDB 在多台中端服务器上的表现要好于一台大型服务器。
【讨论】：