2025 年 5 月，OceanBase 作为第一作者单位，与来自高德地图、康奈尔大学（Cornell University）的研究团队共同发表的论文 OceanBase Unitization: Building the Next Generation of Online Map Applications 获得了 ICDE 2025 最佳工业与应用论文亚军（Best Industry and Application Paper Runner Up） 奖项，这也是 OceanBase 首次斩获 ICDE 大奖，实现历史性的学术突破。在本文中，高德技术服务平台负责人炳蔚和高德服务端架构师福辰（花名）对获奖论文进行详细解读。本文转载自高德技术公众号。
论文主题：
OceanBase Unitization: Building the Next Generation of Online Map Applications
论文链接：
https://www.computer.org/csdl/proceedings-article/icde/2025/360300e183/26FZCoh4LOU
*当届会议在工业界通常有一篇 Best Paper 和一篇 Best Paper Runner Up（最佳备选）。
想法出自：促科技创新：高德数据优化篇之 OceanBase 最佳实践
导读
OceanBase Unitization Building the Next Generation of Online Map Applications —— OceanBase 单元化构建下一代在线地图应用，在“海量数据”和“多维度数据”管理的复杂场景下，分布式数据库被广泛用于在线地图平台，提供一致性、容灾和高性能的云服务，以保障用户的体验。
而传统的单宿主架构系统在大规模服务扩展方面面临严峻的挑战且需要复杂的架构同时满足在线事务处理 (OLTP) 和在线分析处理 (OLAP) 两个场景。因 OceanBase 的列存机制，让引擎变得更加灵活，支撑的场景更加多样化。
本文提出的 OceanBase 的架构设计，这是一个将服务和操作“单元化”到单个机器上的分布式数据库系统。通过单元化设计实现了从单宿主迁移到跨多个区域的多宿主模式。利用这一特性，OceanBase 可确保在机器离线时数据复制和服务实现无缝的切换。然而，这种架构下，区域之间的通信开销有时会很重。
为了解决这个问题，OceanBase 将读写操作单元化，并采用混合集中化和单元化方法，针对 OLTP和 OLAP 进行了动态优化。为了验证我们的设计，我们将 OceanBase 部署在高德地图（一个支持大规模分布式服务的在线地图应用平台）上。通过一系列实验，我们证明了 OceanBase 强大的容灾能力，在写密集型和读密集型基准测试中均实现了性能提升。
Introduction
随着数据量的快速增长，分布式数据库系统的使用已成为当今互联网行业的主流趋势。谷歌、支付宝等领先的互联网公司都开发了自己的分布式数据库系统。在分布式场景中，数据库系统部署在多个节点上，并通过网络互连，从而创建一个逻辑上统一的数据库系统。通过将工作负载分布在多个节点上，它们可以以最小的延迟处理并发事务请求，从而高效地服务于大量用户并稳健地支持业务。
在分布式系统中，高可用性和高性能已成为评估有效性的两个关键指标。在独立的数据库系统中，单个服务器的故障可能导致严重的停机时间并阻塞后续的查询请求，这种单点架构的局限性，使得服务器和应用程序容易出现性能瓶颈。
为了解决这个问题，许多系统采用了通过添加机器和拆分应用程序等形式的灾难恢复技术。例如，在众多金融业务场景中，跨多个互联网数据中心 (IDC) 的横向扩展模式已被广泛采用。然而，对于拥有数亿用户的系统，仅仅依靠 IDC 级别的灾难恢复可能显得不足。部署层面的灾难恢复至关重要，需将 IDC 分布在不同地理位置，以防范地震、海啸等潜在威胁。
通常，像银行系统这样的典型系统会采用经典的“两城三中心” IDC 部署要求。当系统发生灾难性破坏时，灾难恢复在确保系统韧性方面发挥着至关重要的作用。然而，系统能够及时处理大规模请求，最大限度地降低最终用户的延迟也同样重要。虽然单点读写可以保证数据一致性，但在请求量巨大的情况下，仍然会出现性能瓶颈。
为了解决这个问题，许多系统选择将数据和计算资源分布在不同节点上，从而实现服务的分布式部署。每个用户的请求都会被定向到一个独立的节点，并在该节点内对分区数据执行读写操作。在某些复杂的情况下，用户的服务可能涉及多个请求，每个请求都可以路由到不同的节点。因此，访问地理位置相近的节点对于显著提升响应速度至关重要，可提升系统整体性能。
基于上述需求，高德地图引入“OceanBase 单元化”的概念。“单元”是指一个可以执行所有业务操作的独立整体，该整体包含各种业务所需的所有服务。“单元”作为基础部署实体，多个单元分布在整个站点内的所有 IDC 中。每个单元处理系统所需的所有应用程序，数据是基于特定标准对数据集进行分区的子集。与传统的面向服务架构 (SOA) 不同，SOA 将服务组织在层级结构中，节点数量也各不相同。
单元化架构保留了集成结构。然而，在这种情况下，同一层中的每个节点都专属于一个特定的单元。当上层调用下层时，只会选择同一单元内的节点。这种方法有助于在单元化架构中实现多活解决方案，有效隔离系统部署和核心流量。因此，它能够实现更灵活的可扩展性和强大的容灾解决方案。
从可用性的角度来看，数据在逻辑和物理上被划分为分配给每个单元的子数据库和表，这使得发送到故障单元的请求能够由另一个活动单元处理，从而确保服务的持续可用性，请求倾向于根据路由策略访问地理位置相近的单元。在性能方面，并发请求被高效地分布在多个单元之间，从而实现负载均衡。此外，根据具体的应用场景，读写 (R/W) 操作可以单元化或集中化。为了减少 OLAP 工作负载的同步开销，我们策略性地过渡到集中式写入。这种灵活的设计最大限度地提高了并发事务吞吐量，并在大数据环境中实现了高性能的查询响应。
设计云原生且独立于行业的架构已成为很多公司未来的发展方向。
具体来说，针对现有的核心服务，其研发重点包括提供跨地域容灾能力以及确保高并发请求下的高吞吐量。本研究主要致力于在高德地图的应用平台上部署OceanBase，采用单元化架构。本文的贡献可以概括为：
容灾能力：OceanBase 的单元化架构和三地五中心部署模式，实现了单元间的无缝切换，确保数据不丢失、不中断，从而实现数据高可用性和业务连续性。
高性能：OceanBase 允许用户访问地理位置相近的数据中心，从而降低延迟并最大程度地减少网络拥塞。为了提升读写请求的高吞吐量，OceanBase 采用了单元化和集中式相结合的架构。
一致性：OceanBase 在不同单元之间实现复制同步，以保证数据的一致性。
我们在高德地图上为众多应用部署了单元化的 OceanBase 系统，为 OLAP 和 OLTP 提供了高可用性和高吞吐量。OceanBase 的单元化架构在 AP 和 TP 性能方面展现出显著的性能优势，远超其竞争对手，展现出强大的数据处理能力和高效的查询机制。
以高德为例介绍三种典型的业务场景，OceanBase 采用单元化架构来应对每种场景带来的挑战。
📕【案例 1】强一致性财务
高德地图财务结算服务主要提供结算和财务数据服务，需要具备强数据一致性、数据防丢失和跨区域容灾能力。如图 1 所示，用户数据、资金流和信息流分别由业务渠道、财务渠道和财务会计模块控制。
高德地图提供各种服务，每个完整的服务都由多个子服务组成，这些子服务构成复杂的业务链。业务模块控制服务之间的交互，监控和管理业务流程的各种状态。如果业务链中任何环节发生故障，高德地图的系统必须及时检测到故障服务，重新启动任何未完成的流程，并从用户的角度确保业务流程的正常执行。
在资金流和信息流方面，财务结算服务在与 B 端商户的支付结算中起着至关重要的作用。它需要高度的数据一致性，以避免由于不一致而导致的支付计算错误。因此，为了提高财务和结算系统的可用性，高德地图需要一个支持跨地域容灾并提供强数据一致性的数据库系统。
(图 1 金融结算业务链)
当用户下达交易订单时，上游电商平台会与下游供应商进行交互，生成交易和订单数据。订单创建后，资金会被计算并支付给下游供应商。为了提升消费者体验，该服务为用户提供预付款服务，并防止下游资金服务出现问题而给消费者造成损失。所有这些服务都涉及资金的流通，因此需要数据读写的强一致性，以确保数据的完整性，并防止由于数据同步延迟而导致的重复付款或错误付款的情况。
📕【案例 2】云同步（OLTP）
高德地图云同步是一项基础业务服务，负责数据的云存储和跨设备同步。如图 2 所示，不同的终端系统（手机、平板电脑、车载系统）从不同节点同时访问云系统，并对云数据（例如用户位置信息、用户账户信息等）进行多次读写操作。在相应的业务场景中，需要确保跨多设备的数据写入准确、更新及时，并在切换设备后快速检索数据。随着高德地图业务的快速扩展，云同步系统需要存储海量数据。因此，在高德地图云同步服务中，数据库系统必须支持海量数据存储，实现多点写入，并确保卓越的读写性能。
（图 2 云同步业务场景）
用户可以在高德地图上标记和保存感兴趣的地点。他们可以选择创建多个收藏夹目录，以便随时查看和管理他们的收藏。借助此功能，用户可以轻松导航并规划前往已保存地点的路线，方便在日常出行中发现和导航到他们喜欢的地方。
此外，用户还可以与其他用户分享他们喜欢的地点和收藏。高德地图提供管理和共享地理信息的服务，这需要高效的写入操作，以确保信息通过实时同步保持最新。
📕【案例 3】在线点评服务与高清地图（OLAP）
高德地图评论服务是一个基于用户评价的信息平台，旨在为用户提供更精准、更实用的评论信息，帮助用户做出更明智的选择。它主要包含两个方面：用户评论和商家回复。
用户可以在高德地图平台上对商家进行评价，从服务质量、产品质量和环境等方面进行评分和评论。商家可以通过高德地图平台界面回复用户评论、解释和解决问题并与用户沟通。通常情况下，评论内容会受到内容审核服务的监控，因此每秒写入事务数 (TPS) 可能不是很高。但是，评论内容会显示在高德地图的各个端点上，因此需要较短的响应时间 (RT)。与用例 2 不同，评论服务涉及的写入操作少于读取操作。因此，我们致力于集中写入操作，以最大限度地减少同步开销。
一般情况下，整体 RT 需控制在 15ms 以内才能达到最佳性能。图 3 展示了高德地图评论服务与 OceanBase 解决方案的痛点分析。
(图 3 评论服务分析以及 OceanBase 解决方案)
在高德地图评论服务中，商家可以发布描述其产品的文章，用户可以浏览这些文章，并对其感兴趣的文章进行评论。
高德地图的评分系统确保用户评论实时更新，使其他用户能够同时访问最新的评价信息。商家可以利用高德地图平台回复用户评论，解决问题并提升服务质量。由于这种交互模式，用户发帖的频率明显低于浏览帖子的频率。因此，需要提供高效的读取操作以满足庞大用户群的需求至关重要。
高德地图的另一项 OLAP 服务，和云同步服务使用的是同一种架构，它是一种高精度地理信息服务，提供厘米级定位精度和详细的道路及交通数据，包括 3D 建模和实时动态信息。此类地图是自动驾驶、高级驾驶辅助系统 (ADAS)、智能交通系统以及城市规划和位置服务的关键基础。其高精度和详尽的数据对于智能交通和自动驾驶技术的发展至关重要。
针对描述的三种典型业务场景，OceanBase 采用单元化架构，提供强大的弹性能力，确保数据高一致性，并提升并发读写效率。业界常见的分布式架构主要包括单活、双活、多活和冷备架构。从容灾能力来看，这些架构可以在应用层面实现跨 IDC 容灾。然而，由于采用异步复制技术，数据库无法在数据中心层面实现零恢复点目标（RPO）。
多站点高可用性（MSHA）是一种面向分布式系统的健壮部署架构。逻辑数据中心的单元化架构是 OceanBase 实现 MSHA 的解决方案。“单元”是指一个独立的集合，可以执行所有业务操作，包括其服务和分配的数据。单元化架构以单元为基本部署单位，在每个数据中心部署多个单元，采用最优路由策略，高效处理访问跨数据中心多个单元的请求，从而最大限度地降低网络开销。
如果一个单元发生故障，其他单元可以无缝接管传入的请求，从而确保高可用性。通过跨区域部署单元，OceanBase 可以轻松支持区域级别的可用性。数据根据特定标准进行分区，从而支持多点读写操作，并缓解集中式操作瓶颈。为了满足不断增长的用户请求，可以通过添加更多单元来水平扩展部署。这有利于系统的可扩展性，从而有效地应对不断增长的用户需求。
从单元化角度来看，系统中存在三种类型的数据：
可分区数据：可以根据选定的维度进行分区，从而真正实现单元化。这类数据通常是单元化架构的核心。例如，订单、支付交易和账户数据。这类数据在系统中的比例越高，单元化程度就越高。如果系统完全由这类数据组成，则可以构建一个完美的单元化架构。
全局数据（关键业务链不频繁访问）：这类数据无法分区，仅存在于全局。一个典型的例子是配置数据，它可能会被关键业务链访问，但访问频率不高。因此，即使访问速度不够快，也不会对业务性能产生显著影响。
全局数据（关键业务链频繁访问）：这类数据与上一类数据类似，不同之处在于它们会被关键业务链频繁访问。如果系统不是以地理分布式方式部署，这类数据对分布式系统的影响很小。
但是，如果我们想通过单元化的方式实现多单元安全策略 (MSHA)，这类全局数据将被不同的单元访问，从而产生额外的开销。
(图 4 单元化架构完整图)
如图 4 所示，OceanBase 中的单元化架构包括区域区域 (RZone)、全局区域 (GZone) 和城市区域 (CZone)。GZone 部署不可拆分的数据和业务活动，而 RZone 部署可拆分的业务和相应数据。GZone 全局部署一次，并由 RZone 依赖。RZone 内的每个数据分片都有五个副本，实现三站点五数据中心的部署，每个分片只有一个可写的主副本，其余副本使用 Paxos 协议保持数据强一致性。每个 RZone 实现单元封装，独立处理所有自身操作。
CZone 的出现是因为 GZone 全局部署一次，但不同城市的 RZone 可能需要远程访问 GZone 的服务和数据，从而导致显著的延迟。因此，每个城市部署一个 CZone 作为 GZone 的只读副本，为该城市的 RZone 提供服务。单元化架构在分布式架构中实现了应用程序和数据的拆分。在地理分布场景下，它通过流量路由解决远程访问延迟问题。在多用户多点读写场景下，单元化架构会根据不同的应用需求决定是否集中写入操作，从而确保 OLTP 和 OLAP 的高吞吐量。
金融服务需要数据强一致性和跨区域容灾。综合考虑部署成本和可用性，我们选择了三城五中心的架构。此外，这种可扩展的架构支持水平扩展，能够在多个城市添加更多数据中心。OceanBase 支持金融数据同时写入多个区域数据副本，即使某个区域不可用，也能确保完整数据的可用性。
OceanBase 中的 Paxos 共识协议保证只有多个数据副本写入成功后响应才算成功，从而确保分布式副本的数据强一致性。
三城五中心部署：最大化 RZone 比例，最小化 GZone 比例，可以提升单元化架构系统的效率。在一个典型的三城五中心单元化架构系统中，单元的部署方式如图 4 所示。首先，我们在两个主要城市部署 RZone，并在第三个城市部署最后一个 RZone，用于运行分片应用。我们确保至少部署四组 RZone，每组分别部署在两个城市（即城市 1 和城市 2）的数据中心，第五组 RZone 部署在第三个城市（即城市 3）。该 GZone 可以处理所有公共服务，从而降低部署成本、开发成本和运营成本。我们将主 GZone 部署在其中一个主要城市（城市 1），用于处理非水平可扩展的业务。我们也可以在另一个主要城市（城市 2）部署一个备份 GZone，作为主 GZone 的远程灾难恢复点。备份 GZone 旨在确保灾难恢复功能的可用性，并能够处理少量的日常业务流量。为了简化整体架构，我们引入了一个 CZone，仅用于备份。更实际地讲，如果观察到从城市 2 的 RZone 或备份 GZone 到城市 1 的 GZone 的跨城市访问似乎对业务运营造成难以容忍的影响（例如响应时间过长），则会决定触发部署额外的 CZone。此额外部署有助于减轻对网络状况的任何不利影响并保持最佳性能。当 RZone 1 发生故障时，我们将 RZone 1 切换到 RZone 2，实现本地灾难恢复。首先进行数据库分片，并将 RZone 2 中 Shard 1 的副本提升为主副本。提升完成后，RZone 1 的流量将切换到 RZone 2，实现本地容灾，恢复点目标 (RPO) 为 0，恢复时间目标 (RTO) 小于 8 秒。同样，对于异地容灾，如果 RZone 1 发生故障，RZone 3 中的副本将切换到主副本，负责处理后续请求。此过程同样实现 RPO 为 0，RTO 小于 8 秒。
预写日志：OceanBase 通过预写日志 (WAL) 机制确保系统崩溃期间数据的正确性和完整性。OceanBase 原生支持对多个数据副本的并发写入，且不会出现同步延迟问题。在传统数据库系统中，写操作通常需要同步写入，即等待数据写入磁盘后才返回成功响应。这种同步写入方法会引入写入延迟，从而降低系统写入性能和吞吐量。然而，OceanBase 采用一种名为 PALF（基于 Paxos 的 Append-only Log File System，仅附加日志文件系统）的 WAL 方法来处理写入操作。当数据写入 OceanBase 时，写入操作会首先记录在 WAL 中，并立即返回成功响应。这种异步写入无需等待磁盘确认，OceanBase 会在后台执行日志刷新，将数据持久化到磁盘。这种方法支持并发写入多个副本，而不会出现同步延迟问题。多个写入操作可以并发处理，写入不同的副本而不会相互阻塞。
基于 Multi-Paxos 的复制：OceanBase 依赖于 Multi-Paxos 协议，它是 Paxos 算法的扩展，使用多阶段和多轮次机制。它通过引入一个 Leader 和多个 Acceptor 来实现高效的一致性。在 OceanBase 的实现中，Multi-Paxos 协议保障了分布式事务的一致性和可靠性。它确保了节点间的数据一致性，并通过 Leader 故障转移等机制提供高可用性和容错能力。Multi-Paxos 通过在 Paxos 集群内选举 Leader 来优化 Basic-Paxos。在 Leader 任期内，所有提案都由该 Leader 发起。这强化了协议的假设，即在 Leader 任期内没有其他服务器发起提案。因此，对于后续提案，可以简化日志 ID 的生成和准备阶段。唯一领导者生成日志 ID 并直接执行接受阶段，一旦多数人确认提案，便达成共识（每个重做日志对应一个提案）。
实验结果表明，单元化设计在“OLTP”和“LOAT”2 个场景下表现不错，也填补了数据库多样化带来复杂度的问题，通过多样化引擎和简化管理运维流程，提高了人效也降低了成本。
Dataset
实验在三个集群上部署 OceanBase 4.1.0，两种集群配置为 32 核/128 GB和 64 核/256 GB，并将 OceanBase（OB Cloud）与 CloudDB-A、CloudDB-B 等商用分布式数据库对比。基准测试使用 Sysbench 模拟高德地图的多种业务场景，包含五个子基准：
RO（只读）：模拟用户与已发布帖子和评论的交互。包含 10 个“Select”查询和 4 个包含聚合函数的附加查询，所有只读查询均表述为分布式事务。
RW（读写混合）：为模拟高德地图评论系统的真实场景，在 RO 子基准中引入 4 个写查询，这些作为分布式事务的查询涵盖了帖子和评论的删除、插入和更新操作。
WO（仅写入）：模拟云同步场景中的极端情况，仅专注于写查询，包括对给定 ID 的删除、插入和更新操作。
Insert：此子基准衡量向表中插入新元组的性能。
Update：Update 子基准评估基于给定 ID 的更新操作效率。
（一）性能对比
在本实验中，为评估不同压力水平下的性能，实验为每个子基准初始化一个“用户节点”，持续向数据库发送请求，并将请求频率逐步提升至 10 万次每秒（TPS）。为评估性能，本文分析了两个关键指标：成功响应的吞吐量和每个请求的平均响应时间（RT）。吞吐量表示单位时间内生成的成功响应数，平均响应时间则通过测量从发送第一个请求到接收最后一个响应的持续时间并除以请求总数计算得出。
为评估系统可扩展性，实验通过逐渐增加“用户节点”中的线程数进行实验。每个线程以相同频率持续发送请求，随着线程数增加，请求传输速率也随之提高。此外，还评估了系统在不同规模下的性能，考察其在可用资源和分布式处理水平不同的场景中如何处理工作负载。
所有子基准下不同分布式数据库系统的性能（TPS）
实验表明，在 RO 等读密集型子基准中，当面临高请求压力和大规模 CPU 设置时，OB Cloud 的性能优于其他系统。OB Cloud 之所以能实现更高的吞吐量，是因为各个单元协助处理请求，避免了主节点过载。在 INSERT 和 UPDATE 等写密集型或高竞争子基准中，OB Cloud 在所有实验设置中始终实现最高吞吐量，这是由于：
首先，OceanBase 使用针对分布式事务高度优化的早期锁释放策略，使参与节点能够在日志序列化到磁盘之前提交事务。
其次，OceanBase 采用 OMS 的离线同步机制确保单元间的数据一致性。
不同系统在变更请求频率和 ECS 实例模式下的响应时间
对比不同分布式数据库系统在变更请求频率和 ECS 实例模式下的响应时间发现，在 RO 场景中，OB Cloud 在 64 核配置下的平均响应时间比 CloudDB-A 和 CloudDB-B 低 30% 以上，体现了其在高并发读场景下的低延迟优势。在 RW 混合场景中，随着线程数增加，OB Cloud 的响应时间增长更为平缓，显示出更好的负载均衡能力。
（二）存储成本
为评估 OceanBase 压缩方案的效率，实验选择本地部署的两个商业数据库系统 DB-A 和 DB-B 作为对比基线，它们采用专用压缩模式以提高存储效率。实验表明，OceanBase 的压缩能力显著优于对比系统，存储空间比 DB-A 少 8.2 倍，比 DB-B 少 2.8 倍，这得益于其微块级用户自定义压缩和列存储编码技术。
不同系统在数据集大小变化时的压缩大小
（三）可用性测试
为评估 OceanBase 系统可用性，实验模拟了集群遭遇故障或灾难的场景。故障场景包括 OceanBase 服务器进程停止、节点重启、网络分区等八种常见故障：
故障场景
实验通过测量恢复时间目标（RTO）来量化系统恢复性能，RTO 定义为从请求遇到“无响应”错误到被其他单元成功处理的时间。实验结果表明，OceanBase 单元化部署的 RTO 始终低于 6 秒，其中 F2 场景因偶尔出现的节点重置消息接收失败导致 RTO 稍长，但通过参数调优可有效缓解。这表明系统能够快速从故障中恢复并恢复正常操作，最大限度减少对请求处理的干扰。
在八种故障场景下的RTO性能
Conclusion
本文展示了高德地图平台使用 OceanBase 实现单元化架构的应用设计，该架构通过跨单元的数据和服务分布确保高可用性，并通过单元化/集中式的读写优化了性能。实验表明，OceanBase 在容灾能力、读写吞吐量和存储效率方面显著优于其他竞争者，为大规模在线地图服务提供了云原生、高扩展的数据库解决方案。
未来，高德地图计划将结构化数据业务（如用户足迹存储）和向量化数据迁移至 OceanBase，以降低 50% 以上的成本。之后利用 OceanBase 的线性扩展能力，通过数据压缩减少节点数量，并在流量高峰时自动弹性扩缩容。此外，高德地图正探索在非结构化数据场景应用 OceanBase，预计成本降低目标同样超过 50%。通过单元化架构，OceanBase 将持续为高德地图提供高效、可靠的数据基础设施，以支撑其业务的持续增长与创新。
往期推荐
▼ 点击「阅读原文」，了解更多客户故事
