本文嘉宾：杨传辉（花名：日照），蚂蚁集团研究员，OceanBase 创始成员和首席架构师。主导了 OceanBase 技术架构设计，实现分布式数据库在核心金融场景零的突破。同时，他也主导了 OceanBase TPC-C 测试并打破世界纪录。著有专著《大规模分布式存储系统：原理与实践》。

本文将带来他从业十几年的专业思考，期待与大家碰撞想法。

概要

自从 1970 年提出关系模型，关系数据库已经发展了 50 多年的时间，产生了一家市值曾经超过 2000 亿美金的公司，Oracle。然而，传统关系数据库采用集中式架构，无法解决互联网时代的可扩展和高并发问题，这次报告将与大家一起探讨下一代分布式数据库的设计。

关系数据库发展过程

关系数据库领域总共诞生了三位图灵奖得主：关系模型提出者 E.F.Codd，事务模型提出者 Jim Gray，以及 Michael Stonebreaker。

关系数据库也是计算机科学所有领域中图灵奖得主最多的，如果大家有志于获得图灵奖，关系数据库也是一个很不错的选择。分为几个流派：最知名的两个数据库都属于 Oracle 公司，分别是商业数据库 Oracle，以及收购的开源数据库 MySQL；IBM 是关系数据库理论的提出者，但发展不太好，并没有抓住关系数据库产业化的机会，反而成就了 Oracle，DB2 数据库目前主要应用在金融等行业的大机系统中；除了 Oracle、MySQL 和 DB2 以外的主流数据库都有一个共同的祖先：Ingres。Stonebreaker 除了发明 Ingres，也是 PostgreSQL，Vertica 等多个数据库的创始人。微软的 SQL Server 和 Sybase 数据库也源自 Ingres。

纵观分布式数据库的发展，我认为分布式数据库经历了三代：

• 第一代分布式表格系统是 NoSQL 系统，代表作是 Google Bigtable；
• 第二代分布式数据库支持可扩展的 SQL 处理，代表作是 Google Spanner；
• 第三代分布式数据库是透明扩展的企业级数据库，兼容传统集中式数据库，支持 HTAP 混合负载，且单机性价比很高，代表作是 OceanBase。

分布式数据库的核心技术

绝大部分技术来源于关系数据库

分布式数据库的绝大部分技术来源于关系数据库，而不是分布式系统，数据库领域的技术积累强于分布式领域。

首先，我们一起看看关系数据库的核心技术。学过计算机的同学都听过一句话：程序=数据结构+算法。存储对应关系数据库的“数据结构”，事务对应关系数据库的“算法”，SQL 是关系数据库的使用界面。除了存储、事务、SQL 这三个核心模块以外，关系数据库还支持数据类型、函数、存储过程等兼容性功能，以及性能、成本、安全、可靠等企业级特性。

关系数据库支持事务 ACID，很多大数据系统也会尽量把自己说成是数据库，然而，能成为数据库的根本原因还在于能够支持事务 ACID，从而应用到 Mission Critical 的核心业务场景。今天，我们经常提到一个词叫 HTAP 混合负载。其实，商业数据库一直都支持复杂查询和混合负载，即在同一套引擎同时支撑 OLTP 交易型负载和 OLAP 分析型负载。真实的企业级应用场景中，纯粹的 OLTP 和纯粹的 OLAP 都是比较少见的，往往都是既有 OLTP，又有 OLAP。很多互联网业务之所以很简单，只需要 KV 存储，原因在于互联网业务做了大量的改造，将本来属于数据库的逻辑往上移到了应用层。

关系数据库成功的经验

关系数据库之所以能够如此成功，我认为原因有三点：



第一，应用驱动创新，应用创新和技术创新相辅相成，产生了一个从理论到技术到产品再到商品的完整数据库产业；早期的 Oracle 版本也不好用，功能不完善甚至经常遇到稳定性故障，但是，通过应用创新驱动技术创新，让越来越多用户使用 Oracle，从而完成了产品技术迭代，战胜了 IBM DB2 等同时期的竞争对手，这才成就了我们今天看到的 Oracle；

第二，抽象与标准化，抽象关系模型和事务模型，将 SQL 语言和 TPC 测试标准化，从而让全球数据库厂商能够在同一个平台上良性竞争，共同促进；TPC 标准出来之前，每个数据库厂商都说自家的产品是最好的，有了 TPC 标准之后，再加上第三方中立的审计组织，到底是骡还是马，拉出来溜溜就知道了，数据库厂商也不要把太多精力放在市场宣传上，而是真正去优化数据库产品；

第三，追求极致性能，成功的关系数据库全部采用 C 语言实现，注重实现细节，优化代码路径的 CPU 指令数，在基础设施层面做到高性能，低延迟，从而大大简化应用。

当“封闭体系”遇到“开放互联网”

关系数据库架构的杰出代表是我们常说的 IOE 架构：I 指的是 IBM 小型机、大型机；O 指的是 Oracle 数据库；E 指的是 EMC 的存储。IOE 基于专用软硬件，本质上是一个封闭体系，这个体系的最大问题在于不够开放，产生了两个问题：

一是价格非常昂贵。摩尔定律大幅降低了开放的 X86 硬件的成本，而专用硬件无法享受技术红利，一套专用硬件往往需要上千万甚至上亿人民币；

二是几乎无法横向扩展，只能支持垂直扩展，通过购买更好的硬件来提升系统的处理能力，从而错过了云和分布式时代的技术变革。

传统集中式数据库面向的是封闭体系下的 Mission Critical 业务场景，处理的是少量用户最为关键的基础数据和事务数据，比如账户、交易数据；而互联网是开放体系，处理的是大量用户的全部行为数据，这些行为数据不仅仅包含基础数据和事务数据，也包含交互数据，也就是海量用户并发访问过程产生的日志。

这将导致两类问题：

一是现象级应用带来的可扩展和高并发需求。如天猫双十一零点峰值的流量是平常的几十上百倍，需要数据库系统具备快速弹性扩容的能力；

二是海量数据带来的分布式架构。集中式架构把硬件故障当成异常处理，而大规模分布式架构把硬件故障看成正常现象，这是一种新常态，需要在软件层面实现自动容错，且做到低成本存储。

互联网时代的分布式数据库

首先，让我们向大规模分布式存储系统的引领者 Google 公司致敬。

Google 最早在生产环境中应用大规模分布式系统，并且把用到的核心技术公开发表成三篇论文，也被成为“三驾马车”，分别是分布式文件系统 GFS，分布式计算系统 MapReduce，以及分布式表格系统 BigTable。这三个系统第一次提出将硬件故障当成正常现象的设计理念，并在软件层面实现自动容错，有一个总控节点 Master 处理元数据和全局调度，其它工作节点执行具体的存储和计算任务。

“三架马车”很好地支撑了 Google 早期的海量数据处理业务，奠定了 Google 基础设施的领先优势，从而支持搜索广告等业务快速发展。每个想要学习大规模分布式系统的同学都推荐精读这三篇论文，里面用到的技术到今天仍然没有过时，仍然是理解分布式数据库的基础。我所在的 OceanBase 团队也会定期开展论文阅读，帮助每个新加入的同学深入理解这三篇论文。

下面我们详细来看看这三代分布式数据库的发展过程。

第一代分布式数据库 NoSQL

第一代分布式数据库其实是 NoSQL 系统。为了实现可扩展，第一代分布式数据库牺牲了 SQL 和事务，不支持 SQL 语言，不支持跨机事务，只支持单行事务或者单机事务，部分 NoSQL 系统甚至牺牲一致性。11年到13年之间 NoSQL 系统很流行，当时很多人认为数据库性能瓶颈的根源在于 SQL，只要牺牲 SQL 语义，就能够一劳永逸地解决高并发场景下数据库面临的可扩展性和单机性能问题。当时有一些流行的说法，比如"SQL is dead"，"one size does not fit all"，走向了另一个极端，但是做着做着却发现 NoSQL 系统中用到的核心技术大多都源于关系数据库。OceanBase 团队 12 年也有争论，到底是走 NoSQL 路线还是坚持做关系数据库，最终我们还是决定做关系数据库，这才走到了今天。

最流行的两个 NoSQL 系统分别是 Amazon Dynamo 和 Google Bigtable。

他们的底层存储分别是一个分布式哈希表和一棵分布式 B+树。Dynamo 采用去中心化的设计，引入一致性哈希来做数据分布，并采用 NWR 协议，要求写入的副本个数 W 加上读取的副本个数 R 大于总副本数 N。Dynamo 系统最大的问题在于牺牲了一致性，需要用户处理冲突，这个做法最后证明是失败的，Amazon 后期设计的分布式存储系统 DynamoDB 就没有沿用这个做法，而是在内部通过 Paxos 协议保证强一致性。

Google Bigtable 构建在 GFS 之上，实现了强一致性，自动将表格划分为子表 tablet，实现了 tablet 的自动分裂与合并。Bigtable 只支持单行事务，之所以只有单行事务，我认为根本原因还在于分布式事务实现过于复杂，不容易做到高效。Bigtable 有两个开源的模仿者，一个是 Hypertable，另一个是今天非常流行的 HBase。

第二代分布式数据库

第一代 NoSQL 系统对用户很不友好，关系数据库的性能和扩展性问题也并不是因为支持 SQL，于是进一步产生了第二代分布式数据库。

第二代分布式数据库以 Google Spanner 为代表。Spanner 支持大部分 SQL，支持分布式事务，但不兼容 SQL 标准。Spanner 通过 Truetime 实现了分布式事务全局时间戳，保证了强一致性，但每次事务提交延时很高，牺牲了单机性能。Spanner 是第一个全球级的分布式数据库，很好地解决了 Scalable SQL 问题，但牺牲了关系数据库最核心的性价比等企业级特性。Spanner 适合应用在对扩展性要求特别高的特定应用场景，例如 Google 本身，但不适合应用在传统行业的 Mission Critical 业务场景。

第三代分布式数据库

第三代分布式数据库是透明扩展的企业级数据库，以 OceanBase 为代表。

第三代分布式数据库的设计理念是把复杂留给基础设施，把简单留给数据库使用者：业务开发人员和运维人员。

它的底层是可扩展的分布式架构，从而享受分布式技术的红利，如高可用、可扩展，兼容传统企业级数据库的功能，在同一套数据库引擎中支持 HTAP 混合负载，并同时，追求极致的单机性价比。

追求极致性价比这一点将从根本上影响分布式数据库的设计，举几个例子：

1) Google Spanner 系统通过 Truetime 机制获取全局时间戳，这个方案导致事务延迟太高，需要改变；

2) 分布式数据库可以划分为 SQL 层和存储层，Google Percolator 系统的事务和并发控制机制构建在存储层之上，采用松耦合的设计，影响性能。为了追求极致性价比，需要和传统关系数据库一样，把事务层放到存储层内部，采用紧耦合的设计。

3) 为了追求性能极致，需要扣实现细节，尽可能优化读写流程的 CPU 指令数，采用 C/C++ 语言实现，手动执行内存管理。

第三代分布式数据库：OceanBase

2021 年是 OceanBase 发展的第十一年，它的成长过程如下图：

2013 年之前，OceanBase 是一个分布式表格系统，不支持 SQL，应用在阿里电商平台，包括淘宝收藏夹，天猫评价，淘宝直通车等等。这个架构最大的优势在于相对简单，能够快速开发出来并在生产系统上线。

2014 年到 2017 年，OceanBase 开始支持 SQL 和 Paxos 高可用，逐步演化为一个可扩展的分布式数据库，首次做到在不依赖专用硬件的情况下，数据库节点故障完全不丢数据且 30 秒之内恢复。通过首创 Paxos 高可用秘方，OceanBase 成功击败其它开源数据库，全面支持支付宝交易、支付、账务等核心场景。

2017 年之后，OceanBase 开始服务更多的企业客户，成为一个透明扩展的企业级数据库。OceanBase 先后在 2019 年和 2020 年两次参加 TPC-C 测试，并取得世界第一的成绩。TPC-C 测试既验证了 OceanBase 的扩展能力，也验证了 OceanBase 的单机性能。

今天的 OceanBase 是一个透明扩展的企业级数据库，包含存储、事务和 SQL 三个核心引擎。

存储：OceanBase 的存储引擎是一个两级分区表加上 LSM 树。

两级分区表源于传统的关系数据库 Oracle，支持哈希分区、Range 分区，以及哈希和 Range 的各种组合分区，能够通过自动 Range 分区解决经常遇到的大账号热点问题。两级分区表最大的优势在于与传统关系数据库完全兼容，且 OceanBase 后台会自动地将不同分区均匀地打散到分布式集群中，对用户完全透明。LSM 树采用 Append only 和批量合并的设计，相比传统关系数据库的 B+树，LSM 树最大的优势在于压缩效率高，且支持对在线 OLTP 业务做压缩，从而大幅降低成本。传统关系数据库，例如 Oracle 或者 MySQL 也支持压缩，但是，传统关系数据库的压缩在 OLTP 业务往往是不打开的，只要打开，性能大幅降低，而 LSM 树没有这个问题。

事务：OceanBase 的事务引擎采用两阶段提交加 Paxos 的设计。

这个设计源于 2004 年两位图灵奖得主 Jim Gray 和 Lamport 联合发表的一篇论文。Jim Gray 几十年前就已经提出了两阶段提交协议，用于解决分布式事务多机一致性问题，然而，两阶段提交协议是一个阻塞协议，无法处理节点故障。当协调者或者参与者节点发生故障时，系统只能停服务。通过引入 Paxos，节点故障后 30 秒之内自动恢复，完全不丢数据，也不丢失正在进行中的分布式事务的状态，从而将两阶段提交协议由理论上升为大规模工业实践。有了支持容错的分布式事务之后，就可以在它之上实现分布式索引，分布式修改，分布式查询等完整关系数据库功能。

SQL：OceanBase 的 SQL 引擎面向 HTAP 混合负载设计。

纯粹的 100% OLTP 业务或 100% OLAP 业务都是很罕见的，绝大部分业务都是既有 OLTP 又有 OLAP，也就是 HTAP 混合负载。传统关系数据库把系统划分为两类：OLTP 交易型数据库和 OLAP 分析型数据库，并通过 ETL 系统实时或者定期将 OLTP 数据库的数据拉取到 OLAP 数据库。

这个方案面临两个问题：

1) 时效性，数据仓库有一个概念叫 T+1，这就是时效性导致的问题；

2) 数据一致性，数据仓库常出现数据不一致的问题，需要人肉订正。

OceanBase 通过同一套引擎同时处理 OLTP 和 OLAP 两种工作负载，大大简化了应用。有了 HTAP 处理能力之后，对于大部分中等规模的客户，只需要一套系统，不再需要多套系统。

极致性能：关系数据库最核心的企业级特性

TPC-C 是目前国际上唯一具有公信力的数据库功能与性能结合的公开检测标准。TPC-C 首先测试数据库的功能，只有功能满足与传统集中式数据库对标的 ACID 强一致特性之后，性能才有意义。

OceanBase 参加 TPC-C 测试，最大的意义并不是跑分有多高，而是证明了一点：基于分布式架构的企业级分布式数据库能够实现与集中式数据库完全对标的 ACID 强一致特性。

有了这一点支撑，由于分布式数据库能够通过增加服务器来提升系统的处理能力，自然能够跑出更好的结果。OceanBase 在 2019 和 2020 年先后取得 6088 万和 7.07 亿 tpmC 的成绩，排名世界第一。这也是分布式数据库第一次正式通过审计，测试基于公有云，采用与生产环境完全一致的通用机型。

被市场验证的企业级分布式数据库

OceanBase 应用在蚂蚁集团，支撑了包括蚂蚁集团交易、支付、账务、会员在内的全部核心业务的 100% 流量，今天我们在支付宝每一笔交易和支付操作背后的数据库都是 OceanBase。

除了蚂蚁集团之外，OceanBase 也应用在银行、保险、证券、运营商等行业的几百个客户的核心系统上。OceanBase 的业务还在快速增长中，也期待越来越多优秀人才加入到 OceanBase，一起为中国数据库硬核科技做贡献。

总结

最后做一个小结，传统集中式数据库包含存储、事务、SQL 这几个核心引擎，以及基于这些核心引擎之上的数据库功能和性能、成本、安全、可靠等企业级特性。

随着互联网时代的到来，为了处理海量用户的行为数据，集中式数据库的可扩展性和并发处理能力成为瓶颈。为了解决这个问题，分布式数据库经过了三次迭代：

第一次迭代是分布式存储系统，也称为 NoSQL，2013 年之前比较流行，基本思路是牺牲 SQL，牺牲事务、一致性和企业级功能，只支持简单的 KV 操作从而做到可扩展；

第二次迭代是分布式数据库，以 Google Spanner 系统为代表，支持可扩展的 SQL，在第一代 NoSQL 系统的基础之上引入了 SQL 和分布式事务，保证强一致性，但是不太注重 SQL 兼容性和性价比，单机性能往往比较差，系统天花板很低；

第三次迭代是透明扩展的企业级数据库，以 OceanBase 系统为代表。分布式架构对业务透明，且支持完备的兼容 MySQL 和 Oracle 的企业级功能，支持 HTAP 混合负载，采用 C 语言实现，单机性能和系统天花板很高。

我认为，关系数据库的未来必定是企业级分布式数据库。今天中国有几百家数据库公司，很多公司都在做分布式数据库。随着时间的推移，相信越来越多的公司会选择与 OceanBase 类似的技术路线，并逐步演进为透明扩展的企业级数据库。

今天的内容基于我十多年的行业摸索和思考，知识在交流中才更有价值，希望我的分享能给大家一些启发，也希望大家少走一些 OceanBase 曾经走过的“弯路”，欢迎留言讨论，更期待与大家一起把中国数据库产业做大做强。

附《下一代分布式数据库设计思考》QA

OceanBase 没有表锁，怎么做到 DML 和 DDL 的？

A：OceanBase 的存储引擎采用了 schema 和数据分离的设计，简单的 DDL（例如增加列和删除列）只需要更新 schema即可，查询时再根据当时的 schema 解析数据。以删除列为例，schema 只是标记删除，读取时再过滤删除列，数据列的物理删除操作在后台合并时执行。

OceanBase 要做 HTAP，那 OceanBase 有什么理由，能既做好 A，又做好 P 呢？资源隔离怎么做得好呢？

A：这里需要避免走极端，HTAP 可以认为是 OLTP 的增强，提升了实时 OLAP 的能力，但在超大数据量的离线 OLAP 分析上相比离线数仓或者大数据的技术还有一定的差距。只不过当 HTAP 数据库出现之后，对于绝大部分中等规模的客户，HTAP 数据库非常方便，没有必要为了最后一点极致的分析性能而单独部署一个数仓，只需要一套 HTAP 数据库就足够了。

想了解下 OceanBase 云原生的想法，shared nothing 和存算分离的关系。

A：我认为这两种技术不矛盾。存储计算分离解决了存储可扩展的问题，但写入不可扩展，shared nothing 进一步解决了写能力可扩展的问题。存储计算分离有一个好处是弹性能力会更好，因为计算节点迁移成本更低。

OceanBase 同时支持 shared nothing 和存储计算分离，可以把存储计算分离看成是类似 Oracle 的 ASM（Automatic storage management，自动存储管理）。

OceanBase 在追求极致性价比方面做了哪些努力？

A：首先，采用紧耦合的设计，存储和事务模块紧耦合从而做极致优化，并尽量做到事务处理本地化。其次，采用 C 语言实现并优化读取路径的 CPU 指令数，严格把关代码细节，追求极致。

紧耦合设计对于性能极致很关键的，比如 MySQL 为了支持多存储引擎，采用单机松耦合设计，带来的问题就是写两份 redo log，Oracle 就只需要写一份数据。分布式数据库紧耦合和松耦合的性能差异就更加明显了。

本次分享时间太短了，意犹未尽，后续还有什么活动可以提前剧透一下吗？

A：后续 OceanBase 技术团队会更加频繁地和大家交流，之后每个月会举行直播或者各城市 Meetup，每周会输出一个分布式数据库技术短视频（视频号 ID：OB小话唠），与大家保持高频率交流，期待大家的持续关注，更准备了非常有趣的周边作为礼物送给大家。

  直播预约  

在《下一代分布式数据库设计思考》的分享中，OceanBase 首席架构师杨传辉给大家分享了他从业十几年的数据库的经历，着重介绍了分布式数据库的三代演变。

是不是还没听够？4 月 28 日 19:00，他将延续三代分布式数据库演进思路，介绍第三代分布式数据库的一体化设计。

扫码预约直播

你将获得：

1) 持久化与日志。如何通过分区级日志实现动态扩展，以及 Paxos 和 Raft 协议的权衡。

2) 并发控制与事务。如何通过多版本并发控制和两阶段提交实现事务的隔离性和原子性，并且尽可能优化性能。

3) HTAP 混合负载。通过行列混合存储、cgroup 隔离等技术兼顾 OLTP 和 OLAP 两种工作负载，尽量优化批处理的 CPU 指令数。

点击链接，预约直播间 https://live.bilibili.com/7844562?visit_id=2vah1hdf4uo0 ，一起探索下一代分布式数据库一体化设计。