我试图在cassandra中存储以下结构 .
ShopID, UserID , FirstName , LastName etc....
对它的大多数查询都是
select * from table where ShopID = ? , UserID = ?
这就是将（ ShopID, UserID ）设置为主键的原因 .
根据文档，Cassandra的默认分区键是第一列主键 - 对于我的情况它是 ShopID ，但我想在Cassandra集群上统一分发数据，我不能允许来自一个 shopID 的所有数据只存储在一个分区，因为一些商店有10M记录，有些只有1k .
我可以设置（ ShopID, UserID ）作为分区键，然后我可以在Cassandra集群中达到记录的统一分布 . 但之后我无法接收属于某些 shopid 的所有用户 .
select *
from table
where ShopID = ?
很明显，这个查询要求对整个集群进行全扫描，但我没有任何可能做到这一点 . 它看起来非常严格 .
我的问题是如何重新组织数据以同时解决这两个问题（统一数据分区，进行全面扫描查询的可能性） .
2 回答
通常，您需要将用户ID设置为群集列，并在保存期间向表和分区键添加一些人为信息 . 它允许将大的自然分区打破到多个合成 . 但是现在您需要在读取期间查询所有合成分区以组合回自然分区 . 因此，目标是在合成分区的数量（大小）和读取查询之间找到合理的权衡以组合所有这些 .
可以找到here和here（示例2：用户组）的可能实现的全面描述 .
当通过聚类日期类型列执行查询/排序/分组时，还要查看solution（示例3：按连接日期的用户组） . 如果您也有类似的查询，它会很有用 .
Cassandra中的每个节点都负责一些令牌范围 . Cassandra使用散列从行的分区键派生一个令牌，并将记录发送到其令牌范围包含此令牌的节点 . 不同的记录可以具有相同的令牌，并且它们在分区中分组 . 为简单起见，我们可以假设每个cassandra节点存储相同数量的分区 . 我们还希望分区的大小相等，以便在节点之间均匀分配 . 如果我们有一个太大的分区，这意味着我们的一个节点需要更多的资源来处理它 . 但是如果我们将它分成多个较小的，我们就会增加它们在所有节点之间均匀分布的可能性 .
但是，节点之间的令牌范围分布与分区之间的记录分布无关 . 当我们添加一个新节点时，它只承担来自其他节点的偶数部分令牌范围的责任，结果是偶数个分区 . 如果我们有2个节点具有3 GB数据，则在添加第三个节点后，每个节点存储2 GB数据 . 这就是为什么可扩展性不受分区影响的原因，您无需在添加新节点后更改历史数据 .