替换 MySQL 分库分表架构，探索成本效益最优

vivo 整体上使用的数据库种类繁多，约有 1000+ 主机，涉及 15 种数据库，还有数据同步工具需要维护。此外，还有多区域多云的特性，包括东莞机房自建、海外使用阿里云、AWS RDS 数据库。

使用数据库的方式也比较复杂。例如，在一个业务中同时使用 MySQL 主从和MySQL MGR，如果涉及读写分离，还要分别叠加 Proxy 使用，数据库的多种类和架构的复杂性给运维团队带来了较大压力，因此开始探索是否有更优的数据库方案。

1. 分库分表无法满足业务需求
   1. 产销存的线下业务数据量较大，vivo 各省业务系统的数据量并不一致，比如广东省的业务量比较大，一个门店的业务系统，最大的数据库为 2TB，大省份会独立个库，小省份会共库，但是所有省份又有整合数据的需求。
   2. 整个业务系统采用分库分表架构，在查询场景，通过将各库数据聚合起来，难以保证查询的实时性和准确性。复杂查询或大数据量查询时，也会导致性能下降。
2. 资源利用率低，成本高
   1. RDS 成本高，资源利用率低：最贵的 CPU 资源利用率较低，平均 CPU 利用率不足 5%，CPU 峰值的平均值也不到 20%；磁盘和 I/O 资源利用率也偏低。在 AWS 中，存储类型和 IOPS 有绑定关系，每个系统都按未来最大规格去分配资源，系统资源的峰值时间节点也不一样，导致资源浪费。
3. 数据库扩展能力不足
   1. MySQL 数据库的可扩展性有限，依赖于分库分表进行水平扩容，带来开发运维复杂度，对于需要分布式数据库解决方案的场景不够理想。

1. 错峰超卖，提升资源利用率
   1. 从硬件方面考虑，OceanBase 的降本优势在于超卖，各系统错峰使用超分资源，不同租户之间的弹性可以分时复用，提升资源利用率。
   2. 假设对应以下三个系统，高峰期使用的资源都需要 4C8G。
   3. ●  如果使用 MySQL，需要为三个业务系统都分配 3 个 4C8G 规格的资源；
   4. ●  如果使用 OceanBase，只需要分配三个 1C8G 的租户，余 3 个CPU 资源可以共享。
   5. 另外，如果开启 OceanBase 的读写分离特性，CPU 资源还能进一步充分利用。
2. 高压缩比高性能，降低资源成本
   1. OceanBase 基于 LSM-Tree 架构的存储引擎和数据压缩比为企业降低存储与硬件成本提供了更多可能。MySQL 的数据压缩依赖于操作系统文件系统，相较之下，OceanBase 的数据压缩比是 MySQL 的 6～7 倍。
3. 完善生态工具，运维提效
   1. OCP管理平台提供了便利的部署、升级、监控、备份恢复等运维手段，一站式管理所有OceanBase集群，简化运维操作；
   2. OMS迁移平台提供了便利的数据迁移方案，支持全量、增量、反向同步等多种模式，便于业务方迁移迁出数据，包括前期的测试和后续的回退。