Clickhouse(ck) 报错 Too many parts (300) 解决方案

一、错误信息

DB::Exception: Too many parts (300). Parts cleaning are processing significantly slower than inserts (version 21.4.6.55 (official build))

二、产生原因

too many part异常原因：当数据插入到[clickhouse]表时，每一批插入都会生成对应parts文件，clickhouse后台会有合并小文件的操作。当插入速度过快，生成parts小文件过多时，clickhouse无法以适当的速度合并这些parts时会报上面这个错误。

客户端查看分片数量：

SELECT
    database,
    table,
    engine,
    active,
    count(*) AS parts_total,
    round(sum(rows) / 10000, 2) AS rows_w,
    round(((sum(bytes) / 1024) / 1024) / 1024, 2) AS size_GB
FROM system.parts
WHERE active = 1
GROUP BY
    database,
    table,
    engine,
    active
ORDER BY size_GB DESC
LIMIT 10;

显示结果：

从中可以看出磨人的300，数量远远不够的

三、解决方案

1、调大后台Merge线程池数量
通过backbackground_pool_size调整merge线程大小，默认是32，这个结合ClickHouse服务器进行适当调整，不宜过大
2、ClickHouse存储方式优化
ClickHouse默认Wide，我们可以针对业务场景特点和数据量，对于一定数据量（条数&大小两个方面）以下，选择Compact，这样可以减少merge压力和时间，针对超过的使用wide。

3、调整config.xml参数
我测试了多partition和多表同时插入崩溃的次数和时间基本一样，所以就是拉大插入的间隔，每次插入数据量大一些，如果还有这个问题，就把参数调大。参数修改后，我这边基本上就没再报错。

<merge_tree>
       <parts_to_delay_insert>600</parts_to_delay_insert>
	<parts_to_throw_insert>600</parts_to_throw_insert>
	<max_delay_to_insert>5</max_delay_to_insert>
<max_suspicious_broken_parts>5</max_suspicious_broken_parts>
</merge_tree>

4、
每次插入进行一次 ，但这会严重影响速度不推荐

optimize table logs.deer_nginx_access final

5、排查发现失败的这个表的数据有一个特性，它虽然是实时数据但是数据的eventTime是最近一周内的任何时间点，我们的表又是按照day + hour组合分区的那么在极限情况下，我们的一个插入请求会涉及7*24分区的数据，也就是我们一次插入会在磁盘上生成168个数据目录(文件夹)，文件夹的生成速度太快，merge速度跟不上了，所以官方文档的上每秒不超过1个插入请求，更准确的说是每秒不超过1个数据目录。

合理设置分区，分区字段的设置要慎重考虑，如果每次插入涉及的分区太多，那么不仅容易出现上面的异常，同时在插入的时候也比较耗时，原因是每个数据目录都需要和zookeeper进行交互。

6、以上都不行的话，查看分片、行数和存储数量最多的表，单表存储超过4、5个T的数据就会时常报此问题，建议设置过期时间，或者采用其他数据库存储过大数据量的表。