“冗余”群集列有什么缺点吗?

mccptt67  于 2021-06-10  发布在  Cassandra
关注(0)|答案(2)|浏览(470)

我注意到,在某些情况下,将常规cassandra列更改为集群列可以显著减小表的大小。
对于此示例表:

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

100000行的大小估计为3.9MB,如果 state 是普通列,如果 state 是一个聚类列(使用datastax课程ds220中的方法估计)。
如果看看数据是如何物理存储的,就不难理解为什么会存在这种差异。在前一种情况下,每个时间戳有两个内部单元-一个用于 state 一个给我 value . 在后一种情况下 value 合并到单元密钥中,因此每个时间戳只有一个单元,并且时间戳(单元密钥的一部分)只存储一次。
第二个集群列不会对可以查询的内容创建任何新的限制。 SELECT * FROM table WHERE id=? AND time>=? AND time<? 他还是很好。
这似乎是一个双赢的局面。特别是在性能方面,是否存在任何不利因素?
(我能想到的就是如果 state 是一个正则列,则可以从insert和 state 不会创建内部单元格。我想如果 state 是一个正则列,通常被省略,那么这个表将比 state 是群集列。)
附加注解值得注意的是,在上面的定义中,您不能按 state 没有相等过滤器 time ,使其不太适用于过滤 state . 如果你把 state 上面的列 time 若要解决此问题,则可以通过 state 以及 time 不相等,但如果需要所有状态(in子句),则返回按顺序排列的行 state 首先,然后 time ,这也不是很有用。

vxbzzdmp

vxbzzdmp1#

1) 您可以根据创建一行 state . 您的数据模型必须认识到并理解这一点。可以使用不同的 state 是一样的 id , time ,原始模型不允许。
2) 如果删除,则需要指定 state 否则你会创造 Range Tombstones (范围删除,因为您正在删除给定 id 以及 time ,但它可能是一系列 state s) 是的。范围逻辑删除在2.1中特别昂贵(在读取路径上),并且在中没有正确考虑 TombstoneOverwhelming 异常处理程序,除非您确实需要它们,否则避免使用范围逻辑删除通常是个好主意。

5lhxktic

5lhxktic2#

我认为这里的主要区别在于,如果它是一个集群列,那么它必须提供insert作为主键的一部分。另外,由于它是主键的一部分,因此也不能更新它,这对于某些表来说可能会有问题。如果你对这两个都没有任何顾虑的话,我看不出你为什么不能加上它。

相关问题