为什么游戏行业喜欢用PolarDB游戏行业的痛点在我看来，不同行业对数据库的使用存在巨大差异。比如游戏行业没有复杂的交易场景，有一个非常大的blob字段用来存储角色的装备信息，那么大的blob字段的更新就会成为数据库的瓶颈。比如在线教育行业需要赶课，那么就会出现热排更新的场景，如何处理热排就成了数据库的问题。比如在SaaS行业，每个客户都有一个Database，那么就会有很多Table，所以数据库需要对多表有很好的支持。游戏行业和其他行业对数据库的使用有着不同的要求。所以在扶持了大量的游戏业务后，了解到游戏行业在使用自建MySQL时存在三大痛点。备份和恢复的要求，写入性能的要求，以及跨地域容灾的要求，下面分别介绍。PolarDB是如何解决这三个痛点的。备份与恢复在笔者与大量游戏开发者的交流中，游戏行业对备份与恢复有着极其强烈的需求。比如在电商行业，不可能将整个数据库实例回滚到当天之前的数据，以至于所有用户的购买交易信息都丢失了。然而，在游戏行业，这样的场景确实存在。例如，当一个版本发布时，游戏行业可能无法发布该版本。这种情况发生在其他行业的概率很低。如果发布失败，需要回滚整个实例。滚动到以前的版本。所以每次发布版本都需要备份数据库实例。所以，当我们玩游戏看到大版本需要停止更新时，可能是因为后台需要备份数据等等。该系列运作。还有一种场景是游戏因为bug、参数配置错误等原因需要回滚到问题发生前的版本，需要回滚整个实例。由于官方MySQL是单机架构，所以常用的备份方式是使用Xtrabackup工具在本地备份数据。如果本地空间不够，需要上传到OSS等远程存储。通常，使用Xtrabackup备份工具大约需要1小时。如果需要将数据上传到远端，时间会更长。PolarDB是一种天然的计算存储分离架构，所以在备份时，通过底层分布式存储的快照能力，备份时间不超过30s，大大缩短了备份时间。核心思想是采用Redirect-on-Write机制。每次创建快照时，都没有真正的Copy数据。仅建立快照索引。之后数据块被修改（Write）时，历史版本被保留给Snapshot，然后生成新的数据块。,被原始数据引用（重定向）。另一种场景是，在游戏行业，如果某个玩家的装备被盗，玩家会向游戏的运营人员投诉，运营人员会找到游戏运维人员，帮助查询玩家的历史数据。笔者之前在某知名游戏中遇到过多个被黑的玩家，然后运维人员经常需要使用PolarDB的按时间恢复的能力来恢复多个不同时间点的实例来查询该游戏的具体设备信息玩家，同时由于玩家账号被盗时间的不准确，往往需要恢复多个实例。针对这样的场景，PolarDB推出了FlashbackQuery，可以查询当前实例任意时间点的历史数据。详见闪回查询一文。总体来说，PolarDB已经建立了一套非常完善的备份和恢复能力。从数据库=>表=>行三个维度满足游戏行业对备份恢复的需求。写入性能游戏行业使用数据库的方式也与其他行业有很大的不同。这是一个非常弱的Schema用法。其他行业通常会把业务抽象出来，建立一个表结构，每个字段越小越好。不建议有Largefields，largefields尽量拆包等。但是在游戏行业，由于需要满足游戏快速迭代开发的需要，玩家的装备信息结构是非常复杂，所以一种常见的做法是将玩家的装备等级信息保存在一个大的blob字段中，blob字段通过proto_buf或json进行编码和解码，每次获得装备或升级后更新整个字段。玩家数据的长度在游戏开服初期比较短，随着游戏版本更新，游戏剧情、运营活动增多。与游戏服务器上线之初的几KB相比，blob字段的长度可能会扩大到数百KB，甚至达到MB级别。因此，可能需要写入数据库才能获得一个设备。对于几百KB的数据，这样的写放大其实是很不合理的。目前也有像MongoDB这样的文档型数据库，允许用户在写入时只更新某个字段，从而减少写入放大。但是，这会影响用户的使用习惯，需要用户修改业务逻辑。这是一个快速发展的游戏行业是无法接受的，所以我看到虽然有一些客户因为写的问题转向了MongoDB，但其实并不多。PolarDB尽量满足用户在这种情况下的使用习惯，在数据库内核层面对数据库写入能力进行了优化。通过partitionredolog、redologcache、undologreadahead、earlylockrelease、nobloblatch等能力，写能力得到全面优化。具体原理可以参考我们的内核月报和之前的文章PolarDB-cloudjump。针对游戏场景，我们修改了sysbench工具，模拟游戏行业大blob的更新工作负载，放到game-sysbench工具中。我们会把更多的SaaS、电商等行业的工作负载放在这个工具里面。在game_blob_update工作负载中，如果玩家的装备信息平均为300kb，我们对比了PolarDBVSauroraVS自建MySQL的数据。PolarDB8.0相对最高QPS为1877.44，峰值QPS可达200??0。PolarDB在CPUbound场景下的性能约为Aurora的5.7倍，是自建MySQL本地盘的3倍。PolarDB在IObound场景下的性能是Aurora的15倍。CPU绑定场景：DB并发数据QPSPolarDB8.051877.44MySQL8.0本地盘4600.22Aurora8.0200328.47IO绑定场景：DB并发数据QPSPolarDB8.02001035.30MySQL8.0本地盘200610Aurora8.020069.15跨地域容灾，游戏行业目前包括跨地域容灾-区域容灾和平台服务。在自建MySQL/RDS的场景下，用户可能需要在异地新建一个实例，然后使用同步工具或者DTS进行跨地域备份。用户需要处理在区域错误场景下如何切换等等。笔者认为对于数据库来说，稳定性>易用性>性能。在这种场景下，如果用户使用云厂商，就是使用云厂商提供的原子能力，通过组装这些原子能力来实现容灾需求。PolarDB针对这样的场景提出了PolarDBGlobalDataba解决方案，将跨地域容灾纳入解决方案中，提供更易访问的解决方案，让用户可以专注于自己的业务逻辑，而不必去处理这些复杂的问题。灾难现场。在具体的跨地域同步场景下，PolarDB利用多通道物理复制能力，保证1s内的跨地域容灾。
