作者:金长龙
爱可生测试工程师,负责DMP产品的测试工作
本文来源:原创投稿
*爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。
先前在做OB存储引擎这块学习的时候,对 OceanBase 的分层转储和 SSTable 这块有些细节就懵懵的,比如L0层的 mini SSTable 的每次生成是否就计入转储次数,L0层到L1层转储的时机以及和 minor_compact_trigger 之间的关系等。 今天就这部分内容做个更细致的探究,试图更深入的理解 OceanBase 的分层转储。
首先来看一下 LSM-Tree(全称是Log-Structured Merge Tree),当下许多较新的数据库都会选择LSM-Tree作为存储结构,比如TiDB、Cassandra、OceanBase等。LSM-Tree的优势是顺序写,提升了整体写入性能。
LSM-Tree 大致可以分为两部分:
先将数据写入 WAL 文件,然后修改内存中的 AVL,因此最优情况下,每次写操作只有一次磁盘 I/O。
删除操作并不会直接删除磁盘中的内容,而是将删除标记(tombstone)写入 Memtable。当 Memtable 增大到一定程度后,则会转换为 Immutable Memtable 并产生一个新的 Memtable 接受写操作。
后台会启动一个合并线程,当 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 满足:
常用的 Compaction 策略有 Classic Leveled、Tiered、Tiered & Leveled 、FIFO 等,简单介绍下前3种。
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
Tiered 模式与 Classic Leveled 的区别在于每一层的sst file之间Key有重合的,每层有多个"Sorted Run",每次做Compaction都是同层先做合并生成一个新的sst file写入到下一层中,这里与Leveled最重要区别是写入到下一层后不再需要排序合并、重写,因为Tiered每层存在多个"Sorted Run",那么写放大最坏情况下为1。但是相比于Leveled,会有读放大和空间放大会比较严重。
Tiered & Leveled 模式是指对于层级较小的 Level,数据量比较小,写入的数据较新,被更新的可能性比较大,使用 Size-Tiered 模式减少写放大问题;对于层级较大的 Level,SSTable 的数据量较大,数据比较旧不太容易被更新,使用 Leveled 模式减少空间放大问题。
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 是一种 Tiered 类型的 Compaction,核心就是释放内存和数据日志,内存中的 Frozen MemTable 通过 Mini Compaction 变成磁盘上的 Mini SSTable。
Mini Compaction 在OceanBase设计里代表的就是一次转储,对应的类型是 MINI_MERGE
随着用户数据的写入,Mini SSTable 的数量会逐渐增多,在查询时需要访问的 SSTable 数量会增多,会影响查询的性能。Minor Compaction 就是将多个 Mini SSTable 合成一个,主要目的是减少 SSTable 的数量,减少读放大问题。当 Mini SSTable 的数量超过阈值时,后台会自动触发 Minor Compaction。
Minor Compaction 细分为两类:
Tiered 类型的 Compaction,将若干个 Mini SSTable 合成一个 Mini SSTable,放置于 L0 层。 对应的类型是 MINI_MINOR_MERGE
Leveled 类型的 Compaction,将若干个 Mini SSTable 与 Minor SSTable 合成一个新的 Minor SSTable,放置于 L1 层。 对应的类型是 MINOR_MERGE
测试创建的租户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,不希望触发大合并,所以该参数设置一个极大值)
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 层转储。”
先对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的控制。
同样是多次执行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.cnblogs.com/buttercup/p/12991585.html
https://www.modb.pro/db/608302
https://www.oceanbase.com/docs/community-developer-advance-0000000000634015
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。