Cassandra模式设计：分区和集群中应该有更多的列吗？

在我的例子中，我有这样一个表结构：

table_1 {
 entity_uuid text 
,fk1_uuid text
,fk2_uuid text
,int_timestamp bigint
,cnt counter
,primary key (entity_uuid, fk1_uuid, fk2_uuid, int_timestamp)
}

文本列由随机字符串组成。然而，只有

entity_uuid

是真正随机且均匀分布的

fk1_uuid

和

fk2_uuid

具有更低的基数，并且可能稀疏（有时

fk1_uuid=null

或

fk2_uuid=null

）

在这种情况下，我可以只将

实体uuid

定义为分区键，或者将

实体uuid、fk1\u uuid、fk2\u uuid

组合定义为分区键

这是一种查找类型的表，这意味着我们不打算基于此表进行任何聚合/切片。行将被旋转出去，因为我们将插入为每一行定义的TTL

有人能告诉我：

• 有太多的分区键和很少的分区键的缺点是什么 每行？存储引擎级别是否存在命中率/成本
• 我的理解是集群键总是被排序的。这是否意味着集群中的文本列总是会导致树 平衡成本

你现在已经知道我的心在哪里了。但是，当一个分区中的所有行都被TTL删除时，该分区仍然有效，或者有没有办法让DB引擎也删除它们

谢谢

---

Bing

拥有大分区和小分区之间的主要区别，可能也是最显著的区别是能够进行范围扫描。如果您希望能够像这样执行扫描查询

SELECT * FROM table_1 where entity_id = x and fk1_uuid > something

然后，您需要使用集群列来提高性能，否则这个查询将很困难（最好是multi-get，最坏是full-table扫描）。我从来没有听说过任何分区过多会拖累性能，但分区过宽的情况（即大量集群列值）当您进入1B+电池范围时，可能会导致问题

就集群的成本而言，它在写入时基本上是免费的（内存中的排序非常快），但在读取时，由于分区分散在不同的sstable中，您可能会产生成本。一次写入的小分区不会受到合并惩罚，因为它们很可能只存在于SS1表中

TTL分区将被删除，但请务必在

GC\u GRACE\u秒

上阅读，以了解Cassandra实际如何处理删除数据的问题

TL；博士 一切都取决于您的读/写模式

• 没有范围扫描？不需要集群密钥
• 是的，范围扫描？集群键是必须的