在 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 命令，可以看整个查询的执行计划，这样查询语句合理不合理都可以再次调整，比以前方便很多，以前通过日志后台看，这对很多的其他开发者是不太友好的。
posted on
