为什么游戏行业喜欢用PolarDB

本文涉及的产品
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
云数据库 RDS SQL Server,基础系列 2核4GB
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
简介: PolarDB 在游戏行业的最佳实践

为什么游戏行业喜欢用PolarDB

游戏行业痛点

在我看来, 不同行业对数据库使用有巨大的差别. 比如游戏行业没有复杂的事务交易场景, 他有一个非常大的blob 字段用于存储角色的装备信息, 那么大Blob 字段的更新就会成为数据库的瓶颈, 比如在线教育行业需要有抢课的需求, 因此会有热点行更新的场景, 对热点行如何处理会成为数据库的瓶颈, 比如SaaS 行业, 每一个客户有一个Database, 因此会有非常多的Table, 那么数据库就需要对多表有很好的支持能力.

游戏行业和其他行业对数据库的使用要求是不一样的.

所以在支撑了大量游戏业务之后, 我理解游戏行业在使用自建MySQL 的时候有3个比较大的痛点

  1. 对备份恢复的需求
  2. 对写入性能的要求
  3. 对跨region 容灾的需求

接下来会分别讲述这三个痛点PolarDB 是如何解决的.


备份恢复

笔者和大量游戏开发者沟通中, 游戏行业对备份恢复的需求是极其强烈的. 比如在电商行业, 是不可能存在将整个数据库实例进行回滚到一天之前的数据, 这样所有的用户的购买交易信息都丢失了.

但是, 在游戏行业中, 这种场景确实存在的, 比如在发版的时候, 游戏行业是有可能发版失败, 这个在其他行业出现概率非常低, 如果发版失败, 那么整个实例就需要回滚到版本之前. 因此每次发版的时候都需要对数据库实例进行备份. 因此当我们玩游戏的时候, 看到大版本需要停服更新, 那么就有可能是因为后台需要备份数据等等一系列操作了.

还有一种场景, 当发生因为外挂, 漏洞, 参数配置错误等等场景下, 这种紧急情况游戏就需要回滚到出问题前的版本, 这样就需要对整个实例进行回滚.


image.png

官方MySQL 由于是单机架构, 那么常见的备份方法是通过Xtrabackup 工具, 将数据备份到本地以后, 如果本地空间不够, 就需要上传到OSS 等远端存储中. 通常通过Xtrabackup 备份工具都需要1h 左右, 如果需要将数据上传到远端那么时间就更长了.

PolarDB 是天然的计存分离的架构, 那么备份的时候通过底下分布式存储的快照能力, 备份可以不超过30s, 将备份时间大大缩短了.

核心思路是采用Redirect-on-Write 机制, 每次创建快照并没有真正Copy数据, 只有建立快照索引, 当数据块后期有修改(Write)时才把历史版本保留给Snapshot, 然后生成新的数据块, 被原数据引用(Redirect).

另外一种场景是, 在游戏行业中, 有可能某一个玩家的装备被盗号了, 那么玩家就会找游戏的运营人员投诉, 运营人员会找到游戏运维人员, 帮忙查询玩家的历史数据.

笔者之前就遇到某著名游戏多个玩家被盗号, 然后运维人员经常需要通过PolarDB 按时间的还原的能力恢复出某多个不同时间点的实例, 用来查询这个玩家的具体装备信息, 同时由于玩家对盗号的时间也不准确, 经常有时候需要还原出多个实例才可以.

针对这样的场景, PolarDB 推出了Flashback Query, 就可以在当前实例查询出任意时间点的历史数据. 具体原理见文章 Flashback Query


image.png

整体而言, PolarDB 建立了一套非常完善的备份恢复能力, 从库=>表=>行三个维度满足的游戏行业对备份恢复的需求.

image.png


写入性能

游戏行业使用数据库的方式也与其他行业有较大区别, 是一种非常弱Schema 的使用方式, 其他行业通常对业务经常抽象, 建立表结构, 每个字段尽可能小, 不建议有大字段, 有大字段尽可能进行拆封等等.


但是在游戏行业中, 由于需要满足游戏快速迭代发展的需求, 玩家的装备信息结构非常复杂, 因此常见的做法是将玩家装备等级信息保存在一个大的blob字段中, 这个blob字段通过proto_buf 或者 json 进行编解码, 每次在获得装备或者升级以后, 就进行整个字段更新,  在游戏开服初期玩家数据长度较短, 而随着游戏版本更新版本, 游戏剧情, 运营活动的增多, 相对于游戏开服初期的数KB, blob字段的长度可能会膨胀到数百KB, 甚至达到MB级别, 因此可能只是获得一个装备, 就需要向数据库写入数百KB 大小的数据, 这样的写放大其实非常不合理.


目前也有像MongoDB 这样的文档数据库, 让用户写入的时候仅仅更新某个字段, 从而减少写放大. 但是这样影响了用户的使用习惯, 需要用户在业务逻辑上进行修改, 这是快速发展的游戏行业所不能接受的, 所以笔者看到尽管有客户因为写入问题转向了MongoDB, 但是其实不多.


PolarDB 针对这样的情况尽可能满足用户的使用习惯, 在数据库内核层面优化数据库的写入能力. 通过 partition redo log, redo log cache, undo log readahead,  early lock release, no blob latch 等等能力将写入能力充分优化. 具体原理可以参考我们内核月报 和之前的文章PolarDB-cloudjump


针对游戏场景, 我们修改了 sysbench 工具, 模拟游戏行业中大Blob 更新的workload, 放在 game-sysbench 工具中, 后续我们还会将更多行业比如Saas, 电商等等行业的workload 放在这个工具中.

在game_blob_update workload 中, 如果玩家的平均装备信息是 300kb, 我们对比了PolarDB VS aurora VS 自建MySQL 的数据

PolarDB 8.0 相对有最高的QPS 1877.44, 峰值QPS最高可以到2000, CPU bound场景PolarDB的性能大概是Aurora的5.7倍, 是自建 MySQL 本地盘的3倍. IO bound场景PolarDB的性能是Aurora的15倍.

CPU bound场景:

DB 并发数据 QPS
PolarDB 8.0 5 1877.44
MySQL 8.0 本地盘 4 600.22
Aurora 8.0 200 328.47

IO bound场景:

DB 并发数据 QPS
PolarDB 8.0 200 1035.30
MySQL 8.0 本地盘 200 610
Aurora 8.0 200 69.15


跨region 容灾


目前游戏行业纷纷出海, 包含了游戏服和平台服. 用户在自建MySQL/RDS 的场景中,  用户可能需要在另外一个region 建立一个新的实例, 然后通过同步工具或者DTS 进行跨region 备份. 用户需要处理region 错误场景如何进行切换等等.

笔者认为对数据库而言, 稳定性 > 易用性 > 性能.


在这个场景中, 用户如果使用云厂商的话, 使用的是云厂商提供的原子能力, 自己通过组装这些原子能力实现容灾的需求, 而PolarDB 针对这样场景提出来PolarDB GlobalDataba 的解决方案, 将跨region 的容灾放在解决方案中, 提供了一个更加易容的解决方案, 从而用户可以关注自身的业务逻辑, 而不需要处理这些容灾的场景.


在具体跨region 的同步场景方案中, PolarDB 是通过多通道物理复制能力, 从而保证跨region 的容灾在1s 以内.

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
关系型数据库 分布式数据库 PolarDB
沉浸式学习PostgreSQL|PolarDB 7: 移动社交、多媒体、内容分发、游戏业务场景, 跨地域多机房的智能加速
在移动社交、多媒体、内容分发业务场景中, 如果用户要交互的内容都在中心网络(假设深圳), 现在用户流动非常频繁, 当用户从深圳出差到北京, 因为网络延迟急剧增加, 他的访问体验就会变得非常差. 网络延迟对游戏业务的影响则更加严重. 为了解决这个问题, 企业会将业务部署在全国各地, 不管用户在哪里出差, 他都可以就近访问最近的中心. 由于标记用户的只有IP地址, 怎么根据用户的接入IP来判断他应该访问哪个中心呢? 通过这个实验, 大家可以了解到在数据库中如何存储IP地址范围和各中心IDC的映射关系, 以及如何根据用户的来源IP(接入IP)来判断他应该去哪个中心IDC访问.
163 0
|
7月前
|
Cloud Native 关系型数据库 分布式数据库
《永恒岛》引入云原生数据库PolarDB实现游戏全球部署和更流畅的游戏体验
三九互娱通过采用阿里云PolarDB作为核心数据库,备份和恢复效率提高10倍以上
122 1
|
存储 运维 容灾
为什么游戏行业喜欢用PolarDB
PolarDB 在游戏行业最佳实践
1506 0
为什么游戏行业喜欢用PolarDB
|
存储 运维 Cloud Native
|
存储 弹性计算 Cloud Native
【云栖号案例 | 游戏&娱乐】PolarDB助力心动网络为千万级用户在线手游保驾护航
为支持游戏业务快速出海,需要支撑全球化业务的统一部署及100万级玩家同时在线的高并发压力。PolarDB为千万级用户提供优良的游戏体验、7*24 高可用服务。
【云栖号案例 | 游戏&娱乐】PolarDB助力心动网络为千万级用户在线手游保驾护航
|
2月前
|
关系型数据库 MySQL 分布式数据库
零基础教你用云数据库PolarDB搭建企业网站,完成就送桌面收纳桶!
零基础教你用云数据库PolarDB搭建企业网站,完成就送桌面收纳桶,邀请好友完成更有机会获得​小米Watch S3、小米体重称​等诸多好礼!
零基础教你用云数据库PolarDB搭建企业网站,完成就送桌面收纳桶!
|
3月前
|
关系型数据库 MySQL Serverless
探索PolarDB MySQL版:Serverless数据库的灵活性与性能
本文介绍了个人开发者对阿里云PolarDB MySQL版,特别是其Serverless特性的详细评测体验。评测涵盖了产品初体验、性能观测、Serverless特性深度评测及成本效益分析等方面。尽管试用过程中遇到一些小问题,但总体而言,PolarDB MySQL版表现出色,提供了高性能、高可用性和灵活的资源管理,是个人开发者和企业用户的优秀选择。
|
4月前
|
关系型数据库 MySQL 分布式数据库
PolarDB 与传统数据库的性能对比分析
【8月更文第27天】随着云计算技术的发展,越来越多的企业开始将数据管理和存储迁移到云端。阿里云的 PolarDB 作为一款兼容 MySQL 和 PostgreSQL 的关系型数据库服务,提供了高性能、高可用和弹性伸缩的能力。本文将从不同角度对比 PolarDB 与本地部署的传统数据库(如 MySQL、PostgreSQL)在性能上的差异。
254 1
|
1月前
|
关系型数据库 分布式数据库 数据库
锦鲤附体 | PolarDB数据库创新设计赛,好礼不停!
锦鲤附体 | PolarDB数据库创新设计赛,好礼不停!
|
2月前
|
关系型数据库 分布式数据库 数据库
PolarDB 开源:推动数据库技术新变革
在数字化时代,数据成为核心资产,数据库的性能和可靠性至关重要。阿里云的PolarDB作为新一代云原生数据库,凭借卓越性能和创新技术脱颖而出。其开源不仅让开发者深入了解内部架构,还促进了数据库生态共建,提升了稳定性与可靠性。PolarDB采用云原生架构,支持快速弹性扩展和高并发访问,具备强大的事务处理能力及数据一致性保证,并且与多种应用无缝兼容。开源PolarDB为国内数据库产业注入新活力,打破国外垄断,推动国产数据库崛起,降低企业成本与风险。未来,PolarDB将在生态建设中持续壮大,助力企业数字化转型。
99 2

相关产品

  • 云原生数据库 PolarDB