良好的 Cassandra 表结构答案

【问题标题】：Good Cassandra table structure良好的 Cassandra 表结构
【发布时间】：2021-04-16 19:05:26
【问题描述】：

我有两列，即 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 位的哈希计算 bucketid，我的分区数量有限，这种方法的巨大优势是现在我可以使用未记录的批处理（更少的网络开销，更快的写入（也许））优化对表的写入，因为我可以使用 bucketid 来批处理大量用户的写入请求。假设集群中有 10 个节点，桶的最大数量为 1024，有 1000 万用户，即每个分区大约 10k 用户。理论上，我基本上可以为 10k 用户批量写入。（批处理的好数字要低得多）读取还是一样的，只是需要像这样计算bucketid：

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

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

【问题讨论】：

标签： database database-design cassandra

【解决方案1】：

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

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

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

【讨论】：