背景
clickhouse集群容量告警，项目中某些表占据大量的存储空间，借此机会对ck的存储优化进行实践学习，并通过多种方式测试验证优化效果。
问题定位
通过查询系统表元数据，定位头部存储的表。之前的文章有具体查询逻辑。如果能通过清理或者是控制表生命周期是最快的方式，不然就要看具体的表各列的存储压缩大小。以下图为例，压缩率在10以下的就是比较低的。
优化方式
要着手优化，最好标准自然是参考官方的最佳实践。
排序键设计
按基数升序排列关键列，能提升存储压缩率和查询效率。 https://clickhouse.com/docs/en/optimize/sparse-primary-indexes#ordering-key-columns-efficiently
- hits_URL_UserID_IsRobot具有复合主键的表(URL, UserID, IsRobot)，其中我们按基数降序排列关键列
- hits_IsRobot_UserID_URL具有复合主键的表(IsRobot, UserID, URL)，其中我们按基数按升序对键列进行排序
压缩率：
查询效率：
这里官方有提供效果验证，就不在重复。
写入顺序
除了低基数列在前，通过对数据进行排序也能提升压缩效率。 因为ck物理存储同分区里也是分数据块的，一个数据块中的数据更有序也能提升存储效率。
压缩算法 DoubleDelta
在定位问题时，我们发现唯一键row_key 的压缩率不到2，一部分原因是该字段写入ck时是乱序的，另外就是使用合适的压缩算法。 ck默认的算法是LZ4（原理是按照4字节窗口扫描，查找与之前的值是否匹配）。但如果我们是有序是列，可以使用另外两个压缩算法 Delta/DoubleDelta (Delta编码存储一个基础值以及后续相邻两个数据的差值, Double Delta是在Delta基础上再做一次Delta，等差数列压缩相当优秀)
我们可以看下有序和无序的数据在不同压缩算法的差异。Double Delta再压缩有序列效率可谓“遥遥领先”。
LowCardinality
低基数建议使用LowCardinality。 相同数据（Android/IOS 枚举）压缩后大小差异近6倍。
避免使用Nullable
相同数据没有Nullable 压缩率更高
总结
以上是我们在优化存储时主要尝试的方案，具体优化还要结合业务情况来定。
