蚂蚁自研数据库OceanBase拿下世界第一

最近国庆休假，抖音、头条等个性化推荐，一直在鼓吹“OceanBase拿下世界第一”，“破世界纪录”，妥妥的标题党。目前在DB-Engines排名的数据库超过300多种，关系型数据库也有100多种。如果OceanBase能在DB-Engines 排名中，别说第一，能够挤进前十也是非常厉害了。

在我看来，OceanBase只不过是一个定制化数据库，定制化数据将来也一定会流行起来，即“特别场景特别对待”。定制化数据库无非就两种目的。一是方便使用，在上面再封装一层API接口，毕竟学习也是要成本的，就像华为的SDS，底层还是Cassandra数据库；二是性能优化，方法有很多，包括去掉不常用的功能，做成轻量级；或者减少磁盘IO，多使用内存临时存储等。

下面是最近一条很火的新闻，希望中国在这一块能够真正做到突破！

OceanBase到底是什么类型数据库？

OceanBase是一个支持海量数据的高性能分布式关系型数据库系统，实现了数千亿条记录、数百TB数据上的跨行跨表事务，由淘宝核心系统研发、运维、DBA、广告、应用研发等部门共同完成。在设计和实现OceanBase的时候暂时摒弃了不紧急的DBMS的功能，例如临时表，视图(view)，研发团队把有限的资源集中到关键点上，当前 OceanBase主要解决数据更新一致性、高性能的跨表读事务、范围查询、join、数据全量及增量dump、批量数据导入。

研发背景：

应对双十一、聚划算、秒杀以及银行国库券销售等短时间突发大流量的场景：

1. 短时间内大量用户涌入
2. 短时间内业务流量非常大，数据库系统压力非常大
3. 一段时间（几秒钟、几分钟、或半个小时等）后业务流量迅速或明显回落

架构：

OceanBase是“基线数据（硬盘）”+“修改增量（内存）”的架构，如下图所示：

 

即整个数据库以硬盘（通常是SSD）为载体，新近的增、删、改数据（“修改增量”）在内存，而基线数据在保存在硬盘上，因此OceanBase可以看成一个准内存数据库。这样的好处是：

1. 写事务在内存（除事务日志必须落盘外），性能大大提升
2. 没有随机写硬盘，硬盘随机读不受干扰，高峰期系统性能提升明显；对于传统数据库，业务高峰期通常也是大量随机写盘（刷脏页）的高峰期，大量随机写盘消耗了大量的IO，特别是考虑到SSD的写入放大，对于读写性能都有较大的影响
3. 基线数据只读，缓存（cache）简单且效果提升
4. 线上OceanBase的内存配置是支撑平常两天的修改增量（从OceanBase 1.0开始，每台OceanBase都可以写入，都承载着部分的修改增量），因此即使突发大流量为平日的10-20倍，也可支撑1~2个小时以上。 

 

一个问题是：修改增量在内存，大概需要多大的内存？即使按双11全天的支付笔数10.5亿笔，假设每笔1KB，总共需要的内存大约是1TB，平均到10台服务器，100GB/台。

 另一个问题是：在类似双十一这种流量特别大的场景中，就像前面说到的，OceanBase内存能够支持峰值业务写入1~2个小时以上，之后OceanBase必须把内存中的增删改数据（“修改增量”）尽快整合到硬盘并释放内存，以便业务的持续写入。整合内存中的修改增量到硬盘，OceanBase称为每日合并，必然涉及到大量的硬盘读写（IO），因此可能对业务的吞吐量和事务响应时间（RT）产生影响。如何避免每日合并对业务的影响呢？OceanBase通过“轮转合并”解决了这个问题。

 众所周知，出于高可用的考虑，OceanBase是三机群（zone）部署：

 

根据配置和部署的不同，业务高峰时可以一个机群（zone）、两个机群（zone）或者三个机群（zone）提供读写服务。OceanBase的轮转合并就是对每个机群（zone）轮转地进行每日合并，在对一个机群（zone）进行每日合并之前，先把该机群（zone）上的业务读写流量切换到另外的一个或两个机群（zone），然后对该机群（zone）进行全速的每日合并。因此在每日合并期间，合并进行中的机群（zone）没有业务流量，仅仅接收事务日志并且参与Paxos投票，业务访问OceanBase的事务响应时间完全不受每日合并的影响，仅仅是OceanBase的总吞吐量有所下降：如果先前是三个机群（zone）都提供服务则总吞吐量下降1/3，如果先前只有一个或两个机群（zone）提供服务则总吞吐量没有变化。

 轮转合并使得OceanBase对SSD十分友好，避免了大量随机写盘对SSD寿命的影响，因此OceanBase可以使用相对廉价的“读密集型”SSD来代替传统数据库使用的相对昂贵的“读写型”SSD，而不影响性能。此外由于轮转合并对服务器的CPU使用、硬盘IO使用以及耗时长短都不敏感（高峰期的传统数据库在刷脏页的同时还要优先保证业务访问的吞吐量和事务响应时间，刷脏页的CPU及IO资源都非常受限），因此OceanBase在每日合并时可以采用更加高效的压缩或者编码算法（比如压缩或编码速度略慢，但压缩率较高、解压缩很快的算法），从而进一步降低存储成本并提升性能。

总结：OceanBase产品定制成分太重，通用性差，别家很难用，但是设计理念可以借鉴。