技术分享 | LSM-Tree 和 OceanBase 分层转储

一、LSM-Tree

• Memt

  able
  : 常驻内存的 KV 查找树  +

  无序的 WAL 文件
• SS

  Table (Sorted Strin

  g Table)
  : 一组存储在磁盘的不可变文件，存储有序的键值对

  
  

写入流程

1、同步写 Memtable

2、异步写 SSTable

• 第 i 层所有文件均由 i - 1 层的 SSTable 合并排序而来，可以通过设定阈值（文件个数...）来控制合并的行为

• 文件之间是有序的，且每个文件的 key 集合不会与其他文件有交集（Level 0 的 SSTable 除外）

Compaction 策略

常用的 Compaction 策略有 Classic Leveled、Tiered、Tiered & Leveled 、FIFO 等，简单介绍下前3种。

1、Classic Leveled

2、Tiered

3、Tiered & Leveled

Tiered & Leveled 模式是指对于层级较小的 Level ，数据量比较小，写入的数据较新，被更新的可能性比较大，使用 Size-Tiered 模式减少写放大问题；对于层级较大的 Level ， SSTable 的数据量较大，数据比较旧不太容易被更新，使用 Leveled 模式减少空间放大问题。

二、OceanBase 的分层转储

Mini Compaction (转储)

Minor Compaction

1、L0 -> L0

2、L0 - > L1

Leveled 类型的 Compaction，将若干个 Mini SSTable 与 Minor SSTable 合成一个新的 Minor SSTable，放置于 L1 层。对应的类型是 MINOR_MERGE

实验（使用社区版 OceanBase 4.0.0.0）

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层转储的时机

租户每触发一次转储 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

先通过视图 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 = 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控制，但是具体如何影响的 也并没有给到相应的观测手法。

实验二：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 ;

2、同实验一的参数配置，但设置 minor_compact_trigger = 0

同样是多次执行 alter system minor freeze ，每次执行后观察 merge 情况。

测试总结：

通过实验二的测试我们发现，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://ask.oceanbase.com/t/topic/31400011