好的Cassandra表结构

Question

我有两列，即 UserId（128 个字符）和数据（100 个字符）。 对于查询，

Select data from SimpleTable where user_guid = 'xyzabc123457789sda' ，

将其存储在 cassandra 中的简单表结构将是：

class SimpleTable(Model):
    user_id = columns.Ascii(primary_key=True)
    data = columns.Ascii()

如果我有 1000 万用户，那么我将拥有 1000 万个分区，这通常不是问题。 但是，还有一个替代版本：

class SimpleTable(Model):
    bucketid = int(primary_key=True, partition_key=True)
    user_id = columns.Ascii(primary_key=True)
    data = columns.Ascii()

现在，如果我对 bucketid 进行客户端级抽象，即修复允许的最大桶数并根据 user_id 的前 n 位的 hash 计算 bucketid，我的分区数量有限，这种方法的一个巨大优势是现在我可以使用未记录的批处理（更少的网络开销，更快的写入（也许））优化对表的写入，因为我可以使用 bucketid 为大量用户批处理写入请求。 假设集群中有 10 个节点，桶的最大数量为 1024，有 1000 万用户，即每个分区大约 10k 用户。 理论上，我基本上可以为 10k 用户批量写入。 （批处理的好数字要低得多）读取仍然是相同的，只需要像这样计算bucketid：

Select data from SimpleTable where bucketid = '999' and 'user_id' = 'xyzabc123457789sda'

第二种方法对我来说看起来不错，但我错过了什么吗？ 我是否认为唯一的权衡是在计算 bucketId 和使用 cassandra 批次进行写入之间？

Answer 1

要考虑的另一件事是分区的大小限制。 Cassandra 的硬限制为每个分区（数据）2GB 和每个分区 20 亿个单元（列）。 这就是为什么随着时间的推移分区增长可能是一个问题。

“时间证明”最常见的方法是按时间“桶”。 幸运的是，您似乎对这个概念很满意。 唯一的区别是“时间桶”只是使用时间组件（月、周等）作为复合分区键，而不仅仅是bucketid 。 需要考虑的事情。

基本上，如果您的data列很小并且您永远不会超过 10k 行/分区，那么您的“分桶”解决方案应该没问题。