Introdução: Práticas recomendadas do PolarDB na indústria de jogos
Por que a indústria de jogos adora o PolarDB
Pontos problemáticos da indústria de jogos
Na minha opinião, existem grandes diferenças no uso de bancos de dados em diferentes indústrias. Por exemplo, a indústria de jogos não possui cenários complexos de transação de transações, e ele possui um campo de blob muito grande para armazenar informações de equipamentos de personagens, então a atualização do O campo de blob grande se tornará o gargalo do banco de dados. Por exemplo, o setor de educação on-line precisa pegar aulas, então haverá cenários em que as linhas quentes serão atualizadas. Como lidar com as linhas quentes se tornará o gargalo do banco de dados. Por exemplo, na indústria de SaaS, cada cliente tem um banco de dados, então haverá muito Se houver muitas tabelas, o banco de dados precisa ter um bom suporte para várias tabelas.
A indústria de jogos e outras indústrias têm requisitos diferentes para o uso de bancos de dados.
Então, depois de dar suporte a um grande número de empresas de jogos, eu entendo que a indústria de jogos tem três grandes pontos problemáticos ao usar o MySQL auto-construído
- A necessidade de backup e recuperação
- Requisitos para desempenho de gravação
- A necessidade de recuperação de desastres entre regiões
A seguir, descreveremos como o PolarDB resolve esses três pontos problemáticos.
Recuperação de backup
Na comunicação entre o autor e um grande número de desenvolvedores de jogos, a demanda por backup e recuperação na indústria de jogos é extremamente forte. Por exemplo, na indústria de comércio eletrônico, é impossível reverter toda a instância do banco de dados para o dados de um dia atrás, para que as informações de transação de compras de todos os usuários sejam perdidas.
No entanto, na indústria de jogos, esse cenário existe. Por exemplo, quando a indústria de jogos é lançada, a indústria de jogos pode não liberar o lançamento. A probabilidade dessa ocorrência em outras indústrias é muito baixa. Se o lançamento falhar, a instância inteira precisa ser retornada. Antes de passar para a versão. Portanto, é necessário fazer backup da instância do banco de dados toda vez que a versão for lançada. Portanto, quando jogamos o jogo e vemos que a versão grande precisa ser interrompida e atualizada , pode ser porque o plano de fundo precisa fazer backup dos dados e assim por diante. A série opera.
Há também um cenário em que o jogo precisa ser revertido para a versão anterior ao problema nesta situação de emergência, para que toda a instância precise ser revertida.
Como o MySQL oficial é uma arquitetura independente, o método de backup comum é usar a ferramenta Xtrabackup para fazer backup dos dados localmente. Se o espaço local não for suficiente, ele precisa ser carregado em um armazenamento remoto, como OSS. Geralmente , a ferramenta de backup Xtrabackup leva cerca de 1h. Se os dados precisarem ser carregados no controle remoto, o tempo será maior.
PolarDB 是天然的计存分离的架构, 那么备份的时候通过底下分布式存储的快照能力, 备份可以不超过30s, 将备份时间大大缩短了.
核心思路是采用Redirect-on-Write 机制, 每次创建快照并没有真正Copy数据, 只有建立快照索引, 当数据块后期有修改(Write)时才把历史版本保留给Snapshot, 然后生成新的数据块, 被原数据引用(Redirect).
另外一种场景是, 在游戏行业中, 有可能某一个玩家的装备被盗号了, 那么玩家就会找游戏的运营人员投诉, 运营人员会找到游戏运维人员, 帮忙查询玩家的历史数据.
笔者之前就遇到某著名游戏多个玩家被盗号, 然后运维人员经常需要通过PolarDB 按时间的还原的能力恢复出某多个不同时间点的实例, 用来查询这个玩家的具体装备信息, 同时由于玩家对盗号的时间也不准确, 经常有时候需要还原出多个实例才可以.
针对这样的场景, PolarDB 推出了Flashback Query, 就可以在当前实例查询出任意时间点的历史数据. 具体原理见文章 Flashback Query
整体而言, PolarDB 建立了一套非常完善的备份恢复能力, 从库=>表=>行三个维度满足的游戏行业对备份恢复的需求.
写入性能
游戏行业使用数据库的方式也与其他行业有较大区别, 是一种非常弱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 以内.
原文链接：click.aliyun.com/m/100034986…
本文为阿里云原创内容，未经允许不得转载。