高德地图（以下简称“高德”）作为一款用户出行必备、拥有海量用户数据的导航软件，对系统运行稳定性要求极高。
一直以来，高德每时每刻都在生产的一些数据库中的数据已经达到数百 TB，数据量的增长不仅带来存储成本的迅速攀升，同时还带来响应性能的下降，进而影响到客户体验。
为了降低成本，避免用户体验下降，同时也是为了更好支持业务未来的增长，高德做出了数据库升级的决策。去年以来，高德已经成功地完成了多个数据库的升级，这些数据库的升级为高德探索和应用新技术、持续改善用户体验和降低成本奠定了坚实的基础。
高德成立于 2002 年，经过多年的发展，高德已经是一家领先的移动数字地图、导航及实时交通信息服务提供商，面向终端用户提供包括导航、本地生活、打车等多种服务。作为国民出行平台的高德地图，本质上是一个真实世界和用户之间的连接和服务平台，大量数据的生成和交互，也都离不开数据库的支撑。
高德业务很多，先后使用过很多种数据库，包括 MongoDB、MySQL、Lindorm、以及图数据库、时序数据库等，以满足不同业务的需求。而且，这些已经上线的数据库也会随着需求的变化不断被替换。比如，高德中用以保持手机和车载数据同步的云同步功能，最初用的就是文档数据库 MongoDB，但随着用户数量的增长和数据量的增加，性能开始变得不稳定，不时会出现抖动，后来改为了 Lindorm数据库。
如今，随着高德业务继续成长，带来高并发和海量数据存储的挑战，云同步中的 Lindorm 数据库再次面临挑战，尤其是存储成本上升问题很突出。当然，面临挑战的不仅是云同步系统，还有评价等多个系统的数据库都面临同样的压力。
“随着数据的增长，存储在数据库中的数据动辄上百 TB，而且增长很快，如何处理这些数据以降低存储成本和后续扩容及迁移成本，成为了摆在我们面前的重要问题。”高德技术服务平台负责人孙蔚表示。作为后端技术的负责人，孙蔚负责数据库的优化、数据库的选型、数据库迁移方案的制订等，也是本次数据库升级的主要负责人。
而对于财务系统情形又有所不同。财务系统一直用的是 MySQL 数据库，由于不是一个面向 C 端用户的服务，数据量上的压力其实并不大，但财务数据对数据一致性有很高的要求，特别是在部署两地三中心的容灾架构以后，如何确保位于不同地点的 MySQL 数据库之间的数据一致性很让人头疼。
鉴于数据量还处于持续增长之中，未来存储成本的压力、性能上的压力以及数据一致性等压力都将有增无减，为了更好支持公司发展，高德决定对数据库进行统一替换升级。
数据库升级的需求已经明确，接下来的问题就是数据库的选型。孙蔚表示，结合当下面临的挑战以及未来业务的发展，高德在选型过程中会重点考虑数据库以下几个方面的能力：
第一，稳定性。这是高德首先要关注的，高德如今已经成为一个基础设施，程序中依赖的数据库或服务的任何抖动都会对用户体验带来直接影响；
其次，可扩展性。高德的流量波动很大，在面对极端需求（比如国庆、春节的高峰流量）时数据库需要能够快速通过水平扩展实现扩容，确保系统稳定运行；
第三，安全性。数据库本身要足够安全，同时，数据的隔离也要做得非常好；
第四，性能好。数据库的响应要非常快，不管是读还是写。“数据库的处理时间最好在 5 毫秒以内，加上业务不超过 10 毫秒，极端情况也不能超过 20 毫秒。这个要求其实比较高，即使是 OceanBase 为了满足这个要求，也对代理层和接入层都做了针对性优化。”孙蔚介绍；
第五，高可用。出现了问题后要能快速地进行切换，切换时间要足够短，只有足够短才能将业务无感知；
第六，对单元化能力的支持。为了保证用户体验，高德现在采用的就是多地多中心的部署方式，如果数据库支持单元化可以简化应用的开发和运维。
以高德的云同步服务为例，云同步主要负责数据的云端存储，多端设备数据同步，用户多点就近接入。高德目前采用的是北京、上海、深圳三地三中心，如果不采用单元化的架构，就可能出现用户跨异地数据中心访问，延迟将不可避免。比如，从深圳的数据中心访问北京的数据中心，仅仅网络通讯一个来回可能就超过 60 毫秒。而采用单元化架构后避免了跨数据中心访问，在一个数据中心就可以完成所有操作。
另外，单元化也可以帮助“扛量”，当某个数据中心出现了故障或者遇到了高峰流量，可以借助其他的单元来临时分担流量，也为故障修复赢得宝贵的时间，这也是一种容灾方式。
“云同步业务上需要保证数据多端准确写入、及时更新，更换设备后数据能快速读取，还需要实现容灾多活。如果没有数据库的支持，就要从应用开发上、从架构设计上去实现，这无疑会加重开发的负担。”孙蔚解释说。
经过调研，最后进入高德视线的主要两类：原生分布式数据库和云原生数据库。后来经过多角度的权衡，结合实际的压测实验，多重评估、高德内部认为 OceanBase 最能满足当下需求，所以，最终选择了 OceanBase。
孙蔚表示：作为一款采用 Shared-Nothing 架构的分布式数据库，OceanBase 天生具有高可扩展性和高可用的特点，而 OceanBase 采用的一些独特技术，使得其在数据一致性、稳定性、性能以及与 MySQL 的兼容上表现优异，尤其是其高压缩的能力更是让人惊讶，数据库迁移后的成本降低非常明显。
根据高德的测算，同样的数据量 OceanBase 所需空间只有 MySQL 的 1/10 左右。结合 OceanBase 的调度等（比如冷热数据的分开处理），使得 OceanBase 的 TCO 成本相比之前的 Lindorm 能减少 10% 和 MySQL 能减少 30% 以上。
孙蔚表示，OceanBase 的几个技术特性尤其让他印象深刻：
第一，向量化引擎。向量化引擎允许一条指令处理多个数据，使得数据库在一些复杂场景效率会更高，外在表现就是更快。这一点对未来高德开发一些与AIGC相关的应用非常有价值。
其次，OceanBase 独特的存储引擎。OceanBase 在行存中又有列存，这种方式给它带来很高的压缩比，而且数据量越大优势也明显。
第三，OceanBase 全链路的缓存机制。OceanBase 提供包括数据缓存（如数据行缓存、微块缓存等）、元数据缓存（如 Partition 位置缓存、Schema 缓存、Clog缓存）等多种缓存，有效提高了 OceanBase 的性能。
最后，OceanBase 的单元化能力。作为分布式原生数据库，OceanBase 架构上的多单元同步链路、OMS 的秒级数据同步能力，保障了多机房数据同步低延迟，支撑了多机房多活的可行性，从而完美地实现了异地多活、各单元异地容灾，机房故障随时切流，用户无损。这样，原来高德需要对数据库专门进行容灾设计，现在借助借助数据库的分布式特性就自动实现了容灾，简化了整个系统的设计，也减轻了运维压力。
如今，高德已经先后完成了云同步、评价系统、财务系统等多个系统的数据库的替换升级，不仅大大节省了存储成本、订阅成本，同时，在动态扩容能力、容灾能力以及最终用户体验上也都有了明显的改善。
回顾已经完成的数据库的升级过程，孙蔚表示，虽然整个过程得到 OceanBase 原厂的大力支持，但还是遇到了一些挑战。最大的挑战就是对分布式数据库和 OceanBase 的了解不够。很多开发人员和运维人员之前没有接触过 OceanBase，要让他们能主动去学习分布式数据库、了解 OceanBase，最后能达成一致参与升级，这是项目组面临的第一个挑战。另一个比较大的挑战是如何保证数据库的平稳迁移，保证迁移过程中不出事故，也不能丢数据。
针对这些挑战高德技术团队做了大量准备工作。孙蔚介绍，他们安排专人来研究 OceanBase，甚至深入到源代码，对数据库进行充分了解，对于数据库的分区 Partition 分区的设计、主索引、二级索引的建立都进行了认真的规划。
其次，充分利用 OceanBase 等数据库提供的各种工具。比如，对 MySQL 数据库利用其 Binlog 日志和 OMS 工具来进行数据同步。有些场景使用了双写，然后通过全量的比对来验证数据是否没有问题。
第三，认真规划，递进式切流。数据库的迁移从单客户开始，然后扩展到 10 个、再到 20、到 100 个，逐步增加，确认没有问题再开始一定比例的灰度测试，最后才全部切换。
“在整个迁移过程中，一定要有回退的手段。一旦有问题，能够随时退回，这样才能保证不出问题。这一点非常重要。”孙蔚说。
显然，面对高德的海量用户带来的高并发和大数据量，这种谨慎是非常必要，因为一个哪怕很小的故障，也可能海量用户放大成一场灾难。为了避免事故，在系统运维时，高德非常强调可靠性，强调减少不确定性。比如，高德经常会做断网演练，对于应急扩容等意外也都提前做好了规划。
孙蔚表示，理论上高德是不允许进行紧急扩容的。“如果出现临时紧急扩容，说明你的设计和运维出现了很大问题。这意味着很大的不确定性，风险极高，一定要尽量避免。如果要扩容也应该是在规划之中的扩容，是有计划的，最好是自动的，这样才能降低不确定性。当然，这就要求要提高可观测性，提高运维能力。”他说。
谈及下一步的工作。孙蔚表示，随着数据库升级的完成，他们也将工作重点转向数据库的优化和一些新技术能力的挖掘。比如，当下很热的 HTAP 和 Serverless 数据库都已经进入高德的考察范围，而 OceanBase 也已经具备了这些能力。孙蔚说，高德有丰富的应用场景，无论是 OceanBase 的 HTAP 还是 Serverless 能力相信未来都会有用武之地。
