支付宝将数据迁移至OceanBase历史库后，得到了哪些收益？

我们都知道，流水型业务的数据量会随着时间不断增加，而当数据量增长到一定程度，便会严重影响数据库的性能，甚至导致数据系统出现容量瓶颈。为了解决这一问题，“历史库”应运而生。

所谓“历史库”，就是存储线上数据库超过一定时间数据的数据库，它的出现一方面可以确保线上库的数据量可控，保证业务的可持续发展；另一方面也能确保历史数据不丢失，当使用者需要历史数据时，也可以在历史库中进行查询。

更重要的是，将数据迁移至历史库后，还能取得显著的降本增效效果。就拿支付宝来说，其将数据迁移到OceanBase历史库后，单位空间磁盘成本降低到线上机器的 30% ，总体成本下降 80% 左右，甚至有些业务的存储成本降低到了原来的 1/10。

“三步”实现历史库迁移

支付宝在启动历史库之前，其在线库集群已经积压了近两年的历史数据，占用了大量机器资源，并且新的数据还在爆发式增长，存储空间压力与日俱增。为了释放在线库存储空间，提高资源利用率，支付宝决定将历史数据迁移至OceanBase历史库。

但是，迁移数据说起来简单，做起来却困难重重。迁移过程中既要保证数据的安全，不影响线上业务或历史库性能，还要确保迁移后数据的完整性和操作历史可查询。基于此，支付宝通过三个步骤，实现了OceanBase历史库的迁移：

第一步，将在线库历史数据迁移到历史库。迁移是通过查询条件获取主键，按主键顺序批量扫描数据，每次扫描 n 条（ batchsize 可配置），批量插入历史库，同时记录每批迁移记录的主键、时间、源库、目标库等信息，保留在 metadb 中，可查询历史操作轨迹，以防止异常情况下重新开始。迁移程序需要关注历史库内存消耗情况，具备防导爆功能。

第二步，应用修改历史数据切流时间配置，访问历史库。当所有表时间节点之前的历史数据全部迁移到 OceanBase 历史库后，应用调整历史库切流时间配置，将时间节点之前数据查询流量切到历史库，验证正确性。此时在线库和历史库均包含时间节点之前的数据，如果发现异常时，应用可回滚。

第三步，在线库删除历史数据，回收空间。当第二步切流验证无误后，按同样的规则，根据中间库中的记录，批量查询历史库对应的记录全信息，主键匹配删除在线库记录，此时在线库删除的记录，肯定在历史库存有一份，不会丢失任何数据。与正向迁移一样，反向删除在线库数据，需要记录位点，防止异常情况从头开始。同时关注在线库内存消耗，防止内存写爆。

使用历史库后收益显著

截至目前，支付宝已建设 20 多个历史库集群，在其内部覆盖交易、支付、充值、会员、账务等几乎所有核心业务，总数据量 95 PB，每月增量 3 PB。其中，最大的交易支付集群组数据量 15 PB，每日数据增量可达到 50 TB。

与此同时，支付宝践行历史库的决定也为其自身带来了显著收益，具体来看：

首先，成本下降 80% 左右。因为历史库采用成本更低的 SATA 盘来搭建 OceanBase 数据库集群，单位空间磁盘成本降低到线上机器的 30%，同时使用更高压缩比的 zstd 压缩算法，使得总体成本下降 80% 左右。值得一提的是，如果线上是 MySQL、Oracle 等传统数据库，那么成本会降低更多，因为 OceanBase 本身的数据编码、压缩以及 LSM-Tree 的存储架构等，使得存储成本只有传统数据库的 1/3。

其次，弹性伸缩能力降低运维成本。历史库使用 OceanBase 三副本架构，每个 zone 中有多个 OBServer ，通过分区将数据分散到多个 unit 中。OceanBase 具备业务无感知的弹性伸缩能力，并且可以通过扩容节点增加容量、提升性能。这也意味着历史库可以不再受限于磁盘大小，通过少数集群就可以涵盖所有业务的历史库，降低运维成本。

另外，数据强一致，故障快速修复。数据迁移相当于一份数据归档及逻辑备份，如果这些数据发生了丢失，那么后续需要做审计、历史数据查询的时候，数据就对不上了，这对于很多业务尤其是金融业务而言是无法忍受的。而OceanBase 底层使用 Paxos 一致性算法，当单台 OBServer 宕机时，可以在 30s 内快速恢复，并保证数据的强一致，降低对线上查询及归档任务的影响。

支付宝使用OceanBase历史库的这一实践，不仅为自己降本增效，也为后续重要业务的历史库迁移改造提供了可靠的成功案例，更为 OceanBase 数据库走向政企、泛互等其他重要领域树立了典型示范，可以说是一举多得。