Clickhouse 表 MergeTree Engine 不断填充“INSERT INTO ... FORMAT CSV”查询，从空开始。平均输入速率为每秒 7000 行。插入发生在几千行的批处理中。当并发执行 SELECT 查询时，这会对性能产生严重影响。如Clickhouse文档所述，系统最多需要10分钟来合并特定表的数据(重新索引)。但这并没有发生，因为表格不断被填充。
这在文件系统中也很明显。表格文件夹有数千个子文件夹，索引过度分段。如果数据摄取停止，几分钟后表格将完全合并，子文件夹的数量会变成十几个。
为了解决上述弱点，缓冲引擎用于缓冲表数据摄取 10 分钟。因此，缓冲区最大行数平均为 4200000。
初始表最多滞后 10 分钟，因为缓冲区保留了最近摄取的行。表格最终被合并，其行为与表格停止填充几分钟的情况相同。 但是，对应于缓冲区和初始表组合的缓冲区表变得越来越慢。
从上面可以看出，如果表是连续填充的，它就不会合并，索引也会受到影响。有没有办法避免这个弱点？
最佳答案
表数据目录下的子文件夹个数不是那么有代表性的数值。
的确，每个子文件夹都包含一个由排序(索引)行组成的数据部分。如果多个数据部分合并为一个新的更大的部分，则会出现新的子文件夹。
但是，合并后不会立即删除源数据部分。有一个 <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 会在内部进行此类检查。 ，它会减慢插入速度，但如果它大于 parts_to_throw_insert=300它将中止插入。
关于buffer - 当 Clickhouse 表连续填充 INSERT INTO 时，SELECT 查询性能影响，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/48171764/