我有一个可能会非常大的集合。现在我知道 MongoDB 对此并没有真正的问题，但我真的不知道如何设计一个可以舒适地处理非常大的数据集的模式。因此，我将概述问题。
我们正在为我们的客户收集大量数据。基本上，当我们收集这些数据时，它表示为一个 3 元组，比如说 (a, b, c)，其中 b 和 c 分别是集合 B 和 C 的成员。在这种特殊情况下，我们知道 B 集和 C 集不会随着时间的推移而增长太多。对于我们现有的客户，我们谈论的是约 200,000 名会员。但是，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 将能够将客户索引加载到内存中并从那里运行。
您对此有何看法？
PS：我希望这不是太含糊，如果有什么不清楚的地方，我会详细说明。