美文网首页
Clickhouse的稀疏索引以及"8192"的含义

Clickhouse的稀疏索引以及"8192"的含义

作者: 白奕新 | 来源:发表于2019-08-18 23:40 被阅读0次

    相信用过Clickhouse的MergeTree引擎的同学都有听说过稀疏索引以及设置过"8192"这个参数,但是官网的案例说明比较晦涩,我一开始也是理解得云里雾里。后面是看到Alexey Milovidov写的一篇介绍,才算是理解了其实的奥秘。把我所了解到的分享给大家,希望对大家也有帮助。

    1、介绍


    从官网的Demo开始。官网给的介绍案例是以(CounterID、Date)这2个键来建立索引,可以看到一对的(CounterID、Date)间隔地生成了一个Marks,例如(a,1),(a,2);根据Marks又生成了相应的Marks numbers。那么"8192"这个index_granularity参数又是用来做什么的呢?大家可以看下(a,1),(a,2)这2个索引之间,间隔了好几个数据,即:
    (1)index_granularity这个参数规定了数据按照索引规定排序以后,间隔多少行会建立一个索引的Marks,即索引值
    (2)稀疏索引的意义即是Clickhouse不对所以的列都建立索引(相比较Mysql的B树索引会为每行都建立),而是间隔index_granularity列才建立一个。
    (3)Marks与Marks number均被保存在内存中,利于查询的时候快速检索。

    2、检索过程

    表字段的存储

    clickhouse针对每一列都进行了分别存储,并生成了.bin以及.mrk两个文件。bin文件存储了真正的列的值(内部又设计列的压缩),mrk文件记录了Mark numbers对应这个列的offset。以官网例子为例,Marks numbers为3对应了CounterID取值为[b,c,d,e]4个字符,查询命中Marks numbers=3时,通过CounterID的mrk文件就可以知道这4个字符在CounterID的bin文件中存储的offset,提高查询性能。

    3、总结

    (1)虽然是稀疏索引,但是如果索引中的列过多,则根据索引来划分数据会更稀疏,建立的索引也需要更多,影响写入性能,也会增加内存的使用
    (2)相比普通的B树索引,稀疏索引需要的内存更少,但是可能导致需要扫描的行数比实际的多(以官网demo为例,例如查询(e,1)命中第3个索引,则需要扫描{index_granularity}行的数据,但是其实内部(e,1)的数据只占了少部分,带来了无效扫描)
    (3)官网推荐是不需要去改"8192"这个值。我个人认为是除非你要做为索引的这个列的值分布非常非常集中,可能几w行数据才可能变化一个取值,否则无需去做调大去建立更稀疏的索引,不过如果这个列这个集中的分布,也不大适合作为索引;如果要调小这个值,是会带来索引列增加,但是同样也会带来内存使用增加、写入性能受影响。
    (4)有2个列组合做组合索引,一个值比较稀疏、一个值比较集中,要选稀疏的值放在第一位。只能选择一个列做单索引,如果有2个备选的值,要选比较稀疏的。

    reference

    ClickHouse Primary Keys

    相关文章

      网友评论

          本文标题:Clickhouse的稀疏索引以及"8192"的含义

          本文链接:https://www.haomeiwen.com/subject/zwadsctx.html