提起高德，许多人首先想到的是其精准的数字地图。但如今的高德，早已不仅仅是一款导航工具，而是发展成为覆盖衣食住行等全场景的“国民级”出行服务平台。

数据显示，高德的日活跃用户数最高已突破 3.6 亿人次（截至 2025 年 10 月 1 日），日均活跃用户也稳定在 1.5 亿人次以上。如此庞大的用户体量，为高德的业务系统带来了海量数据存储与实时响应的双重挑战，尤其在五一、国庆等出行高峰期间，后台系统承受的压力更为显著。

面对持续增长的业务压力，传统基于分库分表的数据库架构已无力支撑。在这一背景下，高德开始探索将数据库升级至新一代分布式数据库 OceanBase 的可行路径。其中，“足迹”与“云同步”等核心业务，成为此次升级的先行者。

01 高德地图在线服务应对海量存储三大核心挑战与思考

作为高德地图出行服务技术负责人，李岩的核心职责之一是应对各业务快速发展带来的高并发与海量存储挑战。

“用户每一次路线规划、每一次地点搜索的背后，都是对系统稳定性与体验感的极致考验。我们必须确保每一次请求都稳如磐石，用户体验如丝般顺滑。”李岩表示。

高德的技术体系构建在云原生基础设施之上，依托云的弹性伸缩能力，可根据业务需求快速实现资源的扩缩容，从而为上层应用的开发与部署提供极大的灵活性。高德强大的云底座也让李岩能更专注于应对大并发、低延迟的海量存储带来的技术压力。

李岩将高德应对海量数据所面临的核心挑战归纳为三方面：

一是数据存储扩展和成本效率，即如何合理部署与分配业务数据。这不仅关乎存储成本，更直接影响业务模型能否实现低成本的扩展与迭代，进而影响整体业务效率。

二是极致的性能要求。高德的在线服务必须在高 QPS/TPS 下保持低耗时的响应，并能在需要时实现平滑的弹性伸缩。同时，系统还需具备故障快速发现、诊断与恢复的能力。

三是容灾高可用保障。系统需支持在出现故障时实现“一键”逃逸能力与逃逸的力度，并尽可能让用户对此过程无感知。

实际上，无论是“足迹”还是“云同步”，这些核心业务系统数据库升级的目标正是为了应对上述三个核心挑战。

02 选择 OceanBase：解决千亿级数据规模的分库分表架构瓶颈

高德的“足迹”服务是一项自动记录用户历史出行与停留地点的位置服务。它通过持续收集定位数据，生成个人专属的出行时间轴，帮助用户回顾、管理和分享自己的移动路线。目前，数据规模已超过 7000 亿条，存储规模突破 360TB，读写并发峰值平均每秒超过 27 万次请求。

“‘足迹’需要在 10 毫秒内响应用户请求，是一种典型的海量数据、高并发、低延迟业务场景，对底层数据库系统要求极高。”李岩表示。

“足迹”原先采用分库分表架构。虽在一定程度上缓解了数据量的问题，但随着业务不断迭代、数据量不断增长，其弊端也逐渐凸显：例如大表以及大表在做索引变更时会引发抖动，进而影响系统稳定性；其次，一些模型拓展以及数据归档成本都相对较高，在成本上持续面临压力。

鉴于业务的快速增长，李岩和团队选择从底层存储层入手，做一次彻底的治理和升级，彻底解决分库分表架构带来的性能瓶颈，满足业务快速发展对数据底座的全新要求。

从业务角度而言，此次治理和升级，高德地图在数据库选型上需满足三大方面的要求：高可用、业务效率和成本。经过测试和对比以后，最终选择 OceanBase 来服务高德地图。

李岩表示，之所以选择 OceanBase，是因为其具有原生分布式和单机分布式一体化架构，具备弹性扩展、高可用和多活容灾能力。同时，除了 OceanBase 的性能稳定、产品成熟度高，已经过市场充分验证外，还有三点能力也是他看中的：

1.极致的存储压缩：OceanBase 提供多种压缩方式，显著降低存储规模；

2.高度兼容 MySQL：减少应用层代码修改量，助力业务平滑升级。

3.原生多活架构支持：可以根据业务需求灵活地选择。

03 高德足迹大规模在线升级的考量与实践：零故障、零问题、用户零感知的平滑跃迁

第一，站在全域、全链路的视角，放量回切控制点保持强统一、强同步、强一致，特别是涉及多层级的服务调用依赖时，这点尤其关键，否则就容易出现读写错位、放量错位的问题。

第二，进行多维度的数据校验。在“足迹”数据升级过程中，从最底层到最上层，分别进行了数据级、SQL级以及业务级的对比。只有三个校验都没有问题，才是真的没有问题。

第三，全量数据同步吞吐量高。这次升级过程中，OMS 的吞吐达到了每秒 1000 万行的并发写入，大大缩短了迁移周期。

升级后的系统平稳，已历经今年“双十一”等流量高峰期的考验，运行稳定、流畅，整体表现优异。对于此次数据库升级，李岩认为非常成功，为高德带来了多方面的实质性收益：

成本显著优化：OceanBase 通过高效的压缩算法，压缩比达到 2.23:1，数据规模得到降低，存储成本节省 55.2%。

性能持续提升：系统平均响应时间由原来的 5.95 毫秒降至 4.42 毫秒，提升了 25.7%，用户体验进一步改善。

研发效率提高：业务开发人员无需再关注分片、路由、弹性扩缩容等底层细节，“如同操作单机 MySQL 一样使用分布式数据库”。

04 OceanBase 异地多活架构在高德的落地实践

“云同步”是高德的另一项核心业务。“云同步”主要完成用户多端设备（如多个手机之间、手机与车机之间）的数据同步。

该业务的显著特点是数据量极为庞大，仅 3 个单元的数据总量就高达 5000 亿条。这一在线服务场景，对数据的实时性和高可用性都提出了极高的要求。

为了保证用户体验，同时也为了容灾，“云同步”在具体的业务场景下联合 OceanBase 采用了异地多活架构，在上海、张北、深圳三个数据中心分别进行部署。业务应用层提供多点写入的能力，基于用户维度进行单元化的路由和单元化的纠偏；中间的底层存储则依赖 OceanBase 的三地五中心金融级无损容灾能力部署，最下层的数据通路通过 OMS 来实现。

李岩介绍，由于高德需要实现不同单元间的双向同步，整个同步链路相对复杂，最终形成了三地六项的同步架构。“多活的目的，是为了就近接入以降低延迟，均衡各地域的资源分布和利用率，同时提升服务的 SLA，实现完全的高可用。同时，‘云同步’性能也得到了显著提升，实现了读写 QPS/TPS 22 万，读写平均响应时间 10 毫秒以内。升级后性能表现平稳，并且无论是水位还是 OMS 三地间同步链路也非常平滑。”

“如果没有 OceanBase 原生的多活能力，数据同步逻辑就必须在应用层实现，这不仅会大幅提升系统复杂度，也会显著增加开发和维护成本。”李岩说。

同时，系统的容灾能力也得到明显增强：当某个业务中心发生故障时，可在分钟级完成流量切换至其他数据中心，实现真正意义上的跨地域容灾逃逸。

05 结语

回看 OceanBase 在高德多个核心业务系统的应用，李岩认为，收益主要体现在以下三方面：

简单：提高了研发效率，业务研发像使用单机一样去使用分布式存储，不用关心分区、路由等等细节问题；

降本：因为有多种数据压缩手段以及数据和日志的分离，带来较高压缩比，数据规模越大，效果越明显；

多活和高可用：能保障数据的强一致性，提供多种多活部署方案，业务可按需选用。

“更重要的是，从分库分表到原生分布式数据库，高德完成的不仅是一次数据库升级，更是一场面向未来的架构演进，还为未来的业务发展预留了充足空间。”李岩总结说。