作者：金长龙
爱可生测试工程师，负责DMP产品的测试工作
先前在做OB存储引擎这块学习的时候，对 OceanBase 的分层转储和 SSTable 这块有些细节就懵懵的，比如L0层的 mini SSTable 的每次生成是否就计入转储次数，L0层到L1层转储的时机以及和 minor_compact_trigger 之间的关系等。 今天就这部分内容做个更细致的探究，试图更深入的理解 OceanBase 的分层转储。
一、LSM-Tree
首先来看一下 LSM-Tree（全称是Log-Structured Merge Tree），当下许多较新的数据库都会选择LSM-Tree作为存储结构，比如TiDB、Cassandra、OceanBase等。LSM-Tree的优势是顺序写，提升了整体写入性能。
LSM-Tree 大致可以分为两部分：
- Memtable: 常驻内存的 KV 查找树 + 无序的 WAL 文件
- SSTable (Sorted String Table): 一组存储在磁盘的不可变文件，存储有序的键值对
写入流程
1、同步写 Memtable
先将数据写入 WAL 文件，然后修改内存中的 AVL，因此最优情况下，每次写操作只有一次磁盘 I/O。
删除操作并不会直接删除磁盘中的内容，而是将删除标记（tombstone）写入 Memtable。当 Memtable 增大到一定程度后，则会转换为 Immutable Memtable 并产生一个新的 Memtable 接受写操作。
2、异步写 SSTable
后台会启动一个合并线程，当 Immutable Memtable 达到一定数量，合并线程会将其写入磁盘（Flush），生成 Level 0 的 SSTable 文件。
当 Level N 的 SSTable 文件数量到达阈值之后，会进行合并压缩（Compaction）操作，在 Level N+1 生成新的 SSTable 文件。
SSTable 分为多层，单个文件的大小通常是上一层的 10 倍，每层可以同时包含多个 sst file，每个文件由多个 block 组成，其大小约为 32K，是磁盘 IO 的基本单位。
第 Level i (i > 0) 层的 SSTable 满足：
- 第 i 层所有文件均由 i - 1 层的 SSTable 合并排序而来，可以通过设定阈值（文件个数…）来控制合并的行为
- 文件之间是有序的，且每个文件的 key 集合不会与其他文件有交集（Level 0 的 SSTable 除外）
Compaction 策略
常用的 Compaction 策略有 Classic Leveled、Tiered、Tiered & Leveled 、FIFO 等，简单介绍下前3种。
1、Classic Leveled
Classic Leveled 模式下每一层都是独立的"Sorted Run" ，代表是按Key排序且同层sst file之间的Key值没有重合，数量大小是逐层增大。相邻的两层sst file比称之为fanout(扇出)，每次做Compaction的条件是Ln层大小达到了阈值，将Ln层数据与Ln+1层数据进行合并。由于每次做Compaction都将Ln层数据写入到Ln+1中，写放大情况会比较严重， 比如L1 ，L2 两层fanout是10，那么L1层写满后与L2层做排序合并，重写生成新的L2层，那么写放大最坏情况下等于fanout
2、Tiered
Tiered 模式与 Classic Leveled 的区别在于每一层的sst file之间Key有重合的，每层有多个"Sorted Run"，每次做Compaction都是同层先做合并生成一个新的sst file写入到下一层中，这里与Leveled最重要区别是写入到下一层后不再需要排序合并、重写，因为Tiered每层存在多个"Sorted Run"，那么写放大最坏情况下为1。但是相比于Leveled，会有读放大和空间放大会比较严重。
3、Tiered & Leveled
Tiered & Leveled 模式是指对于层级较小的 Level，数据量比较小，写入的数据较新，被更新的可能性比较大，使用 Size-Tiered 模式减少写放大问题；对于层级较大的 Level，SSTable 的数据量较大，数据比较旧不太容易被更新，使用 Leveled 模式减少空间放大问题。
二、OceanBase的分层转储
OceanBase 数据库的存储引擎就是基于 LSM-Tree 架构的设计，也是划分为内存中的MemTable 和磁盘上的SSTable。OceanBase 将磁盘上的 SSTable 划分为三层，使用的是 Tiered & Leveled 的 Compaction 策略，在 L0 层使用 Tiered 模式，在 L1 层、L2 层使用 Leveled 模式。
OceanBase 中的 Compaction 分为三种类型：Mini Compaction、Minor Compaction、Major Compaction。 其中Major Compaction指的是大合并，我们先不谈，这里只说一下Mini Compaction和Minor Compaction。
Mini Compaction (转储)
Mini Compaction 是一种 Tiered 类型的 Compaction，核心就是释放内存和数据日志，内存中的 Frozen MemTable 通过 Mini Compaction 变成磁盘上的 Mini SSTable。
Mini Compaction 在OceanBase设计里代表的就是一次转储，对应的类型是 MINI_MERGE
Minor Compaction
随着用户数据的写入，Mini SSTable 的数量会逐渐增多，在查询时需要访问的 SSTable 数量会增多，会影响查询的性能。Minor Compaction 就是将多个 Mini SSTable 合成一个，主要目的是减少 SSTable 的数量，减少读放大问题。当 Mini SSTable 的数量超过阈值时，后台会自动触发 Minor Compaction。
Minor Compaction 细分为两类：
1、L0 -> L0
Tiered 类型的 Compaction，将若干个 Mini SSTable 合成一个 Mini SSTable，放置于 L0 层。 对应的类型是 MINI_MINOR_MERGE
2、L0 - > L1
Leveled 类型的 Compaction，将若干个 Mini SSTable 与 Minor SSTable 合成一个新的 Minor SSTable，放置于 L1 层。 对应的类型是 MINOR_MERGE
实验（使用社区版OceanBase 4.0.0.0）
测试创建的租户ob_bench，内存2G。几个主要参数设置为
memstore_limit_percentage = 50
freeze_trigger_percentage = 20
minor_compact_trigger = 2
_minor_compaction_amplification_factor = 25
major_compact_trigger = 9999 （我们本次实验仅是想>探索L0、L1级的Compaction，不希望触发大合并，所以该参数设置一个极大值）
实验一：在持续数据流的情况下，观测L0, L1层转储的时机
1、创建测试库sysbench，用sysbench工具创建1张表sbtest1、数据100W。
租户每触发一次转储 memtable dump flush的数据必然是包含许多表的，我这里只创建1张业务表，仅是希望后续测试时业务变更相对集中
sysbench /usr/share/sysbench/oltp_insert.lua --mysql-host=172.30.134.1 --mysql-db=sysbench --mysql-port=2881 --mysql-user=root@ob_bench --tables=1 --table_size=1000000 --report-interval=10 --db-driver=mysql --skip-trx=on --db-ps-mode=disable --create-secondary=off --mysql-ignore-errors=6002,6004,4012,2013,4016 --threads=10 --time=600 prepare
2、先通过视图DBA_OB_TABLE_LOCATIONS找到sbtest1对应的TABLET_ID，然后通过GV$OB_TABLET_COMPACTION_HISTORY查询到在创建100W数据过程中，已经触发了4次MINI_MERGE和1次MINI_MINOR_MERGE
3、对sbtest1持续的写数据，观测sbtest1表级的转储情况
sysbench /usr/share/sysbench/oltp_insert.lua --mysql-host=172.30.134.1 --mysql-db=sysbench --mysql-port=2881 --mysql-user=root@ob_bench --tables=1 --table_size=1000000 --report-interval=10 --db-driver=mysql --skip-trx=on --db-ps-mode=disable --create-secondary=off --mysql-ignore-errors=6002,6004,4012,2013,4016 --threads=10 --time=600 run
测试总结：
官方对于参数minor_compact_trigger的解释：“minor_compact_trigger 用于控制分层转储触发向下一层下压的阈值。当该层的 Mini SSTable 总数达到设定的阈值时，所有 SSTable 都会被下压到下一层，组成新的 Minor SSTable。” https://www.oceanbase.com/docs/community-observer-cn-10000000000900778
如上测试时我们设置的minor_compact_trigger = 2，按理解在每两次触发MINI_MERGE之后，就会触发一次MINOR_MERGE，把L0层的SSTable下压到L1层。 实际测试下来发现未必如此，当达到minor_compact_trigger的阈值后，必然会触发Minor Compaction，但它可能是L0层上的MINI_MINOR_MERGE（同层数据合并），也可能是L0->L1层的MINOR_MERGE（数据下压到下一层）。 但是具体什么情况下，触发哪种Minor Compaction，在官方文档只是介绍会受隐藏参数_minor_compaction_amplification_factor控制，但是具体如何影响的 也并没有给到相应的观测手法。
附：官网对参数 _minor_compaction_amplification_factor的解释：“_minor_compaction_amplification_factor控制 L0 层内部多个Mini SSTable转储的时机，默认为 25。当所有Mini SSTable的总行数达到 Minor SSTable 的写放大系数比例后，才会触发 L1 层转储，否则触发 L0 层转储。当 L1 层不存在Minor SSTable 时，所有Mini SSTable行数到指定阈值（由 minor_compact_trigger 控制）后才会触发 L1 层转储。”
实验二：alter system minor freeze 是否真的在L1层做一个MINOR_MERGE类型的compaction ？
1、同实验一的参数配置，且 minor_compact_trigger = 2
先对sbtest1表记录做一次update，然后手动执行alter system minor freeze;（因为我们实验观测的是指定表的merge情况，所以在minor freeze之前要做一次update操作，主要是保证memtable中有对该表操作的记录）
如上我们看到，alter system minor freeze之后只是做了一次MINI_MERGE，并没有到L1层。
我们再执行一次alter system minor freeze;
这一次我们发现在做了一次MINI_MERGE之后，触发了MINI_MINOR_MERGE。
我们可以继续这样做下去，最终我们发现 alter system minor freeze实际上做的是MINI_MERGE，在MINI_MERGE之后具体是否会触发MINI_MINOR_MERGE 或 MINOR_MERGE，还是会受实验一里面所提到的参数minor_compact_trigger 和 _minor_compaction_amplification_factor的控制。
2、同实验一的参数配置，但设置minor_compact_trigger = 0
同样是多次执行alter system minor freeze，每次执行后观察merge情况。
可以看到在minor_compact_trigger = 0时，当内存中的memtable dump flush到L0层后，会立刻下压到L1层， 这点同官方文档中的解释是一致的。
测试总结：
通过实验二的测试我们发现，alter system minor freeze真正做的是形成一个mini sstable (MINI_MERGE)，在MINI_MERGE之后是否还会触发其他的merge，同样是受参数minor_compact_trigger 和 _minor_compaction_amplification_factor的控制。 并且指令中的minor freeze实际上并不是特别准确，因为看到minor总会让人想到L1层，如果改成mini freeze会更合适一些。
参考资料
https://www.modb.pro/db/608302
https://www.oceanbase.com/docs/community-developer-advance-0000000000634015
https://www.modb.pro/db/610025
https://ask.oceanbase.com/t/topic/31400011
