Write Amplification

问题描述

写放大在存储系统上基本上不可避免。

首先

1，磁盘级别就会有 比如SSD就会存在数据擦除导致写放大。

2，RAID Read-Modify-Write策略也会存在多写校验块的过程导致写放大。

3，存储系统中一般会为了保证数据一致性，会有类似mysqlde redo log的思路，就会存在一个多写log的过程，这样也会导致写放大。

4，LSM-tree写放大，金无足赤，人无完人，merge的compaction机制过程不可避免写放大，存在排序和重写过程，只能尽量优化。

所以Write Amplification也是clickhouse merge资源消耗的一部分，不可避免，我们做的就是如何优化merge中的一些性能消耗。

clickhouse 同样也做了一些相应的优化

merge过程中 存储两个矛盾的问题，查看源码

https://github.com/ClickHouse/ClickHouse/blob/master/src/Storages/MergeTree/SimpleMergeSelector.h

那就是parts数量和Write Amplification的矛盾

为了避免写放大，不可避免parts过多，为了减少parts过多，必然要做大量merge，减少查询和系统压力，那这样，就存在一个系统平衡系数'base'

clickhouse主要使用算法https://presentations.clickhouse.tech/hse_2019/merge_algorithm.pptx

主要做的操作是，尽量保证tree的平衡，越老年龄的parts越少merge，越大的约少merge

保证base是一个平衡的值，系统默认为5。

解决方案(Optimizations)

代码级别的base参数 好像是不能修改的，能做的优化主要就是如下

A)确实存在，当单机数据量写入很大的时候是有这样的问题的，需要将数据分发到不同的机器上,磁盘压力直接变为1/N

B)增加磁盘IO，做磁盘Raid，

C)控制好批量写入的大小，不能太大，需要根据业务情况控制，参考（Performance）。

clickhouse关于对处理写放大的策略issue

https://github.com/ClickHouse/ClickHouse/pull/155