OceanBase的存储引擎
OceanBase本质上是一个基线加增量的存储引擎,跟关系数据库差别很大。 存储机制是LSM树(Log-Structured Merge Tree,日志结构合并树),这也是大多数NoSQL使用的存储机制。OceanBase采用了一种读写分离的架构,把数据分为基线数据和增量数据,其中增量数据放在内存里(MemTable),基线数据放在SSD盘(SSTable)。虽然不是刻意设计的,但OceanBase确实比传统数据库更适合像双十一、秒杀以及优惠券销售等短时间突发大流量的场景:
短时间内大量用户涌入,短时间内业务流量非常大,数据库系统压力非常大
一段时间(几秒钟、几分钟、或半个小时等)后业务流量迅速或明显回落
OceanBase是“基线数据(硬盘)”+“修改增量(内存)”的架构,如下图所示。
整个数据库以硬盘(通常是SSD)为载体,对数据的修改都是增量数据,只写内存,新近的增、删、改数据(修改增量)在内存,所以DML是完全的内存操作,性能非常高。而基线数据在保存在硬盘上,因此OceanBase可以看成一个准内存数据库。这样做的好处有:
写事务在内存(除事务日志必须落盘外),性能大大提升。
没有随机写硬盘,硬盘随机读不受干扰,高峰期系统性能提升明显;对于传统数据库,业务高峰期通常也是大量随机写盘(刷脏页)的高峰期,大量随机写盘消耗了大量的IO,特别是考虑到SSD的写入放大,对于读写性能都有较大的影响。
基线数据只读,缓存(cache)简单且效果提升。
读数据的时候,数据可能会在内存里有更新过的版本,在持久化存储里有基线版本,需要把两个版本进行合并,获得一个最新版本。同时在内存实现了Block Cache和Row cache,来避免对基线数据的随机读。当内存的增量数据达到一定规模的时候,会触发增量数据和基线数据的合并,把增量数据落盘(称为转储,又叫minor freeze)。同时每天晚上的空闲时刻,系统也会自动每日合并(简称合并,major freeze)。
OB为何采用这种特殊架构,简要来说,就是基于这样一条理论基础——尽管数据库本身的数据量越来越大,记录数越来越多,但每天的增删改数据量并不大,仅仅只占数据库总量一个很小的比例。 这个情况不只是对支付宝的支付数据,对其它大部分数据库实际应用情况也适用,是OB建立上述存储引擎的重要理论基础。
LSM树存储引擎和B树存储引擎一样,同样支持增、删、读、改、顺序扫描操作,而且通过批量存储技术规避磁盘随机写入问题。当然凡事有利有弊,LSM树和B+树相比,LSM树牺牲了部分读性能,用来大幅提高写性能。