我不能真正理解 MongoDB 分片集群中的片键概念，因为我刚刚开始学习 MongoDB。
引用 MongoDB 文档：
块是分配给特定分片的连续范围的分片键值。当它们增长到超过配置的块大小时，mongos 将块分成两个块。
似乎卡盘大小与特定分片有关，而不是与集群本身有关。我对吗？
谈到分片键的基数：
考虑使用状态字段作为分片键：
状态键的值保存给定地址文档的美国状态。该字段的基数较低，因为在 state 字段中具有相同值的所有文档必须驻留在同一个 shard 上，即使特定状态的块超过了最大块大小。
由于 state 字段的可能值数量有限，MongoDB 可能会在少量固定块之间不均匀地分布数据。
我的问题是分片键与块大小的关系。
在我看来，只有两个分片服务器，不可能分发数据，因为state 字段中的相同值必须驻留在同一个 shard 上。对于亚利桑那州、印第安纳州和缅因州等三个州的文档，数据是如何分布在两个分片中的？
为了理解您的问题的答案，您需要了解基于范围的分区。如果您有 N 个文档，它们将被分成块 - 确定分割点的方式取决于您的分片键。
由于 shard key 是文档中的某个字段，因此将考虑 shard key 的所有可能值，并且所有文档将（在逻辑上）根据每个文档的 shard key 的值分成块/范围。
在您的示例中，“状态”有 50 个可能的值（好吧，可能更像是 52），所以最多只能有 52 个块。默认块大小为 64MB。现在假设您正在对包含一千万个文档的集合进行分片，每个文档大小为 1K。每个块不应包含超过大约 65K 的文档。一千万个文档应该被分成超过 150 个块，但我们只有 52 个不同的分片键值！所以你的块将非常大。为什么这是个问题？好吧，为了在分片之间自动平衡块，系统需要在分片之间迁移块，如果块太大，则无法移动。而且由于它无法拆分，因此您将陷入不平衡的集群。
分片键和块大小之间肯定存在关系。您想选择具有高基数的分片键。也就是说，您需要一个可以有许多可能值的分片键，而不是像 State 这样的东西，它基本上只锁定了 50 个可能的值。像这样的低基数分片键可能会导致块仅包含一个分片键值，因此在平衡操作中无法拆分并移动到另一个分片。
片键的高基数（例如一个人的电话号码，而不是他们的州或邮政编码）对于确保数据的均匀分布至关重要。低基数分片键会导致无法拆分的更大块（因为您有更多需要保持在一起的连续值）。