在数据库选型初期,我们接触到 OceanBase 并看中其两项能力:多租户能力、数据压缩能力。
知乎原有的 MySQL 架构是采用的云厂商的裸金属服务器自建而成,拥有上百台高配服务器,包含数千个 MySQL 实例(每台服务器包含4块SSD盘,每块盘上有5个 MySQL 实例)。由于缺乏数据隔离,导致MySQL 实例大小不均衡,大的 MySQL 实例增长过快抢占小实例资源,因此,资源争抢问题明显,且存储空间分配不均,进而促使资源隔离和合理分配等需求的解决被提上日程。
OceanBase 的多租户特性能够有效解决上述问题,通过资源隔离和灵活的租户管理,我们能够更好地利用服务器资源、减少资源碎片化、提高资源利用率。同时,我们也了解到 OceanBase 的数据压缩能力非常强,尤其在海量数据场景能够做到极致降本。 (一)前期调研
在正式上线 OceanBase 前,我们重点测试了兼容性、数据迁移和分区表设计等关键环节。 1.兼容性和使用限制。
测试阶段,首先需要对 OceanBase 和 MySQL 的兼容性进行详细对比和实际验证,通过将原本 MySQL 的业务数据导入 OceanBase 测试集群进行功能验证、性能压测,了解 OceanBase 的使用限制例如表长度限制等,确保业务能够平滑迁移。 2.大表的分区表设计。
MySQL 有一些大表数据量较大,单表将近3TB,为了便于后期数据管理,以及实现更高的查询性能,迁移到 OceanBase 后,需要进行大表分区设计。这就涉及分区规则、分区字段等的选择,例如:分区规则是基于二级分区还是哈希分区、分区字段是选择主查询字段还是业务拆分字段,需要 DBA 和业务人员在熟悉 OceanBase 的同时,结合业务需求和数据特点,共同设计合理的分区规则,以优化数据查询性能和提高数据存储效率。 3.有效划分租户,让硬件资源使用更优。
一般情况下,一个 observer 承接的租户非常多,涉及的资源规格也较高,例如128C512G。面对数据量不大但查询高频的业务场景,或数据量巨大但查询频率较低的审计日志数据等,该如何划分租户资源,实现集群中存储型租户和计算型租户的均衡搭配,使磁盘、Memory、CPU等多种资源得到充分利用,是该阶段需要我们考虑的问题。
(二)应用场景
由于我本人比较关注国产数据库,从OceanBase 正式开源时就开始关注它。经过下载验证、阅读官方文档、全面调研,并加入社区,调研社区用户的使用反馈等,当我确认与MySQL兼容,且产品稳定可靠以及落地可行后,逐步开始在非核心业务线、核心业务线进行验证。我们进行了OceanBase与MySQL的性能对比测试,并将MySQL大表通过OMS迁移至OceanBase,观测增量数据同步的性能。相较MySQL,OceanBase可提升至少30%的读写性能,数据压缩至少2倍。
目前 OceanBase 已在知乎的直答( AI RAG 服务)、安全、教育等多个业务线成功落地,不仅打开了MySQL大实例带来的扩展和存储瓶颈,解决了数据隔离问题,还带来了40%以上的降本效果。知乎的 OceanBase 集群规模已达7套集群,包含33个租户,共计91台高配服务器。