好的卡桑德拉表结构

Question

我有两列，即UserId(128个字符(和data(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，我的分区数量有限，这种方法的一个巨大优势是，现在我可以使用未标记的批处理优化对表的写入(更少的网络开销，更快的写入(也许((，因为我可以使用buketid为大量用户批处理写入请求。假设集群中有10个节点，最大存储桶数为1024，用户数为1000万，即每个分区约有1万用户。从理论上讲，我基本上可以为1万用户批量写作。(配料的好数字要低得多(读数仍然相同，只需要像这样计算bucketid：

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

第二种方法对我来说似乎很好，但我错过了什么吗？我认为唯一的折衷是在计算bucketId和使用cassandra批处理进行写入之间，这是对的吗？

Answer 1

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

最常见的"；时间证明"；是指"；"桶"；按时间。幸运的是，你似乎对这个概念很满意。唯一的区别在于；时间桶"；只是简单地使用时间组件(月、周等(作为复合分区键，而不仅仅是bucketid。需要考虑的事情。

基本上，如果您的data列很小，并且永远不会超过10k行/分区，那么您的"；桶装"；解决方案应该是好的。