近日， OceanBase CTO 杨传辉受邀出席全球知名开发者论坛 Stack Overflow 的最新一期播客节目，与 Stack Overflow 高级内容创作官 Ryan Donovan 展开对话。双方围绕分布式数据库的可靠性、一致性保障、HTAP 架构以及 AI 时代分布式数据库的发展趋势等热点话题进行了深入探讨和交流。杨传辉不仅揭秘了 OceanBase 的“前世今生”，还分享了其背后许多鲜为人知的趣闻轶事。

 

Ryan Donovan                                                                         杨传辉

Stack Overflow 高级内容创作官                                       OceanBase CTO

本期播客中的精彩摘要

对于 HTAP 来说

分布式数据库是最佳选择

首先，如果我们将 OLTP 系统和 OLAP 系统合并，数据量相比之前将大幅增加，分布式数据库能够处理更大规模的数据。其次，分布式数据库中每一份数据都有多个副本。我们可以在主副本中使用行存来处理 OLTP，在次级副本中使用列存来处理OLAP。只要我们有一个优秀的 SQL 优化器，就可以找到最佳方式来支持混合工作负载。

分布式数据库有很多种

原生分布式SQL数据库是终极解决方案

实现分布式数据库的方式有很多种，比如常见的 NoSQL 数据库、分库分表。相比之下，我认为原生分布式 SQL 数据库才是终极解决方案。它既能实现高可用性和可扩展性，又能提供完整的 SQL 支持。

高连续性业务

城市级容灾是必选项

对于支付宝等要求高业务连续性的企业，仅仅具备数据中心级别的容灾是不够的，城市级别的灾难恢复能力不仅是可选项，而是必选项，尤其是对于 OLTP 数据库来说，这一点至关重要。

相比独立向量数据库

通用数据库加向量插件是未来发展方向

向量数据库目前主要有两种类型：一种是独立的向量数据库，另一种是带有向量插件的通用数据库，也就是“SQL + AI”。后者在传统 SQL 数据库的基础上引入了向量存储和处理能力。我认为，带有向量插件的通用数据库是未来的发展方向。OceanBase 在 2024 年 10 月 正式发布了向量能力。

AI 时代数据库的一大技术趋势是

「混合搜索」

混合搜索指同时支持 SQL、NoSQL 和向量等多种数据模型。如果能在通用数据库的基础上支持向量功能，就可以通过一个 SQL 查询实现混合搜索。我认为这将大大简化 AI 技术栈，帮助企业更快地进行 AI 应用开发。

下文为对话全文（中文翻译）

Ryan：大家好，欢迎收听 Stack Overflow 播客，在这里，我们会讨论一切和软件与技术相关的话题。我是 Ryan Donovan。我负责编辑博客，也是 Stack Overflow 播客的联合主持人。在今天的节目中，我们将与 OceanBase 的首席技术官杨传辉一起聊聊他们如何打造一个能够处理超过十亿客户数据的数据库。欢迎来到 Stack Overflow 播客。

杨传辉：大家好。Ryan 你好。

Ryan：在节目开始之前，我们通常会先了解一下我们的嘉宾，听听他们是如何踏入软件和技术领域的。那么您的“入行故事”是怎样的呢？

杨传辉：我在大学学习计算机科学期间，偶然读到了谷歌在分布式计算和存储领域发表的几篇研究论文。其中，Google File System 这篇论文给我留下了深刻的印象。这是一篇非常有名的文章，也让我对这一技术产生了浓厚的兴趣。

毕业后，我加入了中国的一家搜索引擎公司，负责构建大规模分布式存储系统。2010 年，我发现阿里巴巴在大规模数据处理方面有巨大的需求，于是我加入了阿里巴巴，从零开始打造 OceanBase。

OceanBase 最初是为阿里巴巴和支付宝内部使用而开发的，如今经过多年的发展，它已经在全球范围内被超过 2000 名客户采用。在这个过程中，我与大量开发者进行了深入交流，尤其是在中国。我还基于自己在大规模分布式存储方面的经验，撰写了许多技术博客，并出版了一本技术书籍。这些内容受到了众多开发者的广泛欢迎。

Ryan：分布式存储是一项非常有趣的解决方案，而 OceanBase 的成长历程更是与支付宝紧密相连。能否请您分享一下支付宝在交易型数据库方面曾经遇到的挑战，以及 OceanBase 是如何针对性地解决这些问题的？

杨传辉：当然。支付宝是一个在全球范围拥有超过 10 亿用户的支付平台。当你到中国旅行时，完全不需要携带现金，只需通过扫描支付宝的二维码，就能轻松完成所有支付需求。此外，在中国，我们有“双十一”购物节，其流量是“黑色星期五”购物节的几十倍。应对如此巨大的流量冲击，对数据库来说是一个巨大的挑战。

当时，支付宝的一些团队尝试通过分库分表来解决可扩展性问题，比如在 MySQL 或 Oracle 上进行分库分表。但这种方法使得应用和数据库的维护变得更加复杂，甚至有些业务无法进行分库分表。因此，从 2010 年起，我们决定从零开始打造一个高度可扩展的数据库。

但你知道，从头开发一个全新的数据库是非常困难的，我们花了很长的时间让支付宝真正开始采用 OceanBase。最初，OceanBase 仅被用于阿里巴巴和支付宝的非核心业务。花了将近五年时间，OceanBase 才被我们的第一个核心业务——支付宝的交易业务所采用。又过了三年时间，支付宝的所有核心业务，包括交易、支付、账务等，都从 Oracle 和 MySQL 迁移到了OceanBase。OceanBase 也成为了支付宝唯一的数据库。

在这个过程中，我们最大的竞争对手是 MySQL 分库分表解决方案。我认为，与其相比 OceanBase 最大的优势是我们解决了无损故障恢复的问题。通过采用基于多数派共识的协议，OceanBase 实现了 RPO（恢复点目标）= 0。这意味着在发生故障时，无论是服务器故障、数据中心故障，甚至是整个城市的灾难，OceanBase 都可以自动恢复，且保障零数据丢失。此外，OceanBase 的存储引擎相比 MySQL 和 Oracle 更具成本效益。以支付宝为例，在迁移到 OceanBase 后节省了大约 70% 的数据库存储成本。

Ryan：如果我没听错的话，你们的分布式数据库采用的不是分库分表方案？

杨传辉：没错，我们采用的不是分库分表方案，我们是原生分布式数据库。

Ryan：听上去很酷，能不能详细讲讲这里的“分布式”是什么意思？比如，如果你们没有使用分库分表，那么背后的复制机制是怎么实现的？以及，这里的“原生分布式”到底是指什么呢？

杨传辉：其实，实现分布式数据库的方式有很多种。比如常见的 NoSQL 数据库，像 MongoDB、HBase、Cassandra、Redis 等。NoSQL 数据库在可扩展性和支持灵活的数据模型方面确实有优势，但通常不支持完整的 SQL 功能。一旦涉及到事务支持、复杂查询和数据一致性等问题，NoSQL 数据库就显得力不从心了。

另一种方案是分库分表，比如基于 MySQL 的分库分表、基于 PostgreSQL 的分库分表，这些都是很流行的方案。分库分表用一种非常直观的方式解决了数据库的可扩展性问题，但它会让系统变得更加复杂，对于应用程序的开发和数据库的维护来说，难度都会大幅增加。

相比之下，我认为原生分布式 SQL 数据库才是终极解决方案。它既能实现高可用性和可扩展性，又能提供完整的 SQL 支持。

目前，也有一些原生分布式 SQL 数据库，比如 Google Spanner、YugabyteDB、CockroachDB，还有 OceanBase 等等。OceanBase 的优势在于更高的性能。在 SysBench 基准测试中，针对简单的 OLTP 工作负载，OceanBase 的单节点性能是其他分布式 SQL 数据库的 3 到 10 倍。OceanBase 还是第一个通过 TPC-C 基准测试的分布式数据库，我们的 TPC-C 性能达到了 Oracle 的 20 倍。

Ryan：我注意到你非常强调性能。通常，当我们与事务型数据库的开发团队交流时，他们更关注的是可用性和可靠性。事务一旦记录，无论发生什么情况，必须确保每次都能成功。那么，OceanBase 是如何在保持可用性、可靠性、数据一致性的同时，还能提升性能的呢？

杨传辉：在 OceanBase 中，我们通过一种基于多数派共识的协议——Paxos 协议，来确保数据的一致性和高可用性。例如，我们为每一份数据创建三个副本，并将这些副本分布在集群中的三个不同节点上。当事务提交时，如果三个节点中有至少两个成功提交，即达到“多数派”，那么这个事务就被认为是成功的，从而确保数据的一致性。

在这种架构下，即使任何一个服务器发生故障，事务仍然会存储在剩下的两个节点中的至少一个上。因此，即使主节点突然宕机，另外两个节点可以自动选举出一个新的主节点，系统依然可以正常运行，且不会丢失任何数据。

Ryan：那么，每个节点是否都记录了所有事务，并且会对每一笔事务达成共识呢？还是说它们之间存在某种分工？

杨传辉：是的，最终每个节点都会存储所有事务，每笔事务只有在同步到多数派节点（即三个节点中的至少两个节点）后，才会被提交。

OceanBase 在支付宝中得到了广泛应用，我们还首创了名为“三地五中心”的架构。依靠这一架构，支付宝不仅能够应对服务器级别或数据中心（IDC）级别的故障，还能有效应对城市级别的灾难。这一架构于 2018 年在支付宝正式上线。迁移到 OceanBase 后，支付宝的数据库能够在不到 30 秒内自动恢复，且零数据丢失。

这背后还有一个非常有趣的故事，我很乐意和大家分享。

Ryan：当然，我喜欢听这些实战故事。

杨传辉：2015 年，支付宝的数据中心设在杭州。2015 年的 5 月 27 日，因为一次道路施工，连接数据中心的地下光缆被意外挖断了，导致部分服务中断。从那天起，支付宝记住了这个教训，并且深刻意识到，城市级别的灾难恢复能力不仅是可选项，而是必选项，尤其是对于 OLTP 数据库来说，这一点至关重要。

在接下来的几年里，我们进一步完善了这一解决方案，如今已经能够实现 RPO（恢复点目标）= 0，RTO（恢复时间目标）小于 8 秒。这意味着，我们的数据库可以在不到 8 秒的时间内自动恢复服务，且保证零数据丢失。可以说，以支付宝为代表的客户的需求推动了分布式数据库，比如 OceanBase 的不断演进。

Ryan：说到容灾，人们通常对数据中心偶尔出现故障的情况进行各种应对计划，但真正有意思的是如何去应对像陨石撞击这样的极端情况，比如某种极端情况导致整个城市都瘫痪了该怎么办。

杨传辉：没错。

Ryan：那么，这种情况的极限是什么？比如，网络要中断到什么程度，系统才会停止运行？

杨传辉：数据中心之间的网络被挖断的那个时候，实际上，两个数据中心之间还有一条冗余的网络连接。但不巧的是，这两条光缆同时都被切断了。也是因为这件事，支付宝意识到，仅仅具备数据中心级别的容灾是不够的，我们必须具备城市级别的灾难恢复能力。

Ryan：这是一种防患于未然的手段。当你拥有一个庞大的交易型数据库时，你必须为任何可能性做好准备。

我们刚才一直在讨论交易型数据库，我们看到很多数据库之间是存在差异的，比如，一些生产数据库被用于实时记录事务信息；还有一些庞大的数据湖，存储所有用于分析的数据，后者通常位于 ETL 流程的末端。你觉得有没有办法弥合这种差距，让所有数据都实时存储在同一个数据库中？

杨传辉：当然。我认为这里有两大阵营：OLTP（在线事务处理）和 OLAP（在线分析处理）。OLTP 用于支持高并发事务，强调强一致性、ACID 特性；而 OLAP 用于支持复杂的数据分析和报表。将 OLTP 和 OLAP 结合起来非常困难，因为这两种工作负载的要求截然不同。

通常，我们需要使用行存来处理 OLTP 工作负载，使用列存来处理 OLAP 工作负载，然后通过 ETL 将数据从 OLTP 传输到 OLAP。这种解决方案从开发者的角度来看非常复杂。因此，我们需要 HTAP（混合事务和分析处理），即使用一个单一的数据库同时支持 OLTP 和 OLAP。

我认为对于 HTAP 来说，分布式数据库是最佳选择。首先，分布式数据库能够处理更大规模的数据。如果我们将 OLTP 系统和 OLAP 系统合并，数据量相比之前将大幅增加。其次，分布式数据库中每一份数据都有多个副本。我们可以在主副本中使用行存来处理 OLTP，在次级副本中使用列存来处理 OLAP。只要我们有一个优秀的 SQL 优化器，就可以找到最佳方式来支持混合工作负载。

OceanBase 就是 HTAP 的一个绝佳例子，我们使用一个数据库系统和一份数据来同时支持 OLTP 和 OLAP。最初，OceanBase 主要用于 OLTP，但我们发现越来越多的用户开始将 OceanBase 应用于更多场景，比如实时 OLAP。因此，我们增强了 OLAP 能力，比如列存、并行执行、分布式 SQL 优化器，并发布了 OceanBase 4.3 版本来支持 OLAP 处理。我们还增加了许多重要的分析功能，比如全文索引、物化视图等。

举一个实际案例，有一家非常著名的餐厅叫海底捞火锅，它几乎是亚洲最有名的火锅品牌之一。原来它使用 MySQL 来处理 OLTP 工作负载，同时使用专门的分析型数据库来处理 OLAP 工作负载，并通过 ETL 将数据从 OLTP 传输到 OLAP 数据库。但这种模式下，OLTP 和 OLAP 之间存在数据延迟，可能会导致数据不一致。迁移到 OceanBase 后，我们用一份数据同时处理 OLTP 和 OLAP 工作负载，消除了数据延迟和数据不一致的问题，此外，还将总体拥有成本（TCO）降低了 40% 以上。

Ryan：这真是令人印象深刻的成果。如果不将它们整合在一起，显然你需要为两个不同的数据库付费，还得维护数据管道。那么，OceanBase 的 HTAP 需要对数据进行某种转换吗？还是这一切都是自动完成的？

杨传辉：确实如此。如果不使用 HTAP，像你刚才说的，就需要两套系统、两份数据，整个过程非常复杂。而在 OceanBase 中，所有 OLTP 和 OLAP 功能都被整合到了一个统一的系统里。并且对于用户来说，无论是 OLTP 还是 OLAP 的 SQL 处理，都是完全自动化的。用户无需关心哪些是 OLTP，哪些是 OLAP，这一切都由我们的 SQL 优化器自动完成。

Ryan：如今谈到数据，就不得不提到 AI，因为 AI 需要处理海量数据。那么，OceanBase 是如何融入当下的生成式 AI 浪潮中的呢？

杨传辉：我认为“SQL + AI”是未来的趋势。OceanBase 的愿景是打造一个统一的分布式数据库，可以处理各种类型的工作负载，包括 OLTP、OLAP 和 AI。在 AI 时代，我们需要向量数据库。目前主要有两种类型：一种是独立的向量数据库，另一种是带有向量插件的通用数据库，也就是“SQL + AI”。后者在传统 SQL 数据库的基础上引入了向量存储和处理能力。我认为，带有向量插件的通用数据库是未来的发展方向。OceanBase 在 2024 年 10 月，也就是去年，正式发布了向量能力。

AI 时代数据库的另一个技术趋势是混合搜索，即同时支持 SQL、NoSQL 和向量等多种数据模型。例如，当你想搜索一家“距离最近、评分最高且环境干净”的餐厅时，这个查询实际上同时涉及了多种数据模型：距离信息可能需要 GIS 数据，评分涉及结构化数据，而关于环境的评价则需要通过向量相似性搜索来实现。因此，如果能在通用数据库的基础上支持向量功能，就可以通过一个 SQL 查询实现混合搜索。我认为这将大大简化 AI 技术栈，帮助企业更快地进行 AI 应用开发。

在支付宝，我们也有许多应用团队正在为各种场景开发 AI 代理，最初，他们可能会同时使用独立的 SQL 数据库和独立的向量数据库。但在 OceanBase 支持混合搜索功能后，他们的所有工作负载都迁移到了 OceanBase，因为这比以前更容易操作，也更高效。

Ryan：是的，现在许多生成式 AI 应用都在朝着检索增强生成的方向发展，也就是为生成的内容提供参考文本。这需要将向量与大量其他类型的数据库存储技术相结合。

杨传辉：没错，这已经成为现实，我认为 AI 时代已经到来。

Ryan：没错，AI 时代已经到来。那么，关于 OceanBase 的未来，你最期待的是什么呢？

杨传辉：我非常期待 OceanBase 在一体化数据库的产品路线上继续发展，将 OLTP、OLAP 和 AI 整合在一起。这将使应用开发者的工作变得更加轻松，尤其是在 AI 时代。如果我们将各种类型的工作负载整合到一个系统中，数据量将比以前大幅增加。因此，我们需要分布式数据库，而且不仅仅是一个简单的分布式数据库，而是一个功能强大的分布式数据库。它需要能够处理各种类型的工作负载，具备高性能、低成本、高可用性和可扩展性等特点。我认为这些需求与 OceanBase 的发展路线和产品能力是一致的。