高德应用OceanBase云数据库的升级选型与迁移干货

业务背景

高德，DAU已在亿级，时时刻刻都持续不断地产生着庞大的数据。随着数据量的迅猛增长，对现有的业务数据存储能力构成日益严峻的挑战。

以我所在部门中的某一大型服务为例，其存储在XDB中的数据量往往达到数百TB之巨，且TPS（包括QPS）维持在万级水平。如何高效地管理这些数据，并在保证性能的同时降低未来的扩容、迁移以及长期存储成本，已成为我们急需解决的首要问题。同时，随着高德在做本地服务上越来越深入，如何在业务发展期提前技术布局，保障现在和未来服务可用性和稳定性，以应对未来业务的飞速成长（参考高德打车的业务成长速度），也成为我们的重点关注之处。

综合我们已知的隐患，和在技术上提前布局未来的需求，我们需要解决以下几个问题：

1. 透明可扩展性、降低维护成本。如何让数据库能跟随业务的发展而增长容量，可依据业务量动态扩缩容（在业务初期使用小规格的存储，随着业务发展可通过增加机器横向扩展），而减少数据迁移带来的技术风险和迁移成本？ 
2. 节约成本，保持性能。面对大体量的业务（如存储TB级别），如何降低存储成本，同时又保持性能在可接受范围内（比如用ODPS存储TB数据成本低，但读写时间太长，无法做在线业务）？
3. 可用性、稳定性、容灾能力。对于DAU过亿的应用，任何故障都会被无限放大，因此服务的稳定性至关重要，如何提高存储的稳定性，提升服务的可用性和稳定性（同城及跨地域容灾能力）？
4. 强一致性。面对结算财务类数据时，如何保证强一致性，保障数据不丢失，即使主节点挂掉，主从切换，能保证已写入主节点的数据不会丢失。
5. 兼容性、降低改造成本。支持MySQL（XDB）协议，可实现存储平滑升级，降低业务系统的代码改造成本，最好的情况是业务系统不需要更改对存储系统操作的SQL就可以实现改造升级。

面对以上的问题，我们需要达到以下六个目标。

1. 提升扩展性，提升数据库弹性扩缩容的能力，使存储横向扩展对上层系统透明，降低数据迁移的风险。
2. 可进行数据压缩和数据共享，减少数据占用的存储容量，降低费用成本。
3. 提升存储稳定性，使系统拥有高可用和容灾能力，能拥有应对机房级别甚至城市级别的容灾能力。
4. 能提供强一致的存储保证，对于结算财务类的数据，可保障较高的一致性，而非用最终一致性的妥协换取其他方面的能力。
5. 兼容原有存储（XDB）的协议，至少是大部分常用协议，可极大减少业务系统的改造成本，实现业务系统所用存储的平滑升级。
6. 要支持较高并发读写能力。

为了实现以上的预定目标，对市面上比较流行数据库的进行研究和对比，以便选出更适合我们场景的数据库。

数据库方案选型对比

单机版的数据库当然无法满足我们现在的需求，而对于关系型数据库的三个发展方向： Sharding on MySQL 、NewSQL 和Cloud Native DB ，都各有各的应用场景，在选择前先简要介绍下三个方向的技术。

Sharding on MySQL 在应用侧或代理层做分片来管理多个MySQL物理库，来解决MySQL单机容量和性能不足的问题。我们正在使用的TDDL就是该架构，虽然计算存储资源可扩展，但在扩展和数据迁移时，业务系统层面需要做大量的改造和业务数据的灰度，为了保证业务不停机会产生大量的改造成本和数据迁移的风险。

NewSQL 数据库，在国内以TiDB和OceanBase这类原生支持分布式的关系型数据库为代表，主要也是为了解决MySQL的问题，和Sharding on MySQL不同的是，NewSQL将分片功能作为数据库的一部分来实现，并提供了动态扩缩容的能力，且对上层业务透明，具备透明可扩展性。

Cloud Native DB（云原生数据库）在国内以PolarDB为代表，具备池化的资源，也可以实现存储资源的动态扩缩容，其一般采用主备方式来实现高可用，同时其扩容和主备探活等功能需要大量依赖外部系统。

为了解决现有问题，减少开发和维护成本，我们选择了NewSQL和Cloud Native DB作为选型方向，并对代表数据库TiDB、OceanBase和PolarDB进行简要对比。

在对比TiDB、OceanBase和PolarDB前，先介绍下其分别采用的架构知识作为补充。TiDB、OceanBase采用的Shard-nothing架构的每个节点有独立计算和存储功能，且节点之间不共享数据。PolarDB采用的Shared-Storage（即 Shared-disk）架构是在存储层做了统一和共享，但计算节点是独立节点。

选型对比

经过多角度的考虑和平衡，我们最终选择了OceanBase作为数据库升级的目标