本文作者:胡玉龙,快手技术专家
快手在较初期采用了OceanBase 3.1版本成功替换了多个核心业务、数百套的MySQL集群。至2023年,快手的数据量已突破800TB大关,其中最大集群的数据量更是达到了数百TB级别。为此,快手将数据库系统升级至OceanBase 4.x版本,从而显著提升了业务的稳定性和运行效率。
本文将分享快手在OceanBase版本升级后的实际应用情况,期待与大家共同探讨和交流版本升级过程中的宝贵经验。
快手应用OceanBase 4.x版本现状
当前,快手的数据量已经增长到了PB级,从原来近200节点增长到了近300个节点。线上共部署9套OceanBase集群,其中数据量较大(20T以上)的集群已经升级4.2或4.3版本,还有一半数据量较小的集群(10T以下)仍在3.x版本。
从下图来看,4.x版本的数据似乎没有增长。但如果在3.x版本不升级的情况下,近一年随着业务的发展,数据量会增长1.5TB左右,数据节点也会提高一倍。这就体现了版本升级的妙处,OceanBase 4.x 版本相较于 3.x 版本能够更极致地压缩数据,节省存储空间,从而节约存储成本和机器成本。
版本升级经验交流
俗话说没有一款产品是万金油,在使用OceanBase 3.x版本时,业务人员希望将不完美的功能进行优化。例如非分区表,当业务量小时,单表很小也无需分区,随着业务量的增长,单分区表可能会把单机CPU打满,或者磁盘占用较满导致单副本变得庞大。此时OceanBase老版本不支持从单分区变为多分区,而4.x版本能够做到。同时,业务人员希望数据库的查询速度可以更快。OceanBase 4.3版本的行列混存特性,可以极大提升复杂查询的性能。
除解决业务需求外,我们升级OceanBase版本的重要因素就是跟随版本迭代,积累运维经验。
- 版本在快速迭代中,需要保持业务版本不落后太多。当我们决定升级时,距离OceanBase 4.2.1 LTS 版本推出已经过去 7 个多月,内核足够稳定,周边生态工具也在不断适配,我们可以放心升级。
- 从3.x版本升级到4.1版本再升级到4.2/4.3版本,我们都是提前在非核心业务场景验证新版本的稳定性和功能,为后续在核心场景使用积累经验。
下面以交易核对场景和支付场景介绍快手在升级OceanBase版本的过程和效果。
核心业务场景1:交易核对
电商业务作为快手最重要的一部分,其交易核对场景是我们的核心场景,要求数据库快、稳、抗压。
首先,目前交易核对场景的主库读写仍在MySQL中,为保证全局数据的一致性,避免MySQL落库失败导致的数据遗漏问题,我们在底层使用OceanBase进行全局核对。根据业务特性,要求我们在MySQL的binlog写入数据后,立即在OceanBase的全局查询中出现。也就是说业务要求返回延迟为毫秒级,否则会影响核对结果。
其次,业务对数据库有着强稳定性要求,例如,在大型直播时,流量迅速上涨百倍,如果数据库抖动,会导致大量的核对失败。因此,在交易核对场景下,数据库不仅需要再日常流量峰值时保持长期稳定,还需要在流量高峰时没有抖动。
再次,当数据量超百TB,单集群数据的单副本达到20TB左右时,随着单表数据的增大,对系统资源消耗会越来越多,进而影响数据库的响应时间。因此,读写请求峰值达到 QPS 百万级要求数据库足够平稳,响应时间不受影响。
下图是OCP监控的OceanBase在交易核对场景的表现,可以看到曲线比较平稳,几乎没有抖动,完全满足业务需求。
核心业务场景2:支付业务
在快手电商场景时常有查询数据的需求,比如商家、客服查订单收益,再比如支付网关聚合查询。目前业务数据量在 OceanBase 单集群达到百 TB 级别,同时单表数据在 10 TB 以上,聚合查询时还需要频繁加索引,如果单表DDL时间太久就会影响业务。
我们的支付业务特点是大量写入(10w/tps),伴随少量复杂查询。此前我们使用分布式数据库某DB来支撑支付业务,它使用range 分区,每个表自动分裂,在写数据量较大时,无法利用所有机器的性能,导致在流量较大的情况下性能较差,如果遇到流量高峰,就需要业务限流才能保证底层查询的稳定性。
在引入OceanBase 3.1版本后,使用 hash 分区,写入性能大幅提升;DDL 速度更快,至少能保证业务流量高峰时不再限流。升级到OceanBase 4.3版本后,成本收益进一步提升;复杂查询速度更快,基本在 10ms 内完成。我们支付业务中还有一些AP查询需求,在使用OceanBase 3.1版本时,只有行存,业务需要忍耐一定的查询延迟,OceanBase 4.3版本的行列混存特性使查询更实时,写入延迟在1ms 以内。
下图是支付业务在升级到OceanBase 4.x版本后的线上表现。
版本升级总结
总的来说,快手在升级OceanBase版本后成本变得更低,查询变得更快。以支付网关为例,在 3.1.x 版本,该集群规模为 65 节点,是线上环境规模最大的集群,升级前数据量 450TB。升级后机器规模缩减为 45 台,数据量压缩至 330TB。机器成本降低了31%,数据量比之前压缩了约27%。
在一些 TP + AP 场景下,最初我们使用OceanBase 3.1版本替换 MySQL,满足业务的HTAP 需求。升级为OceanBase 4.3版本后,更加稳定,性能更高,分析耗时更快。另外,在OceanBase 3.x 版本里面,我们需要将OceanBase数据同步到下游对接大数据生态,但受限于 Binlog 不支持所以操作起来不太方便。在OceanBase 4.2 版本, Binlog 兼容 了MySQL Binlog ,这个问题也得到了解决。
此外,我们也感受到了OceanBase生态工具侧的迭代升级。例如OCP、ODC等在2022年之前容易出现升级、扩容方面的问题,现在我们用OCP集群12台机器运维管理9套集群都没有出现扩缩容或监控告警相关的问题了。当OCP诊断到问题时能够自动解决,无需人工干预。不过有一个问题,对于业务来说,有时候排查问题就需要观察 p99、p999 监控信息,而当前 OCP 的监控看不到 p99、p999 监控线。从官方了解到,预计 11 月支持该功能。
整体来说我们使用 OceanBase 很顺畅,也积累了非常多的使用经验,有机会给大家分享更多 OceanBase使用姿势。
OceanBase 云数据库现已支持免费试用,现在申请,体验分布式数据库带来全新体验吧 ~
标签:升级,版本,快手,业务,PB,OceanBase,数据量 From: https://blog.csdn.net/OceanBaseGFBK/article/details/142635845