其原因是于Row的粒度过于细，访问成本过高。具体分析是：由于Append更新，导致Page的物理位置常规性发生变化。这里可以采用Page层面甚至是SSt层面的路由进行进行管理。如果是在Row粒度上，要采用Row级别粒度的路由信息。路由信息大概在50倍的膨胀，路由信息难于管理，并且在Compaction过程中（后面会提到）开销也很高（因为移动数据的时候要改Row的路由信息）

由上述更新方式，导致Page的版本链较长。较长的版本链会导致CPU访问性能下降、IO次数变多。

Compaction的目标：

有上述分析可以得出，Compaction的目标是：

回收空间：回收过期数据的存储空间

降低版本链：（RocksDB的版本链就是L0的文件 + 多层的查找方式《待确认》）

Compaction的原则：

控制写入放大：

有目的的合并：减少版本链

可回收数据的标识：

RocksDB Compaction 成本分析（逐层缓存，Batch合并）：

写入放大：

从L1到L2层的Compaction开始分析：

每层的存储，从范围上几乎是相当的，不同的是每层的数据量。因此造成了即每层单位数据量能够覆盖的数据范围是逐层下降的。从层上来看，密度是逐层上升的，即最后一层密度是100%。倒数第二次，密度是10%。

逐层缓存：RocksDB利用这个特征，可以保证数据下层过程中，每层的写放大都是10 +1。因为Ln层单位数据量覆盖的数据范围是Ln+1层的10倍，因此需要10个Ln+1层的数据块才可以满足Ln层的数据范围。所以是10 + 1。

所以总的写入放大是 4 + 11 （n-1），在2TB-3TB这个量级的数据量下，n=5

因此RocksDB的写入放大：

在update场景，写入放大很低，因为分层结构天生支持冷热分离。写入放大是37，可以按n=4计算。
在Insert场景，写入放大可能更低，对于主键这种递增插入的话，写入放大很低了，不涉及到合并。在Batch基础上可以做到个位数。对于二级索引这种随机插入的方式，由于二级索引本身数据量就较少，按照全量250GB计算，也是在37左右。
所以整体来看，RocksDB的写入放大在40左右，或者40以内。

同时由于数据存储有较好的空间冷热属性（至少相对于写操作是这样），因此在空间回收过程中更有针对性。

有目的的合并：

通过数据有序，有目的的合并，减少逻辑Page上的版本链。

BwTree(LLAMA) 合并成本分析（这个可能不准）：

由于论文在GC部分描述不清楚，且没有开放源码，所以首先描述我认为的问题、解决方案以及根据解决方案计算的写放大。

存在的问题：

内存版本链长度，降低CPU开销。---这个还好，RocksDB也存在内存链的访问，具体是在计算BloomFilter的时候需要访问。所以这个不是太大，比如在7-8以内都还可以。
存储上的版本链长度，导致读IO较高。--- 这里RocksDB是通过布隆过滤器实现1%的误判，来减少读IO的可能。
空间回收的IO成本，它的空间是日志这种数据搬迁的方式，没有天生实现冷热分离。

解决方案：

merge delta record：内存中根据链表长度定期Merge
将merge后的，新生成的delta record 持久化，减少磁盘上版本链的长度。降低IO开销（会增加部分写放大）。

======================================================

如果换成热点数据的10%的增量数据的话，实际上也不会有很大空间。大概百分之一？1TB大概有10GB？

感觉BwTree的问题在于IO不可控上，相比RocksDB，可以通过BloomFilter和BLockIndex，来保证命中率。降低IO次数。

同时，合并和Append Update-D是互斥的。

可以存在这样的策略：每个update-D同时记录链表长度，从某个链表节点就可以知道deltalink长度。

目的性差一些，存储都是无序的。这块也可以参考CF搞成关系性强一些的存储方案。但对于某一个表还是无序的。

因为目的性较差，所以在Merge Base和Delta链时，开销会高一些。

整体来看：

缩减版本链的写放大是在10 = 1 + 1（4个delta merge一次） + 10 = 12

空间清理写放大好像会多一些：

为了读取某个delta需要把周边的都读上来。

<未完>

Append写入方式的收益和成本分析

Append写入收益：

Append成本分析：

首先分析Append方式对数据访问的影响：