MySQL替代升级：怪兽充电历史库实现降本增效

怪兽充电2017年成立，并后来者居上于 2021 年在纳斯达克上市。早在三年前怪兽充电的累计注册用户超 2 亿，到2023第二季度，注册用户数已经到了 3.625 亿，日均单量达 190 万笔。作为共享充电宝第一股，业务增长迅速，以至于业务架构不停地增加组件。

持续涌入的用户带来了业务的快速增长，业务系统架构逐渐变得复杂，目前使用MySQL数据库作为历史库，存在大量问题，包括资源的浪费、维护成本高，架构复杂等因素。

1. 混合云架构组件繁复
   1. 持续涌入的用户带来了业务的快速增长，业务系统架构逐渐变得复杂。目前采用的是混合云架构，由于系统中微服务和数据组件较多，因此开发了维护云+IDC、覆盖基础设施/中间件/微服务的 DevOps 平台 Hydra 进行统一维护管理。用到数据库包括MySQL、Redis、ElasticSearch、MongoDB等等。
2. 数据库实例多、运维成本高
   1. 历史库集群较大，使用分库分表技术，从 8 个库分到 64 个库（schema），放到 8 个实例中，总体数据量约 9.6TB，单库中最大的表数据超过 2 亿行。并且在业务数据量不断扩大的情况下，后台查询若是用实时库查询，其索引无法覆盖所有的查询场景，由此引入 ElasticSearch 集群。迁移服务也写入 ElasticSearch 集群，通过 Binlog 订阅实时数据库的数据，并使用 ShardingSphere JDBC接入迁移服务 ，整体架构复杂。
3. 数据库扩容麻烦，无法动态扩容
   1. MySQL 水平扩容的方式是分库分表，维护成本相对更高，无法平滑实现快速扩容，对业务等都有一定的影响和侵入性。

1. OceanBase 高级压缩技术
   1. 经过对 OceanBase 和 MySQL 数据存储占用的对比：如果部署单实例，数据占用对比是 1:6.8；如果部署 OceanBase 三副本，MySQL 主从两副本的情况下，数据占用对比为 1:4.6。由此可见，OceanBase 在存储方面的优势显著，可以显著降低 IDC 的存储用量。这也主要得益于 OceanBase 的数据编码和通用压缩能力，大大提高数据的压缩比。
2. 业务平滑迁移，多库数据汇聚
   1. 使用 OceanBase 官方提供的 OMS 同步数据。同步 64 个数据库到 OceanBase，根据OMS 的配置迁移对象的匹配规则能力，使分库分表的数据源迁移到 OceanBase 变得非常简单高效，8 个数据库实例共 64 个库，建 8 个同步任务就可以完成迁移，通过简单的配置可以实现每个实例上多个库的数据汇聚同一个 OceanBase 库。