背景
其实早在去年我们就已经开始接触并研究clickhouse了，因为当时进行多表关联测试性能并不是特别优秀，所以并没有在线上大范围使用，当时研究的是分布式部署 （感觉分布式会比单机好一些）最后发现性能并不怎么样 而且分布式的sql也有很多限制，不支持单条删除和更新操作、不支持in和join（当时的版本，18.12.14之前），直到前几天看了携程一篇关于clickhouse的文章，将clickhouse的性能描述的神乎其神，再次勾起了我研究的欲望，附携程公众号文章 每天十亿级数据更新，秒出查询结果，ClickHouse在携程酒店的应用
测试
开始之前我们先看结果：
- 携程的case：
clickhouse 版本：18.12.13
服务器配置：
| 参数 | 配置 |
|---|---|
| CPU | 40c |
| 内存 | 128g |
| 硬盘 | SSD |
| 虚拟内存 | 禁用 |
数据：
| 表 | 数据量 |
|---|---|
| A | 1000w |
| B | 2000w |
| C | 6000w |
| D | 2.4亿 |
测试场景：
| case | 时间 |
|---|---|
| A + B +C 三表关联聚合查询 | 190ms |
| B + D 关联聚合查询 | 390ms |
| A + B +D 三表关联聚合查询 | 640ms |
根据携程给的一份查询统计数据来看他们基于clickhouse的分析需求90%在500ms内：
- 易企秀测试case：
clickhouse 版本：18.12.13
服务器配置：
| 参数 | 配置 |
|---|---|
| CPU | 32c |
| 内存 | 128g |
| 硬盘 | SSD |
| 虚拟内存 | 禁用 |
数据：
| 表 | 数据量 |
|---|---|
| A | 4000w |
| B | 1.3亿 |
测试场景：
| case | 时间 |
|---|---|
| B 单表聚合排序 | 2s |
| B + D 关联聚合排序 | 11s |
通过对比测试，在配置相当的情况下测试结果差距还是很大的，那么究竟是什么原因造成的呢？该如何进行优化...
过程再现
- 调参：
网上有人说通过调大 max_memory_usage 与 max_bytes_before_external_group_by 的值可改善查询性能（主要是处理并发query或单次查询内存约束的）
SET max_memory_usage = 128000000000; #128G，
SET max_memory_usage = 60000000000; #60G，
实际测试这种操作，性能并没有任何影响，但在16C 、68G、普通硬盘环境下的clickhouse调大这两个参数的值性能会有一倍提升。
-
优化建表语句
建表语句
通过缩小分区数量性能略有提升，但不明显
优化SQL
JOIN操作时一定要把数据量小的表放在右边，ClickHouse中无论是Left Join 、Right Join还是Inner Join永远都是拿着右表中的每一条记录到左表中查找该记录是否存在，所以右表必须是小表。优化engine
将普通的mergetree engin 改为特殊的memory engine，性能无任何变化。-
io 排查
通过测试过程中对硬盘io的监控数据看，clickhouse在计算的过程中基本没有什么io操作，只是在最后一个阶段有1-2s的写io操作，这也侧面印证mergetree的强大。
memory engine
那么问题来了 ，这些都没有明显改善，那携程的case是怎么快起来的呢？
初步怀疑携程case中的操作并没有使用到全表数据，应该在聚合前加了很多筛选条件，带着疑问邮件了上文的作者，结论如下：
-
我们调整后的case：
秒查
结论
1、使用SSD盘比普通盘性能会提升1倍
2、亿级别单表聚合排序最慢2s出结果，普通盘需4秒
3、多表关联需增加过滤条件，将聚合结果控制在千万级别内可秒出
4、join时大表在左小表在右
5、如果不想加where条件，那么可以提前构建大宽表或者预计算
6、按照我们业务量级上面服务器配置减半并不影响性能
其实clickhouse并不需要做什么优化，100个并发内单表分析可随意操作，体验极佳；多表分析需根据实际使用场景针对性优化
认为是对的 坚持下去 就是对的，认为是对的 不去坚持 最后可能就是错的
目前我们实时数仓除了使用clickhouse 外 还在使用另外一个秒查引擎，亿级规模场景下分析 这个engine是真的秒查哦 SnappyData
