如果我有大量的收藏，数据库分片看起来很棒。如果我有很多相当大的集合怎么办？假设对于 1 亿个文档（不是很大的评论）的集合，分片是有效的。它是否也对 10 000 个集合每个 10 000 个文档有效？
（我认为这个问题对于面向表的数据库仍然有效，如果你用表替换集合，用行替换文档。如果可能的话，我想知道理论答案以及特定 MongoDB 场景中的答案，如果与理论不同的话回答。）
AskOverflow.Dev
如果我有大量的收藏，数据库分片看起来很棒。如果我有很多相当大的集合怎么办？假设对于 1 亿个文档（不是很大的评论）的集合，分片是有效的。它是否也对 10 000 个集合每个 10 000 个文档有效？
（我认为这个问题对于面向表的数据库仍然有效，如果你用表替换集合，用行替换文档。如果可能的话，我想知道理论答案以及特定 MongoDB 场景中的答案，如果与理论不同的话回答。）
大多数人都有“单一大型集合”的问题，因此分片显然有助于减少平衡这些数据的麻烦。
然而，当你有 10000 个小集合时，你头疼的可能不是“平衡数据”。对于这么多小集合，您的问题很可能是跟踪这些集合。根据您的文档大小，您甚至可能无法突破实际发生分片的下限。
对于非常小的集合，您可以使用鲜为人知的movePrimary 命令来管理数据的位置。
当然，另一种看待这个问题的方式是为什么你有 10k 的收藏？集合不需要同质对象，并且对于 10k 集合，必须生成其中的大部分。很可能在同一个集合中存储不同“类型”的数据，减少集合的数量，然后将类型作为分片键的一部分。
MongoDB 分片的工作原理是将一个集合分成更小的“块”，然后将它们平均分布在多台机器上。通常最有效的默认块大小为 200MB。因此，除非一个集合增长到远大于 200MB，否则它不会分成块，因此不符合分片的条件，所以不会有任何好处。
在一般情况下，在多台机器上分片数据是扩展读取、写入和查询的一种非常有效的方法。您可以获得多个 CPU、硬盘和内存存储的好处，它们可以并行读取、写入和处理数据。内存横向扩展对于 MongoDB 尤为重要，MongoDB 的高性能对内存中的数据拟合非常敏感。