“冗余”聚类列有什么缺点吗？答案

【问题标题】：Any downside to 'redundant' clustering column?“冗余”聚类列有什么缺点吗？
【发布时间】：2019-02-16 01:17:10
【问题描述】：

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

对于这个示例表：

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

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

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

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

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

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

其他 cmets 值得注意的是，在上面的定义中，如果在 time 上没有相等过滤器，则无法按 state 过滤，这使得它对于过滤 state 不是很有用。如果您将state 列放在time 上方以解决此问题，那么可以通过state 和time 不等式进行过滤，但如果您想要所有状态（IN 子句），则返回的行按@987654340 排序先@，然后time，这又不是很有用。

【问题讨论】：

标签： cassandra cql

【解决方案1】：

我认为这里的主要区别在于，如果它是一个集群列，它必须提供 INSERT，因为它是主键的一部分。此外，由于它是主键的一部分，因此您也无法对其进行更新，这对于某些表来说可能会出现问题。如果您对这两者中的任何一个都没有任何顾虑，我看不出您有任何不能添加它的原因。

【讨论】：

【解决方案2】：

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

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

【讨论】：