【发布时间】：2015-08-19 08:07:31
【问题描述】：
我有一个应用程序，其中 Cassandra 表的“自然”分区键似乎是“客户”。这是我们想要查询数据的主要方式，我们将获得良好的数据分布等。
但是如果有超过 100 万的客户，那会不会有太多不同的分区？
我应该选择一个分区键数量较少的分区键吗？
我已经查看了一些关于这个主题的相关问题，但似乎没有一个能解决这个问题。
【问题讨论】：
【发布时间】：2015-08-19 08:07:31
【问题描述】：
但是如果有超过 100 万的客户，那会不会有太多不同的分区？
没有。 Murmur3Partitioner 可以处理类似 2^64（-2^63 到 +2^63）的分区。 Cassandra 被设计成非常擅长存储大量数据并通过分区键检索。 一个分区（20 亿）的列数是有限制的，但对于分区的总数，我认为你会接受你所拥有的。
我应该选择一个分区键数量较少的分区键吗？
绝对不是。这可能会导致您的分区变得太大，和/或在集群中形成“热点”。
选择一个好的分区键的主要任务是找到一个（两者）都能在集群中提供良好的数据分布并与您的查询模式相匹配的分区键。从我读到的内容来看，听起来你确实做到了。
【讨论】：
我认为您误解了如何使用分区键。推荐的分区程序获取您的分区键值，然后从中计算 128 位哈希。哈希称为记录的 token，正是该令牌值决定了记录的存储位置。每个 Cassandra 节点都有一组与之关联的令牌范围。如果记录的标记落在某个节点的范围内，则该记录将存储在该节点上。 partitions 的数量不是由您选择的分区键决定的：它是集群中令牌范围的数量。这大致等于您在配置数据存储节点时选择的 vnodes 总数。
【讨论】：
您可以使用当前的分区键。无需使用复合分区键来驱动更多分区。您是否在进行任何时间序列数据建模，每秒增加更多列。如果没有，您当前的分区键可以用于数百万客户。
【讨论】：