聊聊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.

民那晚安晚安。

  • 11
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 2
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值