聊聊ClickHouse中的低基数（LowCardinality）类型

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.

民那晚安晚安。