墨天轮访谈 | OceanBase 白超：海量数据管理，为什么选择 OceanBase？

2022 年 5 月 11 日
本文字数：3887 字
阅读完需：约 13 分钟

分享嘉宾：白超（大窑）OceanBase 解决方案架构师、前蚂蚁集团数据库团队 DBA 专家
整理：墨天轮社区

导读

大家好，我是白超（花名：大窑），在过去的几年中，作为蚂蚁集团数据库 SRE 团队成员，经历了历年的双 11 大促，深度参与了交易支付、数字金融、国际站点等多个业务的数据库存储架构升级工作。今天分享的内容包含两个方面，一是介绍 OceanBase 的技术架构特点，另一方面也想从蚂蚁集团自身业务演进发展的角度来谈谈，为什么OceanBase是互联网行业海量数据并发业务需求的必然选择。

互联网行业数据库面临的挑战

当前互联网行业对于数据库提出了很多挑战，随着业务形态的发展演进，数据增长速度越来越快。不管是私有部署，还是云数据库，也都同样面临着规模越来越大，实例数越来越多的情况。

首先从效率上，因为 DBA 需要运维的实例数更多了。不同的业务线，不同的应用，面临不同问题的时候，DBA 的幸福感是很低的，时间是碎片化的。对于业务来说，感知就是数据库本身的容量防御能力不足，应急时效也难以保证，比如电商大促、直播、秒杀等场景上，很多时候支撑能力是不够的。

其次在成本上，数据增长的速度是非常快的。尤其从疫情发生以来，很多场景线上化的趋势更加明显。包括线上支付，线上购物等场景越来越多。从而引发的订单数量，以及用于实时分析的场景数据增速明显加快。在此场景下，体现到数据库资源上会发现机器需求增多，与之对应的存储需求增大，但 CPU 利用并不充分。尤其遇到节日促销或类似双 11，618 等并发场景备战时，是需要提前做扩容，往往需要提前很长时间就开始准备机器资源。

第三，传统的单机数据库，比如 Oracle 或者互联网行业常用的 MySQL 都有一些痛点，是不得不面对的。比如数据量太大时，很多时候就要选择拆库，在这个过程中又要引入中间件，本身增加了一定的复杂度会侵入业务，对于 DBA 又添加了一些新的挑战。比如随业务发展表变得很大，需要做一些 DDL 表结构的变更。在传统数据库的场景下，这些变更都会存在较大的风险，甚至有阻塞业务的可能。

再比如说缓存穿透，高连接数达到数据库极限；主备切换看似成功了,其实只是集群层面成功，DNS 或者虚拟 IP 等并没有切换成功；容灾场景下的脑裂，丢数据问题等这些都是在过去使用传统数据库时面临的常见问题。

图 1 互联网行业下数据库的挑战

蚂蚁数据库架构的三代升级史

随着互联网行业的发展，对数据库提出了越来越高的要求——除了“提效率”与“降成本”，还有“解痛点”。传统数据库在处理业务需求时遇到了很多的问题，这些问题在蚂蚁也都经历过，首先我来简单讲讲蚂蚁集团数据库的演进过程。

第一代数据架构是构建在 IOE 的基础之上——IBM 的小型机、Oracle 的商业数据库，还有 EMC 的共享存储。随之带来的运维成本非常高，同时稳定性的挑战也非常大的。随着业务的快速发展，这套架构已经完全没有办法适应业务发展的增速。

以当时的支付宝为例，因为它本身金融交易的属性，拥有非常大规模的 Oracle RAC 集群，然而这种架构本身的扩容是有上限的，当扩容一定规模的情况时，数据库性能的边际效应已经非常明显了，无法再提升数据库的容量，这些都是业务增长情况下必须要面对的问题。因此从支付宝业务发展的角度出发，为了解决这些问题，蚂蚁数据库整体架构演进到第二阶段：中间件+拆分+单元化。

随之诞生的是第二代架构，第二代架构的主体仍然是传统单机数据库——也就是 Oracle 和部分 MySQL，加上蚂蚁自研的分布式中间件，某种程度上解决了业务的水平和垂直的扩展能力。但即便如此仍然有不少难题亟待解决，例如：机房级故障的快速恢复和强一致性保障、跨库跨分片事务、全局一致性、自动负载均衡以及复杂 SQL 的执行能力。

业务井喷式的发展对底层的数据库提出了更高的要求，这些要求包括更高的稳定性，快速恢复能力和极致的弹性能力等，为了解决这些问题，我们需要的是一套全新的方案和架构，也就最终演进到了以 OceanBase 为核心的第三代数据存储底盘。

图 2 蚂蚁数据库的三代演进

OceanBase 集群架构

ceanBase 是不基于任何开源产品，完全自研的原生分布式关系数据库。下面我将进一步介绍 OceanBase 是如何在高速增长业务中，在一个个真实的业务需求下不断创新和打磨的，首先我们来看 OceanBas 的集群架构。

OceanBase 是一个存储无共享的架构，如下图例子所示，这个 OceanBase 集群中有 6 台 OBServer 被分成了 3 个 Zone，在实际部署中可能这三个 Zone 会存在于三个机房，其中 Zone1、Zone2、Zone3 的数据是完全对等的，这样设计的能够实现当任意一个机房不可用时，出现断电或者网络“孤岛”现象时，也不会影响 OB 整体对业务应用的服务。因此第一个特点是 OceanBase 集群架构中所有的节点都是对等的，每个节点有独立的管控、SQL、事务以及存储引擎，整个系统没有任何单点。

OceanBase 中的数据以分布式的方式进行存储，这样为数据库的线性扩展性提供了理论基础，自动实现访问路由、策略驱动负载均衡。同时 OceanBase 的集群架构还具有高可用和强一致的特性，通过 multi-Paxos 分布式协议的工程实现，确保数据（日志）持久化在多数派节点成功，少数派故障时能够做到数据不丢失，故障转移自动完成。

图 3 OceanBase 集群架构

OceanBase 如何支撑海量并发的互联网业务？

1、OceanBase 的特性与优势

OceanBase 的第一个特性是多租户+存储压缩，能够大幅提高资源利用率，降低成本。

大集群将长尾应用的多实例 MySQL/Oracle 统一进行管理，有效提高资源密度，消除存储碎片。同时多租户的特性实现数据库内核级虚拟化，满足数据安全隔离的同时，提供基于业务画像的可伸缩计算资源、同时通过 Leader 打散实现混部。

图 4 OceanBase 特性：多租户+存储压缩

OceanBase 数据库使用基于 LSM-Tree 的存储引擎，能够有效地对数据进行压缩，并且不影响性能，可以降低用户的存储成本。

在支撑支付宝某业务从 Oracle 迁移到 OceanBase 中，实现了数据库占用存储区空间由 100TB 减少到 33TB。

图 5 OceanBase 基于 LSM Tree 的存储

此外，OceanBase 能够原生的实现水平无限扩展与迁移均衡流控。

在水平扩展过程中仅需 OCP 发起操作，内核负责数据迁移和内部强校验，当均衡完成后新的节点自动开始提供服务。同时 OceanBase 的数据均衡迁移速度远高于传统数据库逻辑迁移的速度。

图 6 OceanBase 特性：水平无限扩展+迁移均衡流控

在上面的内核特性支撑下，OceanBase 得以实现快速的弹性扩缩容。如下图所示，当需要扩容时，能够快速地将数据水平负载均衡至下方的新添加三个节点，由此实现集群翻倍的读写能量，过程中对应用透明，区别于传统数据库单点写的架构，OceanBase 可以实现全副本的 leader 打散，这也为超高并发写入的业务提供了基础。