共计 3986 个字符，预计需要花费 10 分钟才能阅读完成。
导语：一家经营海内休闲游戏的公司随着其业务的倒退，表的数据量大幅减少，原始的单实例 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。
