非常大的数据集的 MongoDB 扩展和内存使用答案

【问题标题】：MongoDB scaling and memory usage with very large data sets非常大的数据集的 MongoDB 扩展和内存使用
【发布时间】：2012-03-05 18:50:54
【问题描述】：

我目前正在开发一个基于 MongoDB 的系统，该系统将存储至少十亿个文档。这将每月增加约 5000 万。

主集合的 id 格式为 YYYYMM_SOURCEID_DOCTYPE_UUID，用作分片索引。每条记录产生大约 1kb 的索引。 99% 的操作将发生在最近三个月的数据上。我们希望支持文档的关键字搜索，在最近三个月的数据中表现非常好，在较旧的数据上表现至少是半不错的。

只要我可以将索引的活动端保留在内存中，MongoDB 听起来是不是一个合理的解决方案？

【问题讨论】：

标签： mongodb

【解决方案1】：

我建议您更改您的分片键，因为您似乎可能会为 everything 命中最后一个分片，因为键的 YYYYMM 位将使所有新插入都转到“最正确”的碎片总是。 http://www.mongodb.org/display/DOCS/Choosing+a+Shard+Key#ChoosingaShardKey-Cardinality 有更多相关信息。

根据“关键字”字段的基数，您可能希望选择它作为分片键。这样，mongodb 可以轻松地从一个分片中获取属于某个关键字的所有文档。所有写入仍将转到所有分片，因为它是按关键字分区的。

如果“keywords”的基数不是很高（即

【讨论】：

这在一定程度上取决于您还想使用哪些其他文档访问模式，以及您希望这些模式如何执行。如果您将其添加为 cmets，我将更新我的答案。
分片键方法基于上面链接的“索引优化”部分。 MongoDB 将在服务器之间拆分存储桶，如果需要，我们可以对其进行调整。从 YYYYMM 开始背后的想法是确保大多数活动发生在 b 树的一端。我们基本上需要随机访问过去三个月的数据，偶尔读取旧数据。