python - 将大型收藏分成较小的收藏？

Question

我有一个可能会非常大的收藏。现在我知道 MongoDB 并没有真正遇到这个问题，但我真的不知道如何着手设计一个可以轻松处理非常大的数据集的模式。因此，我将概述问题。

我们正在为客户收集大量数据。基本上，当我们收集这些数据时，它被表示为一个三元组，比方说 (a, b, c)，其中 b 和 c 分别是集合 B 和 C 的成员。在这种特殊情况下，我们知道 B 和 C 集不会随时间增长太多。对于我们目前的客户，我们谈论的是约 200,000 名成员(member)。但是，A 集是随着时间不断增长的集。目前我们每个客户大约有 2,000,000 名成员，但这个数字将会增长(可能会很快)。此外，b->a 和 c->a 之间存在 1->n 关系。

此数据集的工作负载基本上分为 3 个用例。集合将定期更新，其中 A 将获得最多的写入，B 和 C 将获得一些，但不是很多。第二个用例是随机访问 B，然后聚合 C 中与 b\in B 相关的一些文档。最后一个用例基本上是从 A 和 B 流式传输一个大的子集以生成一些新数据。

我们面临的问题是索引越来越大。目前我们有大约 8 个小客户的测试设置，目前总数据集大小约为 15GB，索引运行在大约 3GB 到 4GB 之间。这里的问题是我们的数据集中实际上没有任何热点区域。它基本上会在所有文档中平均分配负载。

基本上，我们提出了 2 个选项来执行此操作。我在上面描述的那个，所有客户的所有数据都堆积在一个集合中。这意味着我们必须在某个字段中创建一个索引，将该集合中的文档链接到特定客户。

另一种选择是将所有 b 和 c 放在一起(这些集合相对较小)，但将 C 集合分开，每个客户一个。我可以想象最后一个解决方案有点难以管理，但由于我们很少同时访问多个客户的数据，因此它可以防止内存问题。 MongoDB 将能够将客户索引加载到内存中并从那里运行。

你对此有何看法？

P.S.:我希望这不是太含糊，如果有任何不清楚的地方，我会详细介绍。

Answer 1

这听起来像是一个更大的集合(如果我没听错的话是 A)，可以合理地放入它自己的数据库中。我说的是数据库而不是集合，因为现在 2.2 发布了，您可能希望尽量减少更繁忙的数据库与其他数据库之间的锁争用，为此最好使用一个单独的数据库(2.2 引入了数据库级锁定)。当然，这是从单个副本集模型来看的。

此外，索引大小听起来与您的数据大小有点不成比例 - 您确定它们都是必需的吗？修剪不需要的索引，组合和使用复合索引可能会显着减少您在索引增长方面遇到的痛苦(它也可能使更新和插入更有效率)。这确实需要具体细节，可能属于另一个问题，或者可能属于 mongodb 用户组中的一个线程，以便多只眼睛可以查看并提出建议。

如果我们考虑分片的可能性，那么真正重要的部分是选择一个分片键，以确保在分片上保留您经常需要一起访问的部分的位置。这将更适合于单个分片集合(在多个相关分片集合中保持局部性将非常棘手，除非您以某种方式手动拆分和平衡 block )。分片使您能够在索引达到单个实例限制等时水平扩展，但这将使分片键决策变得非常重要。

同样，选择分片键的细节超出了这个更一般性讨论的范围，类似于我上面提到的潜在索引审查。