原文链接🔗:https://www.jianshu.com/p/f361e7cfc8b3
2020年快要过去了,写博客的习惯还是得捡起来。最近刚刚忙完搬家的事情,抽出一点时间简单聊两句。
在常见数据库系统的类型体系中,字符串是最灵活、表意性最强的类型,但是存储成本无疑也最高。ClickHouse提供了两种简单字符串的更优的存储方式,即:
但是,我们平时见到的字符串绝大多数都是变长的,只有哈希值、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倍左右,看官可酌情参考。