我有一个应用程序，其中Cassandra表的“自然”分区键似乎是“客户” . 这是我们想要查询数据的主要方式，我们可以获得良好的数据分布等 .
但如果有超过100万的客户，那会是太多不同的分区吗？
我应该选择导致分区键数量较少的分区键吗？
我已经看了很多关于这个主题的相关问题，但似乎都没有解决这个问题 .
不.Murmur3Partitioner可以处理类似2 ^ 64（-2 ^ 63到2 ^ 63）分区的内容 . Cassandra旨在非常擅长存储大量数据并通过分区键进行检索 . 分区内的列数有限制（20亿），但对于分区总数，我认为你可以随心所欲 .
当然不 . 这可能会导致分区变得过大，和/或在群集中形成“热点” .
选择一个好的分区密钥背后的主要任务是找到一个（两者）在集群中提供良好的数据分布，并匹配您的查询模式 . 从我正在阅读的内容来看，听起来你已经完成了这一切 .
我想您误解了如何使用分区键 . 建议的分区程序获取您的分区键值，然后从它们计算128位哈希值 . 散列称为记录的标记，它是确定记录存储位置的标记值 . 每个Cassandra节点都有一组与之关联的令牌范围 . 如果记录的令牌落在节点的范围内，则该记录存储在该节点上 . 分区数不是由您选择的分区键确定的：它是群集中令牌范围的数量 . 这大致等于配置数据存储节点时选择的vnode总数 .
您最好使用当前的分区键 . 无需使用复合分区键来驱动更多分区 . 你在做任何时间序列数据建模，每秒增加更多列有点事 . 如果不是，您当前的分区密钥可以用于数百万客户 .
3 回答
不.Murmur3Partitioner可以处理类似2 ^ 64（-2 ^ 63到2 ^ 63）分区的内容 . Cassandra旨在非常擅长存储大量数据并通过分区键进行检索 . 分区内的列数有限制（20亿），但对于分区总数，我认为你可以随心所欲 .
当然不 . 这可能会导致分区变得过大，和/或在群集中形成“热点” .
选择一个好的分区密钥背后的主要任务是找到一个（两者）在集群中提供良好的数据分布，并匹配您的查询模式 . 从我正在阅读的内容来看，听起来你已经完成了这一切 .
我想您误解了如何使用分区键 . 建议的分区程序获取您的分区键值，然后从它们计算128位哈希值 . 散列称为记录的标记，它是确定记录存储位置的标记值 . 每个Cassandra节点都有一组与之关联的令牌范围 . 如果记录的令牌落在节点的范围内，则该记录存储在该节点上 . 分区数不是由您选择的分区键确定的：它是群集中令牌范围的数量 . 这大致等于配置数据存储节点时选择的vnode总数 .
您最好使用当前的分区键 . 无需使用复合分区键来驱动更多分区 . 你在做任何时间序列数据建模，每秒增加更多列有点事 . 如果不是，您当前的分区密钥可以用于数百万客户 .