MongoDB:集合中文档的BIllions

Question

我需要将66亿个双内存加载到一个集合中，但我找不到任何关于最佳方法的信息。

将如此多的文档加载到一个主键索引上将永远耗费时间，但据我所知，mongo不支持与分区等效的功能？

分片会有帮助吗？我是否应该尝试将数据集拆分到多个集合中，并将该逻辑构建到我的应用程序中？

Answer 1

很难说最佳的批量插入是什么--这在一定程度上取决于要插入的对象的大小和其他不可测量的因素。你可以尝试几个范围，看看哪一个能给你最好的性能。作为另一种选择，有些人喜欢使用mongoimport，这是相当快的，但您的导入数据需要是json或csv。显然有mongodrestore，如果数据是BSON格式的。

Mongo可以轻松处理数十亿个文档，并且可以在一个集合中包含数十亿个文档，但请记住maximum document size is 16mb。有很多人在MongoDB上有数十亿的文档，在MongoDB Google User Group上有很多关于它的讨论。如果你改变主意，想要拥有多个集合，这里有一个关于使用大量集合的document，你可能会喜欢阅读。拥有的集合越多，拥有的索引也就越多，这可能不是您想要的。

这是一个来自Craigslist的关于将数十亿个文档插入到MongoDB和他的blogpost中的presentation。

分片看起来确实是一个很好的解决方案，但通常分片用于跨多个服务器进行扩展，很多人这样做是因为他们想要扩展他们的写操作，或者他们无法将他们的工作集(数据和索引)保存在RAM中。从单个服务器开始，然后随着数据增长或需要额外的冗余和恢复能力而转移到分片或副本集，这是非常合理的。

然而，也有其他用户使用多个神来绕过单个神的锁定限制，因为有很多写操作。这是显而易见的，但仍然值得说一说，但多mongod设置比单一服务器管理更复杂。如果您的IO或cpu没有达到最大值，您的工作集比RAM小，并且您的数据很容易保持平衡(相当随机地分布)，那么您应该会看到改进(在单个服务器上使用分片)。作为FYI，存在内存和IO争用的可能性。随着2.2通过db locking改进了concurrency，我怀疑这样的部署的理由将会少得多。

你需要适当地计划你的分片，也就是仔细考虑选择你的分片键。如果你这样做，那么最好的方法是预先拆分并关闭平衡器。移动数据以保持平衡将适得其反，这意味着您需要预先决定如何拆分数据。此外，有时在设计文档时，考虑到某些字段可用于分片或用作主键，这一点很重要。

这里有一些很好的链接-

• Choosing a Shard Key
• Blog post on shard keys
• Overview presentation on sharding
• Presentation on Sharding Best Practices

Answer 2

您完全可以使用shard data in MongoDB (在shard key上跨N个服务器进行分区)。事实上，这是它的核心优势之一。在您的应用程序中不需要这样做。

对于大多数用例，我强烈建议对66亿个文档执行此操作。根据我的经验，使用多个中端服务器比使用一个大型服务器时，MongoDB的性能更好。