聊聊ClickHouse中的低基数LowCardinality类型 |
您所在的位置：网站首页 › lowcard › 聊聊ClickHouse中的低基数LowCardinality类型 |
聊聊ClickHouse中的低基数LowCardinality类型
|
为什么要有LowCardinality
在常见数据库系统的类型体系中，字符串是最灵活、表意性最强的类型，但是存储成本无疑也最高。ClickHouse提供了两种简单字符串的更优的存储方式，即： 存储固定长度（按字节数计）字符串的FixedString类型， 以及将字符串转为定长整形枚举值的Enum类型。 但是，我们平时见到的字符串绝大多数都是变长的，只有哈希值、IP等少数种类适合用FixedString存储；并且数据的定义域可能会经常变动，频繁修改Enum字段来增加枚举值也显然不可行。因此，ClickHouse又提供了第三条路，即LowCardinality——“低基数”类型。顾名思义，它适合长度和定义域都可变，但总体基数不是特别大的列。 根据官方文档，低基数是一种修饰类型，即用法为LowCardinality(type)。其中type表示的原始类型可以是String、FixedString、Date、DateTime，以及除了Decimal之外的所有数值类型。但是，LowCardinality的设计初衷就是为了优化字符串存储，修饰其他类型的效率未必会更高，所以下面只考虑LowCardinality(String)的情况。 做个小实验来创建两张MergeTree测试表，其中一个用普通String类型，另一个用低基数String类型。 CREATE TABLE test.user_event_common_str ( user_id Int64, event_type String ) ENGINE = MergeTree() ORDER BY user_id; CREATE TABLE test.user_event_lowcard_str ( user_id Int64, event_type LowCardinality(String) ) ENGINE = MergeTree() ORDER BY user_id;从我们的埋点日志表中取一些数据（总计约2.3亿行）分别存入两张表中。event_type字段表示埋点事件类型，目前约有100种，且会随着应用的迭代而增加。 做个简单的聚合查询： :) SELECT event_type,count() AS cnt FROM test.user_event_lowcard_str GROUP BY event_type ORDER BY cnt DESC; -- ... 105 rows in set. Elapsed: 0.050 sec. Processed 229.77 million rows, 240.39 MB (4.59 billion rows/s., 4.80 GB/s.) :) SELECT event_type,count() AS cnt FROM test.user_event_common_str GROUP BY event_type ORDER BY cnt DESC; -- ... 105 rows in set. Elapsed: 0.297 sec. Processed 229.77 million rows, 5.34 GB (774.40 million rows/s., 18.00 GB/s.)可见在这个场景下，对低基数String进行聚合，速度是对普通String进行聚合的6倍，并且读取的数据量只有原来的4.5%。从系统表中查询存储空间的占用，低基数String也明显要更小： :) SELECT table,column, sum(rows) AS rows, formatReadableSize(sum(column_data_compressed_bytes)) AS comp_bytes, formatReadableSize(sum(column_data_uncompressed_bytes)) AS uncomp_bytes FROM system.parts_columns WHERE table LIKE 'user_event_%_str' AND column = 'event_type' GROUP BY table,column; ┌─table──────────────────┬─column─────┬──────rows─┬─comp_bytes─┬─uncomp_bytes─┐ │ user_event_lowcard_str │ event_type │ 229770105 │ 186.89 MiB │ 219.57 MiB │ │ user_event_common_str │ event_type │ 229770105 │ 599.33 MiB │ 3.26 GiB │ └────────────────────────┴────────────┴───────────┴────────────┴──────────────┘我们甚至可以用DDL语句将String类型的列直接修改为低基数String类型的列，速度也相当快： :) ALTER TABLE test.user_event_common_str MODIFY COLUMN event_type LowCardinality(String); 0 rows in set. Elapsed: 7.420 sec. 低基数的背后LowCardinality的实现方法同样简单而高效，即字典压缩编码（dictionary encoding）加上倒排索引（reverse index），如下图所示。事实上，LowCardinality(String)类型还有一个别名StringWithDictionary，更贴近其本质。 一旦有了字典，很多对字符串进行操作的函数就可以下推到字典上执行（如下图所示），效率很高。另外，同一个字典上的操作会被缓存（甚至包括GROUP BY子句产生的哈希值），不必每次都进行计算。 最后，ClickHouse还提供了low_cardinality_max_dictionary_size参数来控制单个字典的大小阈值，默认为8192。也就是说，如果LowCardinality(String)列的基数大于该阈值，就会被拆分成多个字典文件存储。 那么，低基数String的基数控制在什么范围内的效率最高呢？关于这点，官方文档和Altinity的blog给出了完全不同的答案。前者认为控制在万级别以内较好，而后者认为10M（即约1000万）以下都可以。笔者利用现有数据集进行测试，String的基数是10万级别，采用LowCardinality的聚合效率仍然是普通String的4倍左右，看官可酌情参考。 The End临近年关，clickhouse-client退出的时候还会预祝新年快乐，有点意思。 喜欢clickhouse的同学，可以关注下方⬇️????书籍购买链接????。 |
【本文地址】