47

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

将这么多文档加载到单个主键索引上需要很长时间,但据我所知,mongo 不支持等效的分区?

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

4

2 回答 2

65

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

Mongo 可以轻松处理数十亿个文档,并且可以在一个集合中拥有数十亿个文档,但请记住最大文档大小为 16mb。许多人在 MongoDB 中拥有数十亿个文档,并且在MongoDB Google 用户组上有很多关于它的讨论。如果您改变主意并希望改为拥有多个集合,这里有一份关于使用大量集合的文档,您可能想阅读这些文档。您拥有的集合越多,您将拥有的索引也就越多,这可能不是您想要的。

这是来自 Craigslist 的关于将数十亿文档插入 MongoDB 和该人的博客文章的演示文稿

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

但是,还有其他用户使用多个 mongod 来绕过具有大量写入的单个 mongod 的锁定限制。这很明显,但仍然值得一提,但多 mongod 设置比单个服务器更复杂。如果您的 IO 或 cpu 没有在这里达到最大值,您的工作集小于 RAM,并且您的数据很容易保持平衡(相当随机分布),您应该会看到改进(在单个服务器上进行分片)。作为一个仅供参考,内存和 IO 争用的可能性是存在的。随着 2.2 改进了dblocking的并发性,我怀疑这种部署的理由要少得多。

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

这里有一些很好的链接 -

于 2012-07-05T10:44:05.710 回答
8

您绝对可以在 MongoDB 中对数据进行分片(在shard key上跨 N 个服务器进行分区)。事实上,这是它的核心优势之一。在您的应用程序中无需这样做。

对于大多数用例,我强烈建议对 66 亿个文档执行此操作。以我的经验,MongoDB 在多台中端服务器上的表现要好于一台大型服务器。

于 2012-07-04T00:21:04.557 回答