MongoDB:集合中文档的BIllions

时间:2012-07-04 00:16:38

标签: mongodb

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

将许多文档加载到单个主键索引上会花费很长时间,但据我所知mongo不支持相当于分区?

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

2 个答案:

答案 0 :(得分:53)

很难说最佳批量插入是什么 - 这部分取决于您插入的对象的大小和其他不可估量的因素。您可以尝试一些范围,看看是什么让您获得最佳性能。作为替代方案,有些人喜欢使用mongoimport,这非常快,但您的导入数据需要是json或csv。如果数据是BSON格式,那显然是mongodrestore。

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

这是来自Craigslist的一个blogpost,它将数十亿个文档插入MongoDB和那个人的concurrency

看起来像分片对你来说是一个很好的解决方案,但通常分片用于跨多个服务器进行扩展,很多人都这样做,因为他们想要扩展他们的写入或者他们无法保留他们的工作集(数据)和索引)在RAM中。从单个服务器开始,然后在数据增长时移动到分片或副本集,或者您需要额外的冗余和弹性,这是完全合理的。

然而,还有其他用户使用多个mongod来解决大量写入的单个mongod的锁定限制。显而易见但仍然值得一提,但多mongod设置管理比单个服务器更复杂。如果你的IO或cpu没有超出这里,你的工作集小于RAM,你的数据很容易保持平衡(相当随机分布),你应该看到改进(在单个服务器上使用分片)。作为一个FYI,存在内存和IO争用的可能性。随着2.2 db lockingChoosing a Shard Key的改进,我怀疑这种部署的原因要少得多。

您需要计划正确分组,即仔细考虑选择分片键。如果你这样走,那么最好预先拆分并关闭平衡器。移动数据以保持平衡将会适得其反,这意味着您需要预先决定如何拆分数据。此外,设计文档有时很重要,因为某些字段可用于分片或作为主键。

这里有一些很好的链接 -

答案 1 :(得分:8)

您绝对可以shard data in MongoDBshard key上N个服务器上的哪些分区)。事实上,这是它的核心优势之一。在您的申请中没有必要这样做。

对于大多数用例,我强烈建议为66亿个文档执行此操作。根据我的经验,MongoDB在许多中端服务器上表现得更好,而不是一个大型服务器。