您在 MergeTree 表上达到了 parts_to_throw_insert
设置。您可以使用以下命令监视给定表的活动部分数量:
select count(*) from system.parts where table = '<table_name>' and active == 1
插入 Clickhouse 的主要要求:您永远不应该每秒发送太多 INSERT
语句。理想情况下 - 每秒/每几秒插入一次。
因此,您可以每秒插入 100K 行,但只能使用一个大的批量 INSERT
语句。当您每秒向 *MergeTree 表发送数百/数千个插入语句时,您将始终遇到一些错误,并且无法通过调整某些设置来更改它。
如果您无法将大量插入组合到 *MergeTree 表之外的一个大型批量插入语句中 - 那么您应该在 *MergeTree 表之前创建缓冲表。
每个插入在
/var/lib/clickhouse/.../table_name/
中创建一个文件夹。在该文件夹中,每列有两个文件 - 一个包含数据(压缩),另一个包含索引。数据在这些文件内部按主键物理排序。这些文件夹称为“**部分**”。ClickHouse 在后台将这些较小的部分合并为较大的部分。它根据一些规则选择要合并的部分。合并两个(或多个)部分后,将创建一个较大的部分,旧部分将排队以供删除。您列出的设置允许微调合并部分的规则。合并过程的目标 - 是为每个分区留下一个大部分(或每个分区几个大部分,因为它们太大,不值得合并)。请查看 评论。
如果您创建新部分的速度过快(例如,通过进行大量小插入),并且 ClickHouse 无法以适当的速度合并它们(因此新部分比 ClickHouse 可以合并它们的速度更快出现) - 那么您会收到异常“合并处理速度明显慢于插入”。您可以尝试增加限制,但您可能会遇到这种情况,然后您会遇到由过多的文件/目录(如 inode 限制)引起的系统问题。
如果您同时插入多个分区,则该问题会按受插入影响的分区数成倍增加。
您可以尝试使用列出的设置之一或使用 max_insert_block_size / max_block_size / insert_format_max_block_size / max_client_network_bandwidth 来调整 clickhouse 的行为。但是:更好的解决方案是按预期速度插入数据。预期速度是:**每 1-2 秒插入一次,每次插入包含 10K-500K 行数据**。
因此,解决“合并处理速度明显慢于插入”的正确方法是调整每秒的插入次数和每次插入的行数。如果数据是逐行出现的,则使用批量插入将小插入组合成一个更大的插入。如果您一次有太多数据要插入,请限制巨大的插入。不要更改 clickhouse 内部机制,除非您真正理解它们意味着什么。
如果您的数据传输速度超过每秒 500K 行 - 您很可能需要在集群中添加更多服务器来处理该流量,而不是调整设置。
后台合并的速度通常取决于存储速度、使用的压缩设置、MergeTree 选项(合并算法 - 简单合并/聚合/求和/折叠等)以及使用的排序键。