
1.概述
转载:添加链接描述
相信很多同学在刚开始使用clickhouse的时候都有遇到过该异常,出现异常的原因是因为MergeTree的merge的速度跟不上目录生成的速度, 数据目录越来越多就会抛出这个异常, 所以一般情况下遇到这个异常,降低一下插入频次就ok了,单纯调整background_pool_size的大小是治标不治本的。
我们的场景:
我们的插入速度是严格按照官方文档上面的推荐”每秒不超过1次的insert request”,但是有个插入程序在运行一段时间以后抛出了该异常,很奇怪。
问题排查:
排查发现失败的这个表的数据有一个特性,它虽然是实时数据但是数据的eventTime是最近一周内的任何时间点,我们的表又是按照day + hour组合分区的那么在极限情况下,我们的一个插入请求会涉及7*24分区的数据,也就是我们一次插入会在磁盘上生成168个数据目录(文件夹),文件夹的生成速度太快,merge速度跟不上了,所以官方文档的上每秒不超过1个插入请求,更准确的说是每秒不超过1个数据目录。
case study:
分区字段的设置要慎重考虑,如果每次插入涉及的分区太多,那么不仅容易出现上面的异常,同时在插入的时候也比较耗时,原因是每个数据目录都需要和zookeeper进行交互。
M.参考
【clickhouse】clickhouse 同时查询数过多 Too many simultaneous queries
当使用ClickHouse时,遇到'Too many parts. Merges are processing significantly slower than inserts'异常,通常是由于MergeTree的合并速度无法跟上数据插入速度导致。本文分析了一个场景,即使按官方建议的每秒1次插入请求,但由于特定数据特性,每次插入可能涉及大量分区,加速了目录生成,从而引发异常。解决方法包括调整插入频次和谨慎设计分区字段,以减少与Zookeeper的交互次数。
1856

被折叠的 条评论
为什么被折叠?



