ClickHouse参数配置
转载⾃：
因为 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 命令，可以看整个查询的执⾏计划，这样查询语句合理不合理都可以再次调整，⽐以前⽅便很多，以前通过⽇志后台看，这对很多的其他开发者是不太友好的。
发布评论