要真正使用上 OceanBase，还需要获得公司业务线的支持。要做到这一步并不容易，因为业务部门与运维部门视角有些不一样。赵智博介绍，虽然尽快降低成本、提高稳定性对业务部门也有吸引力，但业务部门其实更关心稳定性，这是进行一切操作的前提。
“毕竟，OceanBase 是一个新生事物，虽然我们对它比较熟悉，但业务线不一定熟悉，因而会有担心、会不信任，不同意也是可以理解的。”赵智博表示。
赵智博说，需要尽可能做好准备工作，包括充分验证和测试，然后从相对边缘的业务开始，逐步让业务线建立起对新的数据库的信心。
比如，映宇宙早在去年 9 月的时候就开始试用 OceanBase，当时 OceanBase 还是 3.2 版本。例如有一个实例上的单表超过 60 万行，采用 OceanBase 后对内存的需求甚至超过了原来的 MySQL。一直等到今年 4 月份，OceanBase出新版，经过验证对一个实例上的单表支持能力超过 100 万，才准备真正迁移。后来，在迁移时和业务部门商量，对大表进行了归档，将表规模控制在 12 万行。
经过确认OceanBase在功能和性能方面都符合映宇宙的需求之后，下一步就是制订迁移规划。
赵智博介绍，在迁移前他们会进行仔细地调研和规划。因为 OB Cloud 是按节点来申请的，价格根据核心数量、内存和存储大小而有不同。比如，OceanBase 最常用的节点规格为 8c，而很少有一个数据库就能跑满一个实例，因此需要规划哪几个数据库共用这一个实例。
为了充分利用资源，同时确保稳定性，在规划中还要尽量让业务量大的和业务量小搭配，以避免资源的争抢。另外，迁移之后，还需要进行两个数据库双跑一段时间，只有确认数据没有问题才算正式完成迁移。所有这些都需要提前规划。
不过，对于常见的因数据库的更换需要对应用程序改造这个挑战，在映宇宙没有成为太大的问题。映宇宙的核心业务所使用的 MySQL 5.6 版本，而 OceanBase 在这个 MySQL 版本的兼容上做得非常好，映宇宙绝大部分应用程序只需要更改下SQL Model 就可以非常平滑地迁移过来。
赵智博说，这与映宇宙在研发上有着相对规范的开发要求和发布流程有一定关系。在公司内部，对与数据库有关的 SQL 语句编写有明确的规范，避免采用数据库专有的特色能力和函数，否则无法上线发布，目的就是尽量减少后期因数据库变更要改写程序。
当然，对于数据库更换这么重大的一个工程，麻烦总还是会有的。赵智博介绍说，麻烦主要是在后期的运营中。比如，曾发生过由于数据库中的某些逻辑判断不合理，引发读放大，从而导致只读节点响应延迟，但后来 OceanBase 做了紧急修复很快解决了，还有系统参数的调优以及多版本的验证等问题也都在 OceanBase 技术人员的帮助下迅速得到解决。
由于前期准备充分，整个项目进展得很顺利，从今年 4 月份映宇宙开始真正开始着手进行多个系统数据库的迁移，借助 OceanBase 的数据迁移工具 OMS 和运维管理工具 OCP，今年 5 月份，映宇宙国内的数据库系统已经基本完成，国外由于产品线相对复杂，还在稳步推进之中。迁移后，目前所有业务系统运行稳定，成本和性能相比之前均有明显提升。
随着数据库迁移工作的顺利推进，赵智博开始把关注点落到 OceanBase 数据库功能的利用上。赵智博表示，Serverless 是他很感兴趣的方面之一。由于映宇宙的业务具有明显的波峰波谷特性，尤其是直播业务，时常因某个明星或者某个热点而爆火，从而形成很大的瞬时压力。这种业务特征非常适合采用 Serverless，因此，他也正在评估和学习，希望为映宇宙引入Serverless 做好准备。
