做微信公众号第三网站,做网站和做商城的区别在哪里,济宁网站开发,京东网站网站建设是什么从 2023 年 9 月测试 OceanBase#xff0c;到如今 3 个核心业务应用 OceanBase#xff0c;国内最早卡牌游戏研发者之一的游卡仅用了两个月。是什么原因让游卡放弃游戏行业通用的 MySQL方案#xff0c;选择升级至 OceanBase#xff1f;杭州游卡网络技术有限公司#xff08;…
从 2023 年 9 月测试 OceanBase到如今 3 个核心业务应用 OceanBase国内最早卡牌游戏研发者之一的游卡仅用了两个月。是什么原因让游卡放弃游戏行业通用的 MySQL方案选择升级至 OceanBase杭州游卡网络技术有限公司以下简称“游卡”公共支持中心运维部负责人俞振佳分享了这一数据库替换历程和实践经验。 作为国内最早的卡牌游戏研发者之一游卡拥有以桌游为代表的线下社交场景和以线上游戏为代表的数字文化场景。核心业务是围绕”三国杀“这一核心IP展开的系列游戏和产品不过近年来也在探索和制造三国光环外的爆款游戏其中一款《自在西游》上线一个月就就突破了 2 亿流水。 在游戏行业最常见也最流行的数据库产品是 MySQL但它对于分布式和扩展性的缺失为游戏业务发展带来了限制。以游卡的数据库集群架构见图 1来说该业务架构有三个特点。 图1 游卡数据库集群架构 特点 1三地两中心符合三级等保要求。从图 1 可见这是一个非常典型的传统数据库主备架构。我们在杭州配备了主备机房在上海机房做容灾在江苏还有一个离线备份机房。 特点 2混合云部署数据在本地。我们将业务部署在云上但所有数据都存储在 IDC 中通过企业专线将 IDC 和阿里云打通。这是目前企业业务上云普遍采用的方式普遍认为数据比较隐私抓在自己手里才放心。 特点 3项目多且每个项目至少对应一个数据库集群。我们的游戏项目非常多不论项目大小都需要使用至少一套 MySQL 集群因此架构繁复。 在上述架构特性下衍生了四个使用痛点。 痛点 1高可用(MHA)配置复杂业务实现自动切换困难。举个例子在一次事故中我们的主库宕机了但主从之间因为存在 1~2 秒的延时从库无法切换到线上即使切换也会丢失数据。这是因为游戏角色的属性是实时写入数据库中的每秒钟的并发量都非常高所以这时无论我们切不切库都无关紧要已经对线上业务造成灾难了。 痛点 2扩容困难、维护成本高。图 2 是移动端《三国杀》从 2015 年日志系统上线至今平均每月日志空间的增长趋势已经显现出几何倍数的增长态势。我们使用 MySQL 只能依靠迁移或分库分表来实现扩容增加了大量的维护成本。尤其在业务侧投放商业推广时迎来数据高峰若占用大量人力维护分库分表直接影响我们的投放效益。 图2 移动端《三国杀》数据 痛点3资源利用率参差不齐。我们知道不可能每一款游戏都是爆款大部分游戏产品都是非常平淡地走完一生。因此平淡运行的游戏产品占用的机器 CPU 和内存非常富余而爆款游戏占用的机器 CPU 和内存严重不足。 痛点4迁移困难。由于游戏业务特性我们经常会有一些迁移工作但 MySQL 提供的 mysqldump 工具的性能和可视化较差无法显示迁移进度或速度因此我们不得不选择其他产品。 上述痛点已经困扰游卡多年如今已成为亟待解决的问题在多番考察后游卡选择上线新的数据库方案——原生分布式数据库 OceanBase。下文介绍使用 OceanBase 带来的架构转变和业务收益。 起初游卡在小范围业务中应用了OceanBase搭建了一套规格为 3 台 48C/256G/80TB 的生产集群。由于从测试到上线不到一个月对 OceanBase 操作经验欠缺因此在部署时遇到了两个小问题。 问题1数据库内存上限配置 OceanBase 需要根据一些配置项进行数据库内存上限的配置如 memory_limit_percentage 和 memory_limit。第一次部署 OceanBase 集群的用户往往不会去手动修改这些配置例如我们最初使用的 4.2.0 版本就默认只使用机器内存的 80% 当做 OBServer 可以使用的内存上限因为 memory_limit_percentage 默认值是 80%这样物理机器就会有 20% 的内存无法被利用。 除此以外还要给一个虚拟的 500 号租户预留一笔内存由 system_memory 这个配置项来控制如果不去手动配置默认会由系统自动根据当前系统的内存情况来调整 500 号租户的内存使用策略。500 租户是个特殊的虚拟租户共享性的、非实体租户消耗的内存都被 OceanBase 数据库划归 500 租户里。我们第一次部署环境时当 256GB 内存的机器上线后在 OCP 里看到的可以为普通用户租户分配的内存资源只剩 180GB约等于 256 * 80%memory_limit_percentage - 30system_memory。后来我们了解到 OceanBase 存在和内存分配相关的一批配置项通过调整 memory_limit_percentage 和 system_memory 解决了这个问题。 问题2磁盘空间配置 当事务日志Clog和数据共用同一个磁盘时OceanBase 默认保留 40% 的磁盘空间给 Clog数据文件只能占用其所在磁盘总空间的 60%。其实这个比例可以通过 datafile_disk_percentage 等相关的配置项来控制。后面我们通过把数据盘、事务日志盘分别挂载到两个不同的磁盘上解决了该问题。 上述两个问题在不够了解产品时很容易被忽略。对此我们的经验是目前主流的 OceanBase 数据库服务器内存为 384GB 或 512GB384GB 内存建议配置为使用机器内存的 80%512GB 内存建议配置为使用机器内存的 90%这也是 OceanBase 官网显示的最佳配置。并且建议企业用户把数据盘、事务日志盘分别挂载到两个不同的磁盘上当数据盘独占磁盘时数据文件默认占用其所在磁盘总空间的百分比为 90%磁盘空间规划的内容详见该文档。 上线 OceanBase 后游卡的业务架构和改造前的 MySQL 架构相似见图3。相当于将 MySQL 的主备容灾节点换成了 3 个 OBServer 节点在每个机房部署了 OBProxy。但受限于社区版我们没有使用 OBProxy 集群的方案而是采用了一个比较取巧的方法。我们使用阿里云的 NLB 服务来负载 2 个 OBProxy这样一来当我们机房的任何一个节点出现问题时还可以保证业务在生产环境的可用性。 图3 游卡上线 OceanBase 后的数据库集群架构 此外我们也使用了较多的 OceanBase 生态配套包括 OCPOceanBase 运维管理工具)、OMS OceanBase 数据迁移工具、OBAgentOceanBase 监控工具、ODCOceanBase 开发者工具、OBProxy OceanBase 专用反向代理。这些工具和组件为我们的运维人员提供了简单而高效的操作进一步减轻了工作人员的负担同时降低了运维成本。 OCP简化运维工作降低运维成本 首先任何一个新产品的上线都存在学习成本OceanBase 提供的 OCP 工具可以将黑屏转变为白屏降低运维学习成本使传统的集中式数据库 DBA 几乎无门槛转型到了分布式数据库进一步降低了 DBA 的门槛使 DBA 更容易上手数据库管理。其次由于我们的游戏产品众多每个游戏产品至少配备一个数据库集群因此一个 DBA 动辄十多个集群需要运维。使用 OCP 平台后DBA 的管理规模只剩一个后台管理规模大幅缩减。同时原本需要在操作系统、平台、客户端等地方进行的账号管理、慢日志分析、监控、备份管理、资源管理、容灾管理全都集中到一个后台进行管理工作集中、便捷。 OMS简单、高效、直观的数据迁移 游卡曾在测试阶段对比了 OMS 和 mysqldump 的迁移性能。mysqldump 的迁移过程涉及导出、压缩、传输、恢复等操作多且耗时长且无法可视化MySQL 生态也没有提供数据校验工具。相较而言OMS 的迁移过程非常简单分进程迁移数据后进行校验。从图 4 的迁移性能对比可见OMS 的迁移效率比 mysqldump 高出很多从 OMS 后台清晰可见迁移进度和速度。当前我们已经迁移超过 20TB 数据OMS 是现阶段最依赖的工具之一。 图4 OMS 和 mysqldump 迁移性能对比 其他工具OBProxy、OBAgent、ODC 除了 OCP 和 OMS 外OceanBase 生态的其他组件也相较于 MySQL 更有优势。 OBProxy 相对 MySQL Proxy 来讲它本身已经集成到了 OCP 的后台搭配云上的 LB 产品简单、高效地实现 HA 配置。 OBAgent 替代 MySQL Exporter搭配 Promethues 和 Grafana 能够平滑接入游卡监控中台将监控数据集中展示。 ODC 不仅是开发和运维工具更是协同工具工单和审核功能让我们非常惊喜替代了我们原本使用的 Navicat。 除收益外我们在使用生态工具时也发现了一些希望 OceanBase 优化的方向。首先是生态工具间的联通比如目前 OCP、OMS、ODC 的相关操作分布在各自的后台中我们希望工具间互相打通只用一个账密和一套后台即可解决运维管理的所有问题。其次我们希望 ODC 增加编辑表结构、编辑存储过程、数据归档等功能打破工单结果无法通知的壁垒。 相比新技术对运维管理的助力企业往往更关心新技术带来的降本和增效。OceanBase 很大程度上提升了游卡的资源利用率降低了存储成本和硬件成本。 1、存储资源利用率提升 OceanBase 最初打动游卡的是其数据高压缩能力经过测试游卡的数据可以压缩到原有数据到 19%~37% 不等见图 5且并不会造成性能下降和 CPU 开销的增加。 图5 MySQL迁移到OceanBase后空间对比 而对于硬件成本的节省经过计算当前企业采用的固态存储约 450 元/TBRAID10 后约 900 元/TB今年预计迁移 20TB 数据迁移后预计空间 7TB 以内可以节省成本 (20-7)T*900元/T*335100 元。上文提到的业务集群其数据可用空间大约为 50GB。按照 80% 的文件存储容量计算我们可以迁移 125TB 左右的数据。那么一个集群可以为我们节省 20 万元。 2、计算资源CPU、内存利用率提升 至于 CPU 和内存利用率的提升我们可以结合游戏行业的数据库性能指标特点来讲。 游戏行业的从库、容灾库资源利用率低即使是主库在大多数时间90%内其 CPU 利用率不到 10%。只有游戏每日任务开启时如凌晨 2 点、上午 10 点时利用率会达到高峰。不同游戏的高峰期不同比如 A 游戏集中在 0 点B 游戏集中在 10 点而运维人员做数据分析集中在凌晨 3-4 点。 基于游戏业务特点我们在 OceanBase 中对租户做了一些优化。通过不同租户的 Zone 优先级调整不同业务的组合适当超限配置提高资源利用率。也就是说我们 CPU 的配置已经超过了数据库拥有的 48 核。用这种方式来提高资源利用率。举个例子比如 A 项目和 B 项目的高峰都在 0 点将两个租户的 Zone 优先级分别设置为 Zone 1 和 Zone 2如果 A、C 项目的高峰分别在 0 和 4 点则将两个租户的 Zone 优先级全部设置为 Zone 1。 通过这样的方式我们的资源利用率都处于 10% 以上从图 6 可见比原来高出很多。 图6 资源利用率对比 通过图 7 的柱状对比也可以看到我们使用 OceanBase 后主机的一些 CPU 利用率得到了显著提升。 图7 MySQL 和 OceanBase 主机 CPU 利用率对比 3、服务器成本节约 我们下架了一套 MySQL 集群和一个阿里云的云数据库。图 8 显示了我们采购 MySQL 集群主机和阿里云服务器的配置及成本。也是目前使用 OceanBase 后节省的成本。 图8 使用 OceanBase 节省的成本 目前游卡从测试到应用 OceanBase 至今三个月余升级效果显著。未来游卡会在更多场景中探索 OceanBase 的价值。 场景一亿级大表性能优化 我们的一款手游项目一天的数据量是 4-5 亿条在使用 MySQL 时我们分了 14 张表共 164 种数据类型占用 60~100GB 的存储空间。在 OceanBase 中我们尝试将所有分表的数据重新合并并将原来的 14 张表按照数据类型转变为 14 个分区。我们进行了插入和读取测试随机插入 10 万条数据随机选取 1 万个账号对随机数据类型进行查询结果显示查询时间与 MySQL 单表查询耗时基本一致。随着数据量和数据类型的增长OceanBase 分区带来的管理便捷性愈发明显因为我们不必担心未来某个表的数据量过大后再次分表的开销。 场景二历史库存储降本 我们想使用费用低廉的存储大容量低转速机械硬盘搭建历史库满足历史低频日志数据查询需求。因为游戏行业有一个要求即厂商对玩家的消费行为等数据能够追溯一年。而事实上厂商对游戏玩家在 3 个月前的行为查询率较低如果这部分数据存储在主力集群中是对存储资源的浪费。因此我们需要将查询率低的历史数据同步到历史数据集群中以节省存储成本。而 OceanBase 的存储技术可以使历史库降本达到 50%~95%我们期待在历史库场景中验证 OceanBase 的价值。 游卡的迁移进度主要分三大部分第一部分是 3 个已上线的生产业务其中包含游卡核心项目——三国杀 Online第二部分是 4 个内部项目包含监控、审计、CMDB 等内部信息化数据库第三部分是游卡集团的 IM 项目。在此过程中我们感谢项目组对运维的信任和对新技术的包容也非常感谢 OceanBase 社区对我们的支持。 目前已经完成迁移上线的项目解决了使用 MySQL 时的高可用配置复杂和容灾、扩容等痛点显著提升了服务器资源的使用率并以此节省了计算资源的成本。后续我们会将更多业务上线 OceanBase希望 OceanBase 能够蒸蒸日上。
