2020年快要过去了，写博客的习惯还是得捡起来。最近刚刚忙完搬家的事情，抽出一点时间简单聊两句。
为什么要有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退出的时候还会预祝新年快乐，有点意思。
:) EXIT;
Happy new year.
民那晚安晚安。
