本文作者：胡玉龙，快手技术专家
快手在较初期采用了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 云数据库现已支持免费试用，现在申请，体验分布式数据库带来全新体验吧 ~