我注意到,在某些情况下,将常规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
,这也不是很有用。
2条答案
按热度按时间vxbzzdmp1#
1) 您可以根据创建一行
state
. 您的数据模型必须认识到并理解这一点。可以使用不同的state
是一样的id
,time
,原始模型不允许。2) 如果删除,则需要指定
state
否则你会创造Range Tombstones
(范围删除,因为您正在删除给定id
以及time
,但它可能是一系列state
s) 是的。范围逻辑删除在2.1中特别昂贵(在读取路径上),并且在中没有正确考虑TombstoneOverwhelming
异常处理程序,除非您确实需要它们,否则避免使用范围逻辑删除通常是个好主意。5lhxktic2#
我认为这里的主要区别在于,如果它是一个集群列,那么它必须提供insert作为主键的一部分。另外,由于它是主键的一部分,因此也不能更新它,这对于某些表来说可能会有问题。如果你对这两个都没有任何顾虑的话,我看不出你为什么不能加上它。