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