cassandra - “冗余”聚类列有什么缺点吗？

Question

我注意到在某些情况下，将常规 Cassandra 列更改为集群列可以显着减小表的大小。

对于此示例表：

id     UUID        K
time   TIMESTAMP   C
state  TINYINT    (C)
value  DOUBLE

state如果是普通列，则 100000 行的大小估计为 3.9 MB ，如果state是聚类列，则估计为 2.4 MB（使用DataStax 课程 DS220中的方法估计）。

如果您查看数据的物理存储方式，不难看出为什么存在这种差异。在前一种情况下，每个时间戳有两个内部单元格 - 一个 forstate和一个 for value。在后一种情况下value，将合并到单元密钥中，因此每个时间戳只有一个单元，并且时间戳（单元密钥的一部分）仅存储一次。

第二个聚类列不会对可以查询的内容产生任何新的限制。SELECT * FROM table WHERE id=? AND time>=? AND time<?还可以。

这似乎是一个双赢的局面。是否有任何缺点，特别是在性能方面？

（我能想到的是，如果state是一个常规列，那么它可以从插入中省略，并且state永远不会创建内部单元格。我想如果state是一个常规列并且通常被省略，那么表格将比如果state是一个聚类列。）

---

附加评论 值得注意的是，在上面的定义中，如果state没有相等过滤器time，则无法过滤，这使得它对于过滤不是很有用state。如果你把state上面的列time来解决这个问题，那么是的，你可以过滤state和time不等式，但是如果你想要所有状态（IN 子句），那么返回的行首先按顺序返回state，然后time，这又不是很有用。

标签： cassandracql

Answer 1

1）您每创建一行state。您的数据模型必须意识到并理解这一点。您可能会为相同的,创建具有不同states 的两行，这是原始模型所不允许的。idtime

2）如果您删除，您需要指定state或创建Range Tombstones（范围删除，因为您要删除给定idand的所有行time，但它可能是states 的范围）。范围墓碑在 2.1 中特别昂贵（在读取路径上），并且TombstoneOverwhelming直到最近的 Cassandra 版本才在异常处理程序中正确考虑，因此避免范围墓碑通常是一个好主意，除非您确实需要它们。