随着多基础设施成为行业发展的主流趋势，数据库选型时需要考虑哪些关键因素？对于云数据库的升级策略，又该如何制定？OceanBase《DB 大咖说》第五期特别邀请了映宇宙（原映客）的数据库负责人赵智博先生，做为一位资深的DBA专家，在数据库运维方面有超过 10 年的经验，他将分享他在此领域的丰富经验。
2022 年 6 月，映客宣布更名为「映宇宙」，英文名 Inkeverse 是 Inke 与Metaverse的结合，体现了集团全新战略方向：进一步走向海外，将现有产品矩阵和元宇宙相结合，进行社交升级打造覆盖更多场景的多维互动社交体系。在全新的业务规划下，23年 4 月份，映宇宙开始对国内、国外所使用的数据库进行全面升级，赵智博是该项目主要的技术负责人之一。
赵智博在 2023 OceanBase 产品发布会进行分享
随着映宇宙业务种类的多元化和经营范围的不断扩展，业务对后台系统提出了更高的要求。数据库作为后台系统的核心软件，面临越来越大的挑战，对数据库进行升级和替换由此进入了映宇宙管理者的议事日程。
一、成本不断攀升，数据库面临升级需求
作为一家互联网企业，映宇宙的系统基本都搭建在云上。由于不同业务有着不同的需求，映宇宙与多个云服务商开展合作。比如，在国内市场有阿里云、腾讯云、火山引擎云，在国外则有 AWS 和谷歌云等。
映宇宙在数据库的部署上也非常多样化，包括 MySQL、MongoDB、Redis、ClickHouse 数据仓库等等。多样化的选择使得技术栈变得复杂，成本攀升的同时，也给映宇宙的数据库运维带来了巨大挑战。
映宇宙国内业务系统的 MySQL 有数十套之多，先后部署了 10 多个集群，有 2000 多个实例。由于业务种类多，选择的 MySQL 服务的模式也有各有不同，有购买云服务器实例后自建的，也有选择云服务商的 RDS 版本。随着业务的增长，成本上升很快。特别是，一些业务（如直播业务）涉及资金的交易，需要高可用、高稳定，因而选择的是金融级 MySQL 的 RDS，其成本也就比普通 RDS 贵得多。
“直播业务是我们的核心业务，所使用的 MySQL 数据库集群规模比较大，对服务的稳定要求比较高，因此选了金融级的数据库云服务。”映宇宙数据库负责人赵智博说。
而社交类产品数据库面临的挑战又有不同。社交类业务对可用性、稳定性容忍度要高一些，普通 MySQL RDS 也可以满足需求，但这类业务数据量非常大，存储成本很高。同时，数据量太大还导致数据搜索和读取变慢，影响到了用户体验，集团只得单独购买了数据库实例用作只读节点，成本也相应地增加了。
在海外市场，映宇宙还面临着数据库的技术支持问题。由于映宇宙研发团队在国内，与国外的数据库技术支持团队之间的沟通不太方便。如果有问题，只能通过邮件或者电话来解决，响应的及时性和国内有不小的区别。同时，还有扩缩容的延迟问题，映宇宙的业务流量变化很快，扩缩容很频繁，而国外的数据库每次扩缩容会有 10 秒以上的延迟，而且成本也明显更高。
另外，映宇宙同时面对多个云服务商，不同的数据库分散了运维、升级精力。搭建统一的数据库，简化软件栈，实现统一的监控和运维，这也是映宇宙希望实现的目标。
二、稳定、低TCO、不挑基础设施，敲定 OceanBase
“既要满足海量数据的管理需求，并且成本降低，还要能满足高稳定、高可靠、统一运维，这是映宇宙对数据库的总体要求。”赵智博说。基于这样的要求公司从去年开始考察和评估各种数据库，并为此做了大量调研和测试，直到今年4月份才最后敲定 OceanBase。
赵智博介绍说，选择 OceanBase 首先一个原因是 OceanBase 有很厚的技术积淀，已经有很多的成功案例，要比其他数据库更让人放心。因此，一直在关注它。早在 OceanBase 宣布开源时，映宇宙就在内部开始试用，还专门进行过压测，并和同类产品进行过对比，OceanBase 的表现都令他们很满意。
当然，真正决定要选 OceanBase 的原因还是在于 OceanBase 稳定性更好，同时能明显降低使用成本。
OceanBase 是分布式数据库，其分布式架构、多副本的特性使其可靠性和可用性都能得到很好的保证，不需额外支付费用就具备金融级 MySQL 的高可靠和高可用性，从而在成本上可以得到节约。同时，OceanBase 的分布式架构中可以很简单地增加节点，而无需单独购买只读节点，简化了运维，成本上也降低了40%-50%。
存储空间上的节省也是映宇宙非常认可的。集团的社交类业务面对海量的用户，数据量非常惊人，成本压力很大，而 OceanBase 在数据存储上采用了专门的压缩技术，最多能节约 2/3 的存储空间，成本优势非常明显。
另外，OceanBase 的云服务——OB Cloud 云数据库在阿里云、腾讯云和国外的 AWS 等主流云上都有部署。这就意味着，可以获得更简便、直接、统一的运维、管理、升级体验。“选择 OceanBase 可以在多基础设施架构下实现统一的技术栈，这也是我们最后选 OceanBase 的一个很重要的因素。”赵智博表示。
三、精心规划，顺利迁移
要真正使用上 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 做好准备。
写在最后：
《DB大咖说》是一档立足数据库领域，关注职业成长与前沿趋势，主要面向架构师、CTO/CIO、DBA、业务负责人、CEO 等推出的原创栏目。我们初衷是围绕数据库领域的职业发展、趋势洞察、选型实践等话题，邀请领先企业的实干者、数据库领域的资深专家，从自身的职场积淀出发，结合所见所闻所思所感，输出一些对行业有价值的优质内容和职场方法论。
