我有一个可能非常大的集合。现在我知道MongoDB确实没有问题，但我真的不知道如何设计一个可以舒适地处理非常大的数据集的模式。所以我将概述这个问题。
我们正在为客户收集大量数据。基本上，当我们收集这些数据时，它表示为3元组，假设（a，b，c），其中b和c分别是集合B和C的成员。在这种特殊情况下，我们知道B和C组不会随着时间的推移而增长很多。对于我们现在的客户，我们谈论的是大约200,000名会员。但是，A集是随着时间的推移不断增长的集合。目前我们每个客户约有2,000,000名会员，但这种情况将会增长（可能很快）。此外，b-＆gt; a和c-＆gt; a之间存在1＆gt; n关系。
此数据集上的工作负载基本上分为3个用例。这些集合将定期更新，其中A将获得最多的写入，而B和C将获得一些但不是很多。第二个用例是随机访问B，然后聚合C中与b \ b相关的一些文档。最后一个用例基本上是从A和B流式传输一个大的子集来生成一些新数据。
我们面临的问题是索引变得越来越大。目前我们有大约8个小客户的测试设置，目前总数据集大小约为15GB，索引运行大约3GB到4GB。这里的问题是我们的数据集中确实没有任何热区。它基本上会在所有文档中获得均匀分布的负载。
基本上我们已经提出了两个选项来做到这一点。我在上面描述的那个，其中所有客户的所有数据都堆积在一个集合中。这意味着我们必须创建一个索引，将某个集合中的文档链接到特定客户。
其他选项是将所有b和c放在一起（这些设置相对较小）但是将C系列分开，每个客户一个。我可以想象最后一个解决方案有点难以管理，但由于我们很少同时访问多个客户的数据，因此可以防止内存问题。 MongoDB可以将客户索引加载到内存中，并从那里运行。
您对此有何看法？
P.S。：我希望这不是太模糊，如果有什么不清楚我会详细介绍。
答案 0 :(得分：1)
听起来像是一个较大的集合（如果我正确地遵循了A），可以合理地放入自己的数据库中。我说数据库而不是集合，因为现在2.2发布了你想要最小化繁忙数据库和其他数据库之间的锁争用，并且这样做一个单独的数据库将是最好的（2.2引入数据库级锁定）。当然，这是从单个副本集模型中看到的。
索引大小听起来与您的数据大小有点不一致 - 您确定它们都是必需的吗？修剪不需要的索引，组合和使用复合索引可以显着减少您在索引增长方面遇到的痛苦（它可能会使更新和插入更有效）。这确实需要细节，可能属于另一个问题，或者可能属于mongodb用户组中的一个线程，因此多只眼睛可以看一看并提出建议。
如果我们看一下抛出分片的可能性，那么真正重要的部分就是选择一个分片键，以便确保在分片上保留局部性，以便您经常需要一起访问它们。这将更适合单个分片集合（除非您以某种方式手动拆分和平衡块，否则保留多个相关分片集合的局部性将非常棘手）。当您的索引达到单个实例限制等时，分片使您能够水平扩展，但它会使分片键决定非常重要。
同样，选择该分片键的细节超出了这个更一般性讨论的范围，类似于我上面提到的潜在索引评论。