导语：一家经营海内休闲游戏的公司随着其业务的倒退，表的数据量大幅减少，原始的单实例MySQL在性能方面曾经无奈满足业务需要，因而须要寻求新的解决方案。本文次要介绍了选用OceanBase的考量因素、测试状况，分享一些实践经验，给大家提供一些参考。业务痛点及选型背景在游戏业务倒退阶段晚期，咱们思考到迭代迅速、运维简略、架构轻量，使后端数据库均采纳了AWS上的MySQL单实例，承当游戏运行、经营剖析等各项业务。经营剖析业务次要面向公司外部员工，用于察看生产业务经营状况、追踪异样用户数据，针对游戏日志进行剖析计算，解决生成BI报表。该业务简直24小时都有数据写入，大部分数据量集中在几张日志表、流水表中，且21:00-24:00点的数据量会是其余时段的1-2倍。随着业务的倒退，咱们发现，经营剖析业务应用MySQL数据库的弊病越来越凸显。弊病1：性能瓶颈。随着多张表一天产生的数据量由百万级增长到亿级，原来的MySQL实例在读场景的性能呈现显著下滑，例如，针对单天的统计计算从原来的10s提早至300+s能力出后果；在写场景下，因为80%以上的数据集中在几张日志表、流水表中，且24小时不间断写，造成写热点、数据入库慢等问题。弊病2：剖析瓶颈。写热点场景下，数据入库慢，叠加读性能下滑的影响，导致经营剖析的数据始终有提早，仅能获取准实时报表。弊病3：扩大瓶颈。数据量突增的状况下，呈现上述性能、剖析瓶颈后，临时只能降级MySQL配置，但随着业务的进一步扩大，升无可升。同时，因为MySQL的局限性，难以采纳线性扩大计划，即便想用分库分表，后期的利用适配革新及前期的运维工作量也很大，无奈短时间解决问题。基于上述三个弊病，咱们在制订解决方案时想到了关注已久的原生分布式数据库OceanBase。早在OceanBase开源（2021年6月）前与CloudCanal的单干直播中，让咱们理解到这款数据库产品。当咱们再度想起OceanBase时，它曾经开源并打算公布OceanBase 4.0版本。在咱们从OceanBase官网及社区深刻理解相干信息时，察看到OceanBase的文档比较完善，其写性能、AP能力、扩展性、迁徙老本都合乎咱们对新计划的预期。当即开展小规模调研。即搭建低配测试环境察看根本的语法兼容和业务适配。
测试与部署在小规模测试过程中，用户数据突增，数据从原来的日增百万级别，间接跳跃到日增1.2亿左右，公司外部报表业务靠近瘫痪，更新替换火烧眉毛。咱们迅速搭建了测试环境，测试公司根本的业务流程、兼容状况，为正式部署做筹备。测试过程中次要考量以下几个因素。1、高性能抽取MySQL中多张日志、流水表的局部数据至OceanBase 4.0单节点中，测试各类剖析SQL的查问性能，如分组求和、总数统计等。比照示例：模仿单表2600w的数据量，OceanBase中全表count(1)毫秒级响应，而在MySQL中执行是分钟级。
2、低成本数据存储方面，原来千万级别的数据在MySQL中大略占用超400 GB的存储量，迁徙到OceanBase中亿级别的数据仅需260 GB。MySQL 5.7迁徙至OceanBase4.0时，应用了MySQL dump导出MySQL 5.7数据，再应用OBLOADER 4.0导入OceanBase 4.0，方便快捷。迁徙至OceanBase4.0当前，少部分存储过程存在不兼容的状况，在代码层面做了批改，相较于分库分表的革新、运维计划，这块的人力投入比拟可控。3、易用性采纳OBD形式部署单节点实例简略快捷，另外自带的ODC开发者工具和以前习惯应用的Navicat都能不便的测试OceanBase。基于上述测试数据，咱们决定部署OceanBase 4.0，生产环境部署信息如下。版本OceanBase：4.0.0_CE_BP1OBD：1.6.2拓扑OceanBase：单节点OBServer+OBProxy配置16C/64G/3*1T租户资源：12C/48G而在理论的测试到生产过程中，线上业务飞速发展，单表日增数据量到上亿级别，导致在生产环境理论跑业务剖析SQL时，效率不佳。因而，咱们针对几张外围表的查问也做了肯定的优化措施。上面以SQL为例开展阐明，以供参考。比方这是一张游戏的流水表，拿到用户的流水记录当前，咱们在外部会统计最近几天，不同游戏、不同渠道用户的各类生产状况，依据统计的各游戏的经营信息及时调整游戏的流动策略。CREATE TABLE games_play_flow (event_time int(11) DEFAULT NULL COMMENT,game_id int(5) DEFAULT NULL COMMENT,account_id bigint(20) DEFAULT NULL,uid bigint(20) DEFAULT NULL,channel_id varchar(20) DEFAULT NULL,play_id varchar(100) DEFAULT NULL,mfr_id int(11) DEFAULT NULL,money_type tinyint(4) DEFAULT NULL,output bigint(20) DEFAULT NULL,consume bigint(20) DEFAULT NULL,
KEY idx_ix_event_time_63917445 (event_time) BLOCK_SIZE 16384 LOCAL,
KEY idx_ix_account_id_1050842020 (account_id) BLOCK_SIZE 16384 LOCAL
) DEFAULT CHARSET = utf8mb4 ROW_FORMAT = DYNAMIC COMPRESSION = 'zstd_1.3.8' REPLICA_NUM = 1 BLOCK_SIZE = 16384 USE_BLOOM_FILTER = FALSE TABLET_SIZE = 134217728 PCTFREE = 0
SELECT /+ parallel(10)/ "2022-12-09" date,
game_id,
channel_id,
sum(output) as pay_output,
sum(consume) as pay_consume
from games_play_flow
where money_type = 2
and event_time between 1670515200 and 1670601600
group by game_id ,channel_id
在测试此类业务SQL的过程中，也呈现了一些意料之外的问题，在日增数据量突增的状况下，OceanBase4.0中单表分组统计SQL性能体现没有在测试环境的体现好。并且因为业务24小时平均写入的特点，业务没有显著的高下峰期，导致当天最新数据入库时，统计信息未更新，统计最近三天经营数据时，SQL执行打算不走索引。咱们也和OceanBase社区的同学一起磋商了解决方案，做了三方面的工作，最终保障了业务SQL的性能满足经营需要。第一，从新布局经营数据的保留周期，打算仅保留1-2个月数据，并且将多张外围的单表（几亿行数据）革新为分区表，按天分区；第二，依据CPU占用减少SQL执行的并行度，利用分区裁剪+event_time索引晋升查问效率；第三，针对统计信息未及时更新的问题，定时工作触发手动收集统计信息。实际总结从整体来看，选用OceanBase 4.0对公司业务性能的晋升还是很大的，也为公司节约了很多老本。首先，解决了MySQL的性能瓶颈问题，根据生产环境理论运行状况，分区表的革新加上OceanBase准内存架构，解决了热点表写的问题，OceaanBase 4.0单机写性能是之前MySQL的5-6倍。其次，针对两条业务线（MySQL与OceeanBase）在游戏正式服的查问性能体现，对于分组聚合查问业务，咱们按天进行数据分区，MySQL对单天的数据进行统计计算须要130s，而OceanBase 仅需18s，且OceanBase业务线日增数据是MySQL业务线的2倍左右。按这样的比例来算，同配置下，在咱们的业务场景下OceanBase的分组查问性能是MySQL的12倍左右。性能失去了微小的晋升。当然，在业务切换到OceanBase 4.0的过程中，咱们也遇到了一些问题，比方上文提到的刚开始启用生产环境发现按天分区的分区表查问性能和测试环境相差较大，起初同OceanBase社区的同学一起疾速定位到了问题。原来是当天的分区统计信息未收集到，导致查问语句走的全表扫描，通过手动触发收集分区信息后，查问性能就立马上来了，据理解，OceanBase 4.1版本将提供在线收集统计信息性能，解决这个问题。除此以外，咱们还反馈了一些对于兼容性、性能等问题，OceanBase社区的同学也一一做了解答，可参考如下：cpu_count不实时失效：https://ask.oceanbase.com/t/topic/35602067mySQL迁徙到ob遇到兼容问题：https://ask.oceanbase.com/t/topic/35601905将来畅想总的来说，在本次业务解决方案替换过程中，咱们重点关注于AP场景下的性能优化，期间遇到的一些问题都已解决，但还有些将来可能遇到的问题，咱们也做了一些布局。将来会将OceanBase4.0BP1降级至正式版本。为反对业务倒退，后续可能会持续扩大实例节点数，针对大表优化，可能进一步做二级分区。在运维治理方面，试用OCP Express，简化集群治理的操作。这次试用OceanBase 4.0，整体而言比拟惊喜，短时间内的调研、测试、替换上线，既解决了咱们的业务痛点，又不必放心扩大问题。将来，我也会积极参与OceanBase的社区，和大家共迎更好的OceanBase。