MongoDB：集合中的所有文档

Question

我需要将66亿个bigrams加载到集合中，但我找不到任何有关此操作最佳方法的信息。

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

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

Answer 1

很难说什么是最佳批量插入 - 这部分取决于您插入的对象的大小以及其他不可估量的因素。你可以尝试一些范围，看看什么给你最好的表现。作为替代，一些人喜欢使用mongoimport，这很快，但是您的导入数据需要是json或csv。如果数据是BSON格式，显然有mongodrestore。

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

这是Craigslist的presentation关于将数十亿个文档插入MongoDB和该文档的blogpost。

它确实看起来像分片将是一个很好的解决方案，但通常分片用于扩展多台服务器和很多民间人士这样做，因为他们想要扩大他们的写作或他们无法保持其工作集（数据和索引）在RAM中。从一台服务器开始，然后随着数据增长或移动到分片或副本集合，或者需要额外的冗余和弹性，这是完全合理的。

但是，还有其他用户使用多个mongods来解决大量写入的单个mongod的锁定限制。这很明显，但仍值得一说，但与单一服务器相比，multi-mongod设置的管理更为复杂。如果你的IO或cpu没有超出这里，你的工作集比RAM小，你的数据很容易保持平衡（非常随机分布），你应该看到改进（在单个服务器上分片）。作为参考，存在内存和IO竞争的可能性。 2.2的改进concurrency与db locking，我怀疑这样的部署将有更少的原因。

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

下面是一些很好的联系 -

• 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在一些中档服务器上表现更好，而不是一个大型服务器。