ClickHouse 参数配置

转载自：https://xw.qq.com/cmsid/20200806A0PQ7X00?ADTAG=amp

在 ClickHouse 进程中，CPU 的主频越高越好，通常建议使用 32 以上的机型，内存越大越好，一般每个线程分配 2GB 内存差不多就够了，当然越大的内存加速就会越明显。

磁盘通常普通的 HDD 磁盘都可以，RAID 方面 RAID-5、RAID-10 或者 RAID-50 都可以。如果查询数据量大、延迟要求比较低的话，使用 SSD/NVME 这些高速设备是最好的。

因为 ZK 节点不能混布，如果混布会出现很多的问题，比如相互影响导致集群无法工作，如果数据量在 TB 级别的时候，会选择一个 SSD 盘之类的高速设备。

我们整理了一些基础的参数：

lmax_threads: 查询使用的线程数量，默认为核数一半；

lmax_memory_usage: 单次查询允许使用的内存量；

lmax_memory_usage_for_all_users：ClickHouse 进程允许使用的内存量, 通常需要考虑为 OS 预留内存；

lmax_bytes_before_external_group_by: GROUP BY 操作使用内存超过该阈值后， 数据会写入磁盘，建议设置为 max_memory_usage/2；

lmax_concurrent_queries: 最大并发数限制；

lmax_bytes_before_external_sort: order by 排序溢写磁盘阈值；

lbackground_pool_size: 后台线程组 。

在使用层面也有一些建议：

避免全表扫描

-查询是需要指定分区

-避免使用 SELECT *

-GROUP BY 需要指定 LIMIT 子句

常用请求使用物化视图预计算， 例如监控⻚面，报表大盘等

关联查询时慎用 JOIN，可以考虑优先使用 IN 解决

JOIN 查询有损性能

-小表在右

-减少参与 JOIN 运算的数据量 (无谓词下推)

数据写入

-避免小批次写入

-批量写入数据中不宜包含过多分区

-适当调大后台 merge 线程数 background_pool_size

分布式表提供查询，代理 + 本地表提供数据写入

合理规划ZK集群配置以及参数调整建议

-数据规模在 TB 级别，建议使用 SSD 磁盘

-开启自动清理数据功能

为用户设置配额

下面我们讲一下查询方面的优化。最简单的来说，对于一条 SQL 语句，我们要看它的延迟，如果延迟的结果不一样，我们就会通过日志和其他的方式来看，哪些数据被扫描了、扫描了多少数据、用到内存多少、有没有写出到磁盘、使用了哪些条件，甚至可以查看执行计划，这些就是查询优化常规的步骤。

最新版本的 ClickHouse，已经提供了 explain 命令，可以看整个查询的执行计划，这样查询语句合理不合理都可以再次调整，比以前方便很多，以前通过日志后台看，这对很多的其他开发者是不太友好的。