本文对蚂蚁集团OceanBase、高德地图等联合编写的发表在ICDE 2025上的工业论文《OceanBase Unitization: Building the Next Generation of Online Map Applications》进行解读，该论文获得“Best Industry and Application Paper Runner Up”奖励，全文共9582字，预计阅读需要30至40分钟。
分布式数据库系统被广泛用于为在线地图平台提供云服务，以实现一致性、容灾能力和高性能，而传统依赖单一服务器架构的系统在大规模服务扩展时面临挑战。本文提出OceanBase（OB）的架构设计，一种将服务和操作“单元化”到单个机器的分布式数据库系统。单元化方法从单一服务器设计转向跨多区域的多服务器设计，通过这一特性，OceanBase可确保在机器离线时实现数据复制和无缝服务切换。同时OceanBase对读写操作进行单元化，并采用集中式与单元化混合的方法，针对在线事务处理（OLTP）和在线分析处理（OLAP）进行动态优化。本文在在线地图应用平台高德地图（AMap）上部署了OceanBase。实验表明，OceanBase展现出增强的容灾能力，并在读写密集型基准测试中实现了性能提升。
1.1 分布式数据库的关键需求
随着数据量的快速增长，分布式数据库系统已成为互联网行业的主流选择。在分布式场景中，数据库系统通过网络互连多个节点，形成逻辑统一的整体。通过将工作负载分散到多个节点，该系统能够以最小延迟处理并发事务请求，高效支持大规模用户和复杂业务。
在分布式系统中，高可用性和高性能是关键评估指标。在传统的单机数据库中，单服务器故障可能导致严重停机，影响查询请求处理。为解决这一问题，业界普遍采用跨数据中心（IDC）水平扩展的容灾技术，例如金融场景中广泛应用的“两地三中心”部署模式。然而，对于亿级用户规模的系统，仅依赖IDC级的容灾技术仍显不足，需进一步在地理区域级别实现分布式部署，以应对地震、海啸等极端风险。
因此，容灾能力是系统应对灾难性故障的核心，但及时处理大规模请求、降低终端延迟同样重要。单点读写虽能保证数据一致性，但在高并发场景下易成为性能瓶颈。为此，分布式系统通过数据和计算资源的节点级分布，将用户请求路由至独立节点处理。在此过程中，访问地理邻近节点成为提升响应速度的关键。
1.2 提出OceanBase单元化的动机
基于上述的需求，本文提出OceanBase单元化架构。“单元”代表可独立执行所有业务操作的自包含实体，作为基本部署单元分布于各IDC中。每个单元处理系统的所有应用，数据则基于特定规则分区存储。与传统分层服务架构（SOA）不同，单元化架构中同一层的节点专属于特定的一个单元，上层调用仅在单元内完成，从而实现多活部署，隔离流量，并提升扩展灵活性和容灾能力：
从可用性看，数据通过逻辑和物理分区分配至各单元，故障单元的请求可由其他单元接管，以确保服务连续性。
从性能看，并发请求通过单元分布实现负载均衡，同时支持根据特定的场景动态选择读写模式（单元化或集中式）。例如，为降低OLAP同步开销，可策略性采用集中写入。
高德地图（AMap）作为国内领先的移动地图服务平台，其核心业务对数据库的扩展性和容灾能力提出了极高要求。此前，AMap使用的MongoDB因分布式存储效率问题导致CPU高负载和服务中断；在迁移至Lindorm和Elasticsearch后虽改善了检索性能，但缺乏传统关系型数据库的完整SQL支持。因此，构建云原生、行业无关的架构成为AMap的核心目标，尤其是跨区域容灾和高并发场景下的高吞吐量保障。本文主要聚焦于在高德地图上部署OceanBase单元化系统的工作，主要贡献包括：
1. 容灾能力：通过对OceanBase单元化和三地五中心部署，实现了无缝单元切换，以确保数据零丢失、数据可用性和业务连续性。
2.高性能：该单元化架构支持就近访问数据中心，降低延迟；通过将单元化与集中式结合，提升读写请求吞吐量。
3. 数据一致性：该单元化架构通过单元间复制同步机制，保障分布式数据一致性。
4. 实际部署验证：本文在AMap的多个应用中部署单元化OceanBase，实验验证了其在OLAP和OLTP场景下的高可用性和性能优势，优于同类产品。
2.1 强一致性金融业务
金融结算业务链
AMap的金融结算服务对资金流和信息流有高一致性要求，同时要防止数据流失和跨区域灾难恢复的能力。业务场景例如用户交易订单处理、与B端商家的结算对账等。如图所示，该业务链涵盖数据管理、资金计算、状态监控等模块。任一环节出现故障时，需快速恢复，避免支付错误或数据不一致。
示例：当用户下交易订单时，上游业务与下游供应商进行交互，生成交易和订单数据，并在创建订单时计算资金并支付给下游供应商。为了提升消费者体验，该服务为用户提供预付款，并保护消费者免受下游资金服务问题造成的损失。该业务场景需要在读和写入数据时保持高度一致，以确保数据的完整性，并防止由于数据同步延迟而发生多次支付或不正确支付的情况。
2.2 云同步（OLTP）
云同步业务场景
AMap的云同步服务负责用户数据（如位置、收藏、设置）的多设备同步，需支持海量数据存储和高频读写。如图所示，用户通过手机、车载设备等多个终端访问数据，要求写入准确、更新及时和快速的跨设备检索。
示例：用户在AMap上标记和保存感兴趣的地方并选择创建多个收藏夹目录，使他们能够随时查看和管理他们的收藏。有了这个功能，用户可以轻松地导航和计划路线到他们保存的位置，方便他们在日常旅行中发现和导航到他们最喜欢的地方。此外，用户可以与其他用户共享他们喜欢的地方和收藏。AMap提供管理和共享地理信息的服务，这需要高效的写操作以确保信息是最新的。
2.3 在线评论与高精地图（OLAP）
评论服务分析以及OceanBase解决方案
AMap的评论服务以用户评价和商家回复为核心，需要读多写少，要求低延迟查询（RT<15ms）。而高精地图作为自动驾驶的基础，提供厘米级定位和实时动态交通数据，属于另一个典型OLAP场景，要求高精度和详细的数据，为无人驾驶、高级驾驶辅助系统等场景做基础。
示例：在AMap评论服务中，商家可以发布描述其产品的文章，用户可以浏览这些文章并评论文章。AMap的评分系统确保用户评论实时更新，使其他用户能够同时访问最新的评价信息。商家可以利用AMap平台回应用户评论，解决问题并提高服务质量。在这种互动模式下，必须提供有效的读取操作以满足大量用户群的需要。
3.1 存储引擎
OceanBase的存储引擎基于LSM-tree结构，将数据分为静态SSTable和动态MemTable，采用混合行-列存储格式，以2MB宏块（包含多个16KB块）为最小I/O单元。该引擎同时支持用户定义压缩和B+树/哈希索引，优化热点数据访问达到高查询性能。通过无共享架构和多版本并发控制（MVCC），结合Paxos协议保障一致性，消除单点故障，OceanBase的存储引擎支持动态扩展和数据重平衡。
3.2 事务引擎
多版本读一致性的实现
OceanBase采用并发控制模型，确保高性能，可扩展性和低延迟事务，并具有内置的高可用性和灾难恢复。其采用基于Paxos的分布式事务模型，通过全局时间戳服务（GTS）实现外部一致性。表数据分布于不同分区，每个分区通过Paxos协议实现容错。OceanBase提供快照读取和读取提交隔离级别，以确保分布式系统中的一致性。它使用多版本存储方法，允许事务使用全局读取和提交版本号进行标记。新版本与事务的全局提交版本号一起存储在内存中以供更新。
如上图所示，分区中的更新通过版本、值和事务ID进行跟踪，允许多个版本。事务通过其ID、状态和版本在内存表中进行跟踪。一致性协议确保分区的大多数节点之间的日志同步。锁管理器协调并发事务访问以防止冲突并确保数据完整性，而日志服务管理操作日志以实现持久性和恢复，增强可靠性和容错性。架构服务维护元数据和架构信息，促进数据库结构管理以响应业务更改。
4.1 单元化架构概述
传统分布式架构（如单活、双活）虽能实现跨IDC容灾，但其依赖异步复制，难以保证数据零丢失（RPO=0）。OceanBase的单元化架构通过“逻辑数据中心”实现多站点高可用（MSHA）。多站点高可用（MSHA）是一种面向分布式系统的健壮部署架构，核心概念包括：
1. 单元（Unit）：是指能够执行所有业务操作的独立集合，包括其服务和分配的数据。单元化架构以单元为基本部署单元，在每个数据中心部署多个单元。采用优化的路由策略，高效处理跨多个数据中心访问多个单元的请求，最大限度地减少网络开销。如果一个单元发生故障，其他单元将无缝接管传入的请求，确保高可用性。
2. 数据类型：
可分区数据：数据可按维度拆分，如订单、账户数据，是单元化的核心。
全局数据（低频访问）：这些数据不能分区，只能全局存在，如配置数据，访问频率不高
全局数据（高频访问）：需跨单元访问，可能引入额外开销。
部署结构：
GZone（全局单元）：部署不可拆分的数据和业务活动，仅全局部署一次，支持跨区域备份（如City1主GZone，City2备份GZone）。
RZone（区域单元）：依赖于GZone，部署可拆分的业务和相应的数据，每个分区包含5个副本（三地五中心），每个分片只有一个可写的主副本，其余的副本使用Paxos协议保证数据一致性。
CZone（城市单元）：作为GZone的只读副本，部署于各城市以降低跨城访问延迟，为该城市的RZone提供服务。
OceanBase单元化部署结构
OecanBase的单元化架构在分布式架构下实现应用和数据的拆分，在地理分布的场景下，通过流量路由解决远程访问延迟问题。在多用户多点读写的场景下，单元化架构根据不同的应用需求决定是否集中写操作，保证了OLTP和OLAP的高吞吐量。
4.2 单元容灾设计
金融业务需要强大的数据一致性和跨地域的容灾能力。考虑到部署成本和可用性，OceanBase选择了三个城市五个数据中心的架构。这种可扩展的架构允许横向扩展，可以在多个城市增加更多的数据中心，使金融数据能够同时写入多个区域数据副本，即使一个区域不可用，也能确保完整数据的可用性。同时，OceanBase中的Paxos共识协议保证仅当成功写入多个数据副本时响应才成功，确保分布式副本的强数据一致性。
OceanBase单元化部署结构
1. 三地五中心部署：通过最大化RZone的比例和最小化GZone，可以提高单元化架构系统的效率。如上图，在三个城市部署五个数据中心，其中两个主城市各部署两个RZone，第三个城市部署一个RZone，GZone主备分别位于两个主城市。当某单元（RZone1）发生故障时，将RZone1切换到RZone2，实现本地容灾：
进行数据库分片，将RZone2中Shard1的副本提升为主副本。
提升完成后，RZone1的流量切换到RZone2，实现本地灾难恢复，恢复点目标（RPO）为0，恢复时间目标（RTO）小于8秒。
同理，对于远程灾难恢复，如果RZone1发生故障，RZone3中的复制副本将切换为主复制副本，负责将来的请求。此过程同样使恢复点目标（RPO）为0，恢复时间目标（RTO）小于8秒。
2. 预写日志（WAL）：OceanBase采用了一种名为PALF（Paxos支持的仅限日志文件系统）的WAL方法来处理OceanBase中的写操作。当数据写入OceanBase时，写操作首先记录在WAL中，WAL立即返回成功响应。这种异步写入消除了等待磁盘确认的需要。OceanBase执行后台日志刷新以将数据持久化到磁盘上。这种方法支持并发写入多个副本，而不会出现同步延迟问题。可以并发处理多个写入操作，写入不同的复制副本，而不会相互阻塞。
3. 基于Multi-Paxos的复制： Multi-Paxos协议是Paxos算法的扩展，使用多个阶段和多轮。它通过引入一个领导者和多个接受者来实现高效的共识。在OceanBase实现中，Multi-Paxos协议确保分布式事务的一致性和可靠性。它确保节点之间的数据一致性，提供高可用性和容错。Multi-Paxos通过在Paxos集群内选举leader来优化BasicPaxos。在leader任期内，所有的提案都是由领导者发起的。这加强了协议的假设，即在领导者的任期内没有其他服务器提出提案。因此，对于随后的提案，日志ID的生成和准备阶段可以被简化。唯一的leader生成日志ID并直接执行接受阶段，一旦大多数人确认提案，即达成共识。
4.3 单元读写设计
在云同步场景中，OceanBase的多单元同步链路和OceanBase Migration Service（OMS）秒级同步能力，确保了多数据中心的低延迟数据同步。云同步的本质是跨多个端点的数据同步，通过使用可用ID等分区键，所有操作都在一个单元内完成，提高R/W性能。
1. 路由机制：业务请求通过路由数据链接。
入口流量路由：通过业务请求中的用户ID等标识解析目标单元，首次请求基于地理位置就近路由，后续请求通过Cookie携带单元信息。
跨区域服务器调用路由：通过RPC服务自动处理跨单元请求，动态调整同城跨域服务调用/城间跨域服务调用，对应用透明。
2. OMS：OceanBase迁移服务（OMS）是专为OceanBase数据库设计的综合工具，支持高效的数据传输和同步。用户可在各种数据库实例间无缝同步复制数据，确保实时迁移和同步，风险和成本最低。
在OceanBase的三地五中心部署中，Paxos协议和多副本部署实现了强大的跨区域容灾能力。当业务中心发生区域故障时，容灾中心通过切换域名无缝接管。OMS通过亚秒级切换和实时验证功能，助力容灾中心的创建，通过部署多个资源节点确保组件的高可用性。若任何OMS单元节点发生故障，同步链路自动连接到其他可用资源节点，确保传输不间断。
3. 数据丢失问题：用户切换到新单元时，新写入的数据可能无法立即在新单元中可见或访问，导致数据丢失。
数据丢失问题
为解决此问题，OceanBase在业务端实施“写入禁止时间”机制。此外，利用OMS跨IDC同步数据，确保OMS数据同步期间防止数据覆盖。OMS支持基于时间戳的起点和终点前数据追补，为确保数据完整性，业务端在OMS流程的起止时间戳之间锁定写入操作。
4.4 集中写入与单元读取
在评论服务的业务中，多点写入虽引入数据冲突和复杂度挑战，却提供更好的容灾能力。因此，本文决定采用集中写入和单元读取的方法。OceanBase采用集中写入架构，所有写入操作集中在中心节点处理，简化架构并减少数据重叠问题。集中写入后，数据可通过单元读取访问，使架构更简洁，无需担心数据重叠。
在线评论业务中集中写入和单元读取的架构
向主节点的集中写入应与备份节点同步。OceanBase实现三城市的主备数据同步，意味着三城市数据库之间可进行实时数据同步，确保数据一致性和可靠性。凭借集群间的原生同步能力，OceanBase实现亚秒级延迟的数据同步，确保数据的即时性和准确性。
如图所示，城市2的中央主集群可读写，实现读取的强一致性。城市1和城市3为备份集群，通过OceanBase的原生集群复制能力实现亚秒级延迟同步，为周级一致性的异构存储提供高吞吐量、低延迟的读取操作。数据一致性通过以下方式确保：
实时同步：通过主备集群间的原生同步能力实现数据一致性。
离线分析：利用数据分析和监控平台确保离线分析场景下的数据一致性。
4.5 分布式事务的单元化
分布式事务扩展（DTX）是一种金融级分布式事务中间件，可确保大规模分布式环境中业务活动的最终一致性。两阶段提交（2PC）+全局时间戳服务（GTS）是一种用于分布式事务的线性一致事务处理流程，如算法所述。
分布式事务执行算法
OceanBase采用早期锁释放（ELR）机制以提高事务处理吞吐量并减少事务处理延迟。事务持有锁的时间包括四个部分：1）数据写入，2）日志序列化，3）同步备份的网络通信，4）日志刷新时间。优化后，日志序列化完成并提交到缓冲区管理器后，无需等待日志多数派刷新即可触发行锁释放，减少事务持锁时间；同时，事务释放锁后，允许后续事务对同一行进行操作，实现多事务并发更新，提高吞吐量。
在单元化架构下，分布式事务可在GZone和RZone中发起。GZone中发起的事务写入DTX服务器的单个表；而RZone中发起的事务，DTX服务器会根据分片ID将事务日志路由到相应的目标数据库和表。事务恢复任务仅在GZone中执行，监控GZone中的单个数据库表和RZone中的分片数据库表，并通过分析事务日志中的分片信息确定事务应路由的目标区域。这方法确保了高效可靠的事务处理，即使在复杂的分布式环境中也能实现无缝恢复。
5.1 实验设置
实验在三个集群上部署OceanBase 4.1.0，两种集群配置为32核/128GB和 64核/256GB，并将OceanBase（OB-Cloud）与CloudDB-A、CloudDB-B等商用分布式数据库对比。基准测试使用Sysbench模拟高德地图的多种业务场景，包含五个子基准：
RO（只读）：模拟用户与已发布帖子和评论的交互。包含10个“Select”查询和4个包含聚合函数的附加查询，所有只读查询均表述为分布式事务。
RW（读写混合）：为模拟高德地图评论系统的真实场景，在RO子基准中引入4个写查询，这些作为分布式事务的查询涵盖了帖子和评论的删除、插入和更新操作。
WO（仅写入）：模拟云同步场景中的极端情况，仅专注于写查询，包括对给定ID的删除、插入和更新操作。
Insert：此子基准衡量向表中插入新元组的性能。
Update：Update子基准评估基于给定ID的更新操作效率。
5.2 性能对比
在本实验中，为评估不同压力水平下的性能，实验为每个子基准初始化一个“用户节点”，持续向数据库发送请求，并将请求频率逐步提升至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的响应时间增长更为平缓，显示出更好的负载均衡能力。
5.3 存储成本
为评估OceanBase压缩方案的效率，实验选择本地部署的两个商业数据库系统DB-A和DB-B作为对比基线，它们采用专用压缩模式以提高存储效率。实验表明，OceanBase的压缩能力显著优于对比系统，存储空间比DB-A少8.2倍，比DB-B少2.8倍，这得益于其微块级用户自定义压缩和列存储编码技术。
不同系统在数据集大小变化时的压缩大小
5.4 可用性测试
为评估OceanBase系统可用性，实验模拟了集群遭遇故障或灾难的场景。故障场景包括OB服务器进程停止、节点重启、网络分区等八种常见故障：
故障场景
实验通过测量恢复时间目标（RTO）来量化系统恢复性能，RTO定义为从请求遇到“无响应”错误到被其他单元成功处理的时间。实验结果表明，OceanBase单元化部署的RTO始终低于6秒，其中F2场景因偶尔出现的节点重置消息接收失败导致RTO稍长，但通过参数调优可有效缓解。这表明系统能够快速从故障中恢复并恢复正常操作，最大限度减少对请求处理的干扰。
在八种故障场景下的RTO性能
6.1 性能优化
为解决分布式事务中链路过长导致的性能问题，可从以下角度进行优化：
首先，采用全链路追踪技术，对业务流程、应用服务和数据库SQL语句进行综合分析。通过追踪机制将业务操作、应用服务调用和数据库查询相关联，来获取完整的业务执行路径。
其次，将应用层的追踪信息传递至数据库层，确保每条SQL语句和每行数据都与对应的业务链路相关联。通过这种方式，可以识别出业务链路中执行最慢的SQL语句，针对性地进行性能优化。对于调用最频繁的服务，考虑引入缓存机制以减轻数据库负载；对跨城市、区域或数据中心执行的SQL语句进行分类和优化，减少潜在的延迟。
6.2 业务连续性
通过OceanBase单元化确保高德地图的业务连续性，需要制定弹性规划并实施技术解决方案以应对中断。高可用性和灾难恢复对于高德地图依赖数据库的地理空间数据服务至关重要。OceanBase的负载均衡功能将传入流量分布在多个节点上，消除单点故障并提供一致的服务。动态容量调度使系统能够根据用户需求调整资源，这在高峰时段或流量激增时至关重要。而严格的变更管理，包括系统更新或变更的全面测试，有助于维持服务稳定性并防止中断。
OceanBase的容灾能力包括地理分布的集群，以便在区域中断时进行故障转移，确保服务不间断。日常运营受益于全面的监控和自动化自动恢复系统，能够检测并纠正故障，最大限度地减少停机时间。同时，灾难恢复计划详细说明了故障转移程序和角色分配，这对于快速恢复和持续运营至关重要，即使在大规模系统故障期间，也能确保高德地图的服务可靠性。OceanBase单元化及其可用性特性为这些连续性策略提供了强大的基础。
6.3 系统运维
系统运维面临的挑战主要包括设备稳定性和流量波动管理。采用分布式架构的高德地图系统可能会遇到服务器的稳定性问题。为此系统设计有单机自愈能力，以便在发生故障时快速恢复正常运行。此外，面对可能的流量激增，作者团队在系统上线前进行了链路容量评估和全面的压力测试。
此外，为确保系统的平稳运行，作者还实施了日常运维检查，例如消息积压和数据库挂起的预警机制。系统的日终批处理作业将按照预定的调度链路执行，确保整体运营效率。为确保数据的准确性和一致性，上下游数据将被自动检查，以确保交易数据的准确性。这些准备和措施共同构成了系统运维的关键部分，以应对上线后可能面临的各种困难。
7.1容灾技术
1.灾难恢复方法：灾难恢复方法已被广泛用于确保系统可用性并减轻灾难的影响：
云备份：建立并维护了一个辅助IDC，作为灾难后的数据恢复手段。
双活灾难恢复：使主备IDC能够同时提供服务，数据从主IDC单向同步到辅助IDC。
许多云服务：采用了多站点高可用架构，确保在多个地理站点或IDC之间的持续运行和服务可用性。这种架构专可以最大限度地减少停机时间，并在单个站点发生故障或中断时提供冗余。
2. 基于日志的恢复：容灾能力依赖于每个节点上实现的恢复算法。各种云数据库根据不同的架构自定义其故障恢复方法：
PolarDB Serverless：使用类似ARIES的恢复算法，区分主节点和只读副本等不同类型的节点，并采用特定算法确保快速恢复。
Amazon Aurora：利用存储层有效管理顺序日志，从而提高写入操作的性能。
Microsoft Socrates：引入独立的XLOG服务，将日志与计算和存储分离，该专用层确保存储事务日志的最佳低延迟和高吞吐量。
SolarDB：将存储和计算分离，在事务提交前将预写日志持久化到持久性存储中。
3. 分区和复制架构：为避免依赖单节点恢复，许多系统采用跨节点的显式分区与复制技术：
VoltDB：采用多节点架构，将表水平划分为“分片”并跨节点复制。
Google Spanner：通过单一Paxos状态机管理跨数据中心的复制数据，确保副本间的一致更新。
Calvin：基于Paxos实现同步复制，但仅复制事务输入而非结果，利用数据库的确定性通过重放输入实现恢复。
PaxosStore：为微信业务构建了高可用存储系统，基于Bitcask和LSM-tree设计分层Paxos协议。
7.2 分布式事务
分布式事务通过数据或服务分区技术在多节点执行:
Calvin：将事务拆分为作业并在节点间调度，通过确定性执行顺序减少协调开销。
RedT：是一个基于RDMA的分布式事务协议，降低跨数据中心的往返次数，提升可用性。
Lindorm：结合计算节点集群与共享存储，支持时序数据的低延迟查询。
Amazon Dynamo：是一个高度去中心化的键值存储系统，支持分区数据的事务操作。
Cassandra：是一个专为海量结构化数据设计的分布式存储系统，支持跨节点的多文档事务。
OceanBase：通过内存与磁盘数据结构结合，有效降低文档操作的开销。
同时，在分布式数据库中，计算存储分离架构日益普及：
PolarDB Serverless：将计算节点的CPU资源与远程内存、存储池解耦。
DAGOR：将服务拆分为微服务，通过细粒度负载监控和协作式负载分流来应对过载。
Citus：作为PostgreSQL的分布式扩展，支持跨集群的分布式查询与事务，适配数据密集型应用。
本文展示了OceanBase单元化架构在高德地图平台的应用，该架构通过跨单元的数据和服务分布确保高可用性，并通过单元化/集中式的读写优化了性能。实验表明，OceanBase在容灾能力、读写吞吐量和存储效率方面显著优于其他竞争者，为大规模在线地图服务提供了云原生、高扩展的数据库解决方案。
未来，高德地图计划将结构化数据业务（如用户足迹存储）迁移至OceanBase，以降低50%以上的成本。之后利用OceanBase的线性扩展能力，通过数据压缩减少节点数量，并在流量高峰时自动弹性扩缩容。此外，高德地图正探索在非结构化数据场景应用OceanBase，预计成本降低目标同样超过50%。通过单元化架构，OceanBase将持续为高德地图提供高效、可靠的数据基础设施，以支撑其业务的持续增长与创新。
论文解读联系人：
刘思源
13691032906（微信同号）
liusiyuan@caict.ac.cn
