当 Clickhouse 表持续填充 INSERT INTO 时，SELECT 查询性能影响答案

【问题标题】：SELECT queries performance impact when the Clickhouse table is continuously populated with INSERT INTO当 Clickhouse 表持续填充 INSERT INTO 时，SELECT 查询性能影响
【发布时间】：2018-06-18 16:46:44
【问题描述】：

Clickhouse 表 MergeTree 引擎不断填充“INSERT INTO ... FORMAT CSV”查询，从空白开始。平均输入速率为每秒 7000 行。插入以几千行为单位进行。当 SELECT 查询同时执行时，这会对性能产生严重影响。如 Clickhouse 文档中所述，系统最多需要 10 分钟来合并特定表的数据（重新索引）。但这并没有发生，因为表格是不断填充的。

这在文件系统中也很明显。表格文件夹有数千个子文件夹，并且索引被过度分割。如果数据摄取停止，几分钟后表格将完全合并，子文件夹的数量变为十几个。

为了解决上述弱点，使用了 Buffer Engine 缓冲表数据摄取 10 分钟。因此，缓冲区的最大行数平均为 4200000。

初始表最多延迟 10 分钟，因为缓冲区保留了最近提取的行。表格最终被合并，其行为与表格停止填充几分钟的情况相同。但是对应于缓冲区和初始表组合的缓冲区表正在变得越来越慢。

从上面看来，如果表是连续填充的，则它不会合并，并且索引会受到影响。有没有办法避免这个弱点？

【问题讨论】：

您能否提供一个可重现的表创建语句，您可以使用它吗？

标签： buffer clickhouse

【解决方案1】：

表数据目录中子文件夹的数量并不是那么具有代表性的值。

确实，每个子文件夹都包含一个由已排序（索引）行组成的数据部分。如果多个数据部分合并为一个新的更大的部分，则会出现新的子文件夹。

但是，合并后不会立即删除源数据部分。有一个<merge_tree> 设置old_parts_lifetime 定义了一个延迟，在该延迟之后将移除部件，默认设置为8 分钟。此外，cleanup_delay_period 设置定义了后台清理器检查和删除过时部件的频率，默认为 30 秒。

因此，在提取开始后大约 8 分 30 秒内有这么多子文件夹是正常的。如果您无法接受，您可以更改这些设置。

仅检查表中活动部分的数量是有意义的（即，尚未合并到更大的部分中的部分）。为此，您可以运行以下查询：SELECT count() FROM system.parts WHERE database='db' AND table='table' AND active。

此外，ClickHouse 会在内部进行此类检查，如果分区中的活动部分数量大于 parts_to_delay_insert=150，它会减慢 INSERT，但如果大于 parts_to_throw_insert=300，它将中止插入。

【讨论】：