clickhouse merge工作原因和性能优化

标题Merges 工作原理与性能优化

标题工作原理

数据写入和初始存储:
当数据写入 ClickHouse 时，数据先存储在内存中，并以较小的块（parts）写入磁盘。
这些小的块最初写入磁盘时没有进行排序和压缩，称为初级数据片段。
合并触发:
合并过程由 ClickHouse 后台自动管理。后台进程会监控表中的数据片段，并根据预设的规则和阈值触发合并操作。
合并操作的触发条件包括：数据片段数量超过阈值、片段大小等。
合并操作:
后台进程选择若干个较小的数据片段进行合并。这个过程包括排序、去重和压缩。
合并过程中，ClickHouse 会读取选中的片段，将数据按主键排序，合并成一个新的更大的片段，然后将这个新片段写回磁盘。
删除旧片段:
新的合并片段创建并写入磁盘后，旧的、小的片段会被删除。
这个过程确保磁盘空间的有效利用，同时提升查询性能，因为查询时需要扫描的片段数量减少了。
并行和优先级:
ClickHouse 支持并行合并操作，但会根据系统负载和资源情况调整合并操作的优先级，以避免对在线查询性能的影响。
用户可以配置合并操作的并发度和资源使用情况。

标题性能优化

1、 background_pool_size
后台任务线程池的大小。后台任务包括数据同步、合并数据片段、删除旧数据、处理突变（mutations）等
GET_PART — 从另一个副本获取分片.
ATTACH_PART — 附加的部分, 可能来自我们自己的副本(如果在 detached 文件夹中找到). 您可以将其视为具有一些优化的 GET_PART , 因为它们几乎相同.
MERGE_PARTS — 合并分片.
DROP_RANGE — 删除指定分区内指定编号范围内的分片.
CLEAR_COLUMN — 注意：已弃用. 从指定分区删除特定列.
CLEAR_INDEX — 注意：已弃用. 从指定分区删除特定索引.
REPLACE_RANGE — 丢弃一定范围的零件并用新零件替换它们.
MUTATE_PART — 对分片应用一个或多个突变.
ALTER_METADATA — 根据全局 /metadata 和 /columns 路径应用alter修改.
老版本默认该参数配置是8 线程数过小 在加上数据复制同步任务死循环 导致其他任务处于等待状态 可以优化到16
24.3.3.102新版本默认值是:16
ClickHouse 出现 “找不到活跃的 part” 错误通常是因为数据丢失或数据分片不一致引起的。这可能与以下几个方面有关：
数据损坏或丢失：当 ClickHouse 期望在特定的分片中找到数据，但实际上数据丢失或损坏时，就会报错。这可能是由于磁盘故障、人为操作错误或其他原因导致的数据丢失。
分布式表配置不一致：如果在分布式表的不同分片中配置不一致，可能会导致某些分片认为它们应该具有的数据在其他分片中找不到，从而引发此错误。这可能是由于数据不一致的复制、分片键配置错误或拓扑变更等原因导致的。
分布式表元数据不一致：如果元数据状态不同步，例如某个节点认为分片仍处于活动状态，而其他节点认为该分片已不再活动，可能导致类似的问题。
数据过期或删除：如果在 ClickHouse 中进行了数据过期或删除操作，而某些查询仍在尝试访问已删除的数据，就可能会出现此类错误。
2、max_replicated_merges_in_queue
用于限制每个分片副本上队列中待处理的最大合并任务数量。这个参数对优化 ClickHouse 集群中的性能和资源利用率至关重要，特别是在处理具有大量数据和高并发操作的场景中
22版本默认值是:2
24.3.3.102新版本默认值是:1000
按照现场写入merge 情况优化参数
3、min_rows_for_wide_part 和 min_bytes_for_wide_part
最小行和最小字节触发合并操作
22版本默认值:1024 行 10485760(10MB)
24.3.3.102新版本默认值是:0 行 10485760(10MB)
适应小文件的写入可优化成0行 100 字节
4、max_bytes_to_merge_at_max_space_in_pool
合并调度程序会定期分析分区中分块的大小和数量，如果池中有足够的可用资源，则会启动后台合并。合并会一直进行，直到源分块的总大小大于
24.3.3.102新版本默认值是:150G
5、max_bytes_to_merge_at_min_space_in_pool
定义在可用磁盘空间不足（池中）的情况下可以合并的部分的最大总大小。这对于减少小部分的数量和Too many parts出错的可能性是必要的。合并通过将合并部分的总大小加倍来预订磁盘空间。因此，在可用磁盘空间较少的情况下，可能会发生这样的情况：有可用空间，但该空间已被正在进行的大型合并所预订，因此其他合并无法启动，并且每次插入时小部分的数量都会增加
24.3.3.102新版本默认值是:1048576 (1 MB)
6、number_of_free_entries_in_pool_to_execute_mutation
当池中的空闲条目数少于指定数量时，不要执行部分变更。这是为了留出空闲线程进行常规合并，避免“Too many parts”
Default value: 20
7、number_of_free_entries_in_pool_to_execute_optimize_entire_partition
当池中的可用条目数小于指定数量时，不要在后台执行优化整个分区（此任务在设置min_age_to_force_merge_seconds并启用时生成min_age_to_force_merge_on_partition_only）。这是为了留出空闲线程进行常规合并，避免“Too many parts”
Default value: 25
该设置的值number_of_free_entries_in_pool_to_execute_optimize_entire_partition应小于background_pool_size * background_merges_mutations_concurrency_ratio的值。否则，ClickHouse 将引发异常
8、parts_to_throw_insert
如果单个分区中活动部分的数量超过该parts_to_throw_insert值，INSERT则会中断并引发Too many parts (N). Merges are processing significantly slower than inserts异常。
Default value: 3000
23.6 版本之前都是：300
9、max_parts_in_total
如果表的所有分区中活动部分的总数超过了该max_parts_in_total值，INSERT则会中断并引发Too many parts (N)异常。
Default value: 100000
10、background_merges_mutations_concurrency_ratio
设置线程数与可并发执行的后台合并和突变数之间的比率。例如，如果比率等于 2 并 background_pool_size设置为 16，则 ClickHouse 可以并发执行 32 个后台合并。这是可能的，因为后台操作可以暂停和推迟。这是为了给小合并提供更多的执行优先级。您只能在运行时增加此比率。要降低它，您必须重新启动服务器。可以从配置文件中应用与background_pool_size设置相同的设置以实现向后兼容
每个线程分配多少个任务用于合并，默认是2。该参数的设置需要根据实际场景进行设置，如果小合并比较多，那么意味着一次合并并不能吃满一个CPU，那么此时一个线程分配两个合并任务，将有助于加速小part的merge，最典型的比如实时插入的场景。
如果每次插入的batch比较大，单个part比较大，那么意味着单次合并有可能将整个CPU跑满，此时如果还给单个线程分配2个合并任务，那么反而会拖累合并性能，此种场景建议值是1。
最终的合并任务个数 = background_pool_size * background_merges_mutations_concurrency_ratio。
您可以通过 SELECT metric, value FROM system.metrics WHERE metric LIKE ‘%background%’; 进行查看。
11、number_of_free_entries_in_pool_to_lower_max_size_of_merge
该配置属于merge_tree的设置。应该与background_pool_size一起更改。
当用于合并的线程任务池空闲的个数小于该值时，对比较大的part的合并暂时忽略不处理，这样做的目的是防止大part合并将线程池占满，无剩余资源用于小part合并，最终导致小part越积越多，出现"Too many parts(N)"错误。
要想充分发挥其威力，起到真正加速merge的作用，可以将该值设置为线程池的90%~95%。
此外，你可以设置下面这些参数配合使用：
合并后多大的part可以称之为一个大part（由参数max_bytes_to_merge_at_max_space_in_pool控制，默认150G）
在大合并中禁用直接IO（由参数min_merge_bytes_to_use_direct_io控制，默认10G），因为直接IO会绕过页缓存，因此通常会比较慢。
在merge比较慢，但是网络传输比较快的副本集群上，可以尝试使用execute_merges_on_single_replica_time_threshold配置。该配置是仅在其中一个副本上执行merge， 另一个副本会隔execute_merges_on_single_replica_time_threshold时间后再去拉取同步副本数据。
根据实际情况来决定，看是水平合并更好，还是垂直合并更佳。所谓水平合并，就是同时合并所有列。而垂直合并，是先merge表中的ORDER BY 列，然后再逐个merge其他列。这种合并方式会占用更少的内存，打开更少的文件，但与水平合并相比，需要更复杂的计算。
如果表特别多，还可以为调度程序提供更多的资源。这里所说的调度程序，就是指分配merge和一些内部管理的组件，主要是调整background_schedule_pool_size和background_common_pool_size。
检查表的schema，尤其是某些列的压缩算法，它虽然可以减小存储的空间，但是会严重影响merge的速度。
在进行插入时，尽量一个批次多插入，使每个part本身就足够大。需要参考以下配置：min_insert_block_size_bytes / min_insert_block_size_rows / max_insert_block_size。
检查是使用宽模式还是紧凑模式。宽模式指每个列都在一个单独的文件中，紧凑模式指多个列混合在一个文件中（可以从system.parts表查看）。默认情况下，min_bytes_for_wide_part=10，即part大于10（百万行），使用宽模式，否则使用紧凑模式。但有的时候，即使是较大的part（有特别多相对较小的列），使用紧凑格式也是有益的；或者相反，即使是较小的part（有少量的胖列），使用宽格式也是有益的。
考虑使用最近发布的 clickhouse 版本 - 它们默认使用压缩标记，这有利于减少 i/o

以上只是一些理论层面的建议，对于这些配置的优化，所有的调整和性能优化都应通过一些可重现的 "基准 "来控制，这样你就能确保这些优化是否真的如我们所期望的那样。毕竟生产环境千变万化，有些优化并不一定绝对有效。同时还要监控系统资源，包括CPU，内存，IO以及zookeeper的使用情况，以及merge线程池的使用情况：select * from system.metrics where metric like ‘%PoolTask’;

标题TTL 参数优化

1、ttl_only_drop_parts
当ttl_only_drop_parts设置为true时，ClickHouse 只会在部分中的所有行根据 TTL 配置已过期时删除整个数据部分。这意味着混合了过期和未过期行的部分将不会被删除；只有每行都已达到其 TTL 过期时间的部分才会被删除。
当ttl_only_drop_parts设置为false（默认值）时，ClickHouse 会正常处理 TTL 操作，这可能涉及删除过期的行并重写部分内容，即使只有部分行过期。