Clickhouse表MergeTree引擎不断填充“INSERT INTO ... FORMAT CSV”查询，从空开始。平均输入速率为每秒7000行。插入发生在几千行的批次中。当SELECT查询同时执行时，这会对性能产生严重影响。如Clickhouse文档中所述，系统最多需要10分钟来合并特定表的数据（重新索引）。但这种情况并没有发生，因为桌子不断填充。
这在文件系统中也很明显。表文件夹有数千个子文件夹，索引过分。如果数据提取停止，几分钟后表就完全合并，子文件夹的数量变为十几个。
为了遇到上述缺点，使用缓冲引擎缓冲表数据摄取10分钟。因此，缓冲区最大行数平均为4200000。
由于缓冲区保留了最近摄取的行，因此初始表最多还剩10分钟。该表最终被合并，其行为与表已停止填充几分钟的情况相同。 但是缓冲区表（对应于缓冲区和初始表的组合）变得非常慢。
从上面可以看出，如果表连续填充，则表示不合并，索引会受到影响。有没有办法避免这种弱点？
答案 0 :(得分：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。
此外，如果分区中活动部分的数量大于parts_to_delay_insert=150，ClickHouse会在内部进行此类检查，它会减慢INSERT的速度，但如果它大于parts_to_throw_insert=300，它将中止插入。