OceanBase存储引擎与备份恢复

笨鸟之路 2021-04-19

3546

介绍 OceanBase 存储引擎前，我们先来了解下传统数据库存储引擎的一些问题。

传统关系型数据库一般采用“堆表”的架构,磁盘上有表空间,会划分出不同的段(Extend),每个段再划分为若干页(Block），磁盘有一个根节点，段和页是随着数据的不断插入来不停分配的。在内存里，跟磁盘表空间对应的是 Buffer Pool，无论应用读取数据，还是修改数据，都需要把数据从硬盘的表空间装载到内存里，在内存里完成数据的读和写，修改后的数据就是“脏数据”，这些“脏数据”最终还是要落入到硬盘表空间里，内存的 Buffe Pool 和硬盘的表空间是一一对应的，也就是数据从哪里读出来的，也写回到哪里。

这就有一个问题，内存 Buffer Pool 的数据是相对紧凑、相对有序的。但是，在表空间上，有可能是非常离散的，比如图中所示，内存的 4 个页是紧凑的，但对应到硬盘上，四个页分布的非常分散。当内存中 Buffer Pool 的脏数据要写回硬盘表空间时，会有一个很严重的随机写的问题。这种随机写会导致严重的写放大，不仅影响写操作性能，而且会显著降低 SSD 的寿命，所以传统数据库一般使用高端读写型 SSD。

还有一个问题，数据的读取还是写，都是以页或者段为单位，即使要修改的数据很少，比如只是修改了 1 个页内的几个字节，也需要把整页更新到硬盘的表空间中，造成写放大。这种写放大是数据库架构带来的，跟 SSD 硬盘的写放大没有关系，即使使用传统的 SATA 或者 SAS硬盘，依然也存在这个问题。

( Log-Structured Merge-Tree日志结构合并树，总之记住它最大的特点就是写入速度快就行了)

OceanBase 是一个准内存数据库的架构，存储又采用 LSM Tree 的架构，可以有效解决随机写和写放大的问题。

OceanBase 把内存分为了两块，一块是 MemTable，用于写；一块是热点缓存，用于读。所有对数据的修改，比如 insert、update 等，都会先放到内存的 MemTable 中，所以可以认为 MemTable 是用于存储“脏数据”的。MemTable 中的数据不像传统数据库那样不定期的进行 check point 到硬盘中，它会在内存中保存较长时间，当内存空间快满的时候，或者到了某个固定的时间（比如凌晨 2 点这种系统不太繁忙的时段），或者由人工触发，把内存的一大批脏数据批量的写回到硬盘上，这个过程叫转储，转储的数据还是增量数据，只是已经落盘了，它还需要与硬盘的 SS Table 的基线数据进行合并，形成新的基线数据。

因此，OceanBase 相当于把传统数据库的多频次的、每次都是小数据量的 check point 变成不频繁的、每次都是大数据量的 check point。这可以带来三个好处：

1：内存的脏数据批量合并之后，顺序写入 SSD 硬盘的，避免了随机写，提高了写性能，延长了 SSD 寿命;

2：传统数据库，delete 操作之后的空间不知道什么时候会再用到，容易造成磁盘碎片。OceanBase 采用了 LSM Tree 架构，数据在磁盘上默认按主键有序排列，当内存里的大量的增量数据和磁盘基线数据合并时，会重新排序，然后以批量写的形式顺序写到硬盘上，可以很容易的把原有的碎片去掉，减少磁盘碎片，提升存储利用率；

3：因为每次写回到硬盘的数据量都很大，可以支持对很大一批数据进行采样，因此它的压缩比传统数据库要高，这块下一页会再详细讲解。

当应用要读取数据时，不能仅仅从基线数据或者热点缓存中读取数据，因为这些数据有可能被更新了，只是还没最后合并到基线数据中。因此，OceanBase 服务器还需要查看硬盘中的转储数据，以及内存中 MemTable 中的数据，确保读数据的强一致性。

因此，OceanBase 的“准内存数据库”+“LSM Tree 存储”的架构，不仅可以有效的提升性能，也可以极大的降低存储成本。

前面我们讲了，每次做数据合并的时候，写入到硬盘的数据量很大，OceanBase 可以对大数量进行采样后会有更好的压缩率。OceanBase 一般会进行两次压缩。

第一次是 encoding，会使用字典、RLE 等算法对数据做瘦身。字典编码的思想很简单，就是把重复性较高的数据进行去重，把去重后的数据建立字典，而把原来存放数据的地方存成指向特定字典下标的引用，比如图上这个例子，Rate-ID 这一列的很多数据是一样的，可以归纳成 4 类，实际表中直接引用即可。

第二次是通用压缩，使用 lz4 等压缩算法对 encoding 之后的数据再做一次瘦身，OceanBase 支持 snappy、lz4、lzo，zstd 等压缩算法，允许用户在压缩率和解压缩时间上做权衡。

因此，在使用相同的压缩算法下，OceanBase 通过高效的数据编码技术大大减少了存储空间。线下测试时，OceanBase 同 MySQL 最新版本 5.7 进行了对比，使用相同的块大小（16KB）、以及相同的压缩算法（lz4），同样的数据存放在 OceanBase 中，要比在 MySQL 5.7中平均节省一半的空间。数据压缩并不是以牺牲性能为代价的，OceanBase 写入（合并）性能较原有系统有了较大的提升，查询性能基本没有变化。

实际生产系统中，支付宝的一个业务迁移到 OceanBase 后，数据由 100T 压缩到了 33T，也充分证明了 OceanBase 的数据压缩效率。

OceanBase 支持全量备份和增量备份，全量备份是对存储层的基线数据进行备份，增量备份是通过 redo-log 备份，OceanBase 支持在线实时的全量和增量备份，对业务无感知。

备份支持 2 种介质，一种是阿里云 OSS 存储，另外一种是普通的 NFS。
NFS 需要一个公共目录，每个 OB Server 都可以访问，NFS 服务器为每台 OB Server 创建子目录，用于存储备份文件。
备份性能可以达到网卡的上限，约 1G 左右。
恢复性能，一般也可以达到 500 兆左右。
备份恢复最小粒度是租户，让备份和恢复更加灵活。
备份恢复数据方面，支持逻辑数据（比如用户权限、表定义、系统变量、用户信息、视图信息等）和物理数据。

oceanbase

文章转载自笨鸟之路，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

OceanBase存储引擎与备份恢复

评论