手机端wordpress模板,免费建站优化,wordpress 跳转,深圳网站制作建设公司本文作者#xff1a;胡玉龙#xff0c;快手技术专家 快手在较初期采用了OceanBase 3.1版本成功替换了多个核心业务、数百套的MySQL集群。至2023年#xff0c;快手的数据量已突破800TB大关#xff0c;其中最大集群的数据量更是达到了数百TB级别。为此#xff0c;快手将数据… 本文作者胡玉龙快手技术专家 快手在较初期采用了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 云数据库现已支持免费试用现在申请体验分布式数据库带来全新体验吧 ~
