建站
咨詢
售后
建站咨詢
新聞中心
為什么游戲行業(yè)喜歡用PolarDB
游戲行業(yè)痛點
巨野ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為成都創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：13518219792（備注：SSL證書合作）期待與您的合作！
在我看來, 不同行業(yè)對數(shù)據(jù)庫使用有巨大的差別. 比如游戲行業(yè)沒有復(fù)雜的事務(wù)交易場景, 他有一個非常大的blob 字段用于存儲角色的裝備信息, 那么大Blob 字段的更新就會成為數(shù)據(jù)庫的瓶頸, 比如在線教育行業(yè)需要有搶課的需求, 因此會有熱點行更新的場景, 對熱點行如何處理會成為數(shù)據(jù)庫的瓶頸, 比如SaaS 行業(yè), 每一個客戶有一個Database, 因此會有非常多的Table, 那么數(shù)據(jù)庫就需要對多表有很好的支持能力。
游戲行業(yè)和其他行業(yè)對數(shù)據(jù)庫的使用要求是不一樣的。
所以在支撐了大量游戲業(yè)務(wù)之后, 我理解游戲行業(yè)在使用自建MySQL 的時候有3個比較大的痛點
- 對備份恢復(fù)的需求
- 對寫入性能的要求
- 對跨region 容災(zāi)的需求
接下來會分別講述這三個痛點PolarDB 是如何解決的。
備份恢復(fù)
筆者和大量游戲開發(fā)者溝通中, 游戲行業(yè)對備份恢復(fù)的需求是極其強烈的. 比如在電商行業(yè), 是不可能存在將整個數(shù)據(jù)庫實例進行回滾到一天之前的數(shù)據(jù), 這樣所有的用戶的購買交易信息都丟失了。
但是, 在游戲行業(yè)中, 這種場景確實存在的, 比如在發(fā)版的時候, 游戲行業(yè)是有可能發(fā)版失敗, 這個在其他行業(yè)出現(xiàn)概率非常低, 如果發(fā)版失敗, 那么整個實例就需要回滾到版本之前. 因此每次發(fā)版的時候都需要對數(shù)據(jù)庫實例進行備份. 因此當我們玩游戲的時候, 看到大版本需要停服更新, 那么就有可能是因為后臺需要備份數(shù)據(jù)等等一系列操作了。
還有一種場景, 當發(fā)生因為 漏洞, 參數(shù)配置錯誤等等場景下, 這種緊急情況游戲就需要回滾到出問題前的版本, 這樣就需要對整個實例進行回滾。
官方MySQL 由于是單機架構(gòu), 那么常見的備份方法是通過Xtrabackup 工具, 將數(shù)據(jù)備份到本地以后, 如果本地空間不夠, 就需要上傳到OSS 等遠端存儲中. 通常通過Xtrabackup 備份工具都需要1h 左右, 如果需要將數(shù)據(jù)上傳到遠端那么時間就更長了。
PolarDB 是天然的計存分離的架構(gòu), 那么備份的時候通過底下分布式存儲的快照能力, 備份可以不超過30s, 將備份時間大大縮短了。
核心思路是采用Redirect-on-Write 機制, 每次創(chuàng)建快照并沒有真正Copy數(shù)據(jù), 只有建立快照索引, 當數(shù)據(jù)塊后期有修改(Write)時才把歷史版本保留給Snapshot, 然后生成新的數(shù)據(jù)塊, 被原數(shù)據(jù)引用(Redirect)。
另外一種場景是, 在游戲行業(yè)中, 有可能某一個玩家的裝備被盜號了, 那么玩家就會找游戲的運營人員投訴, 運營人員會找到游戲運維人員, 幫忙查詢玩家的歷史數(shù)據(jù)。
筆者之前就遇到某著名游戲多個玩家被盜號, 然后運維人員經(jīng)常需要通過PolarDB 按時間的還原的能力恢復(fù)出某多個不同時間點的實例, 用來查詢這個玩家的具體裝備信息, 同時由于玩家對盜號的時間也不準確, 經(jīng)常有時候需要還原出多個實例才可以。
針對這樣的場景, PolarDB 推出了Flashback Query, 就可以在當前實例查詢出任意時間點的歷史數(shù)據(jù). 具體原理見文章 Flashback Query
整體而言, PolarDB 建立了一套非常完善的備份恢復(fù)能力, 從庫=>表=>行三個維度滿足的游戲行業(yè)對備份恢復(fù)的需求。
寫入性能
游戲行業(yè)使用數(shù)據(jù)庫的方式也與其他行業(yè)有較大區(qū)別, 是一種非常弱Schema 的使用方式, 其他行業(yè)通常對業(yè)務(wù)經(jīng)常抽象, 建立表結(jié)構(gòu), 每個字段盡可能小, 不建議有大字段, 有大字段盡可能進行拆封等等.但是在游戲行業(yè)中, 由于需要滿足游戲快速迭代發(fā)展的需求, 玩家的裝備信息結(jié)構(gòu)非常復(fù)雜, 因此常見的做法是將玩家裝備等級信息保存在一個大的blob字段中, 這個blob字段通過proto_buf 或者 json 進行編解碼, 每次在獲得裝備或者升級以后, 就進行整個字段更新, 在游戲開服初期玩家數(shù)據(jù)長度較短, 而隨著游戲版本更新版本, 游戲劇情, 運營活動的增多, 相對于游戲開服初期的數(shù)KB, blob字段的長度可能會膨脹到數(shù)百KB, 甚至達到MB級別, 因此可能只是獲得一個裝備, 就需要向數(shù)據(jù)庫寫入數(shù)百KB 大小的數(shù)據(jù), 這樣的寫放大其實非常不合理。
目前也有像MongoDB 這樣的文檔數(shù)據(jù)庫, 讓用戶寫入的時候僅僅更新某個字段, 從而減少寫放大. 但是這樣影響了用戶的使用習慣, 需要用戶在業(yè)務(wù)邏輯上進行修改, 這是快速發(fā)展的游戲行業(yè)所不能接受的, 所以筆者看到盡管有客戶因為寫入問題轉(zhuǎn)向了MongoDB, 但是其實不多。
PolarDB 針對這樣的情況盡可能滿足用戶的使用習慣, 在數(shù)據(jù)庫內(nèi)核層面優(yōu)化數(shù)據(jù)庫的寫入能力. 通過 partition redo log, redo log cache, undo log readahead, early lock release, no blob latch 等等能力將寫入能力充分優(yōu)化。
具體原理可以參考我們內(nèi)核月報 和之前的文章PolarDB-cloudjump針對游戲場景, 我們修改了 sysbench 工具, 模擬游戲行業(yè)中大Blob 更新的workload, 放在 game-sysbench 工具中, 后續(xù)我們還會將更多行業(yè)比如Saas, 電商等等行業(yè)的workload 放在這個工具中。
在game_blob_update workload 中, 如果玩家的平均裝備信息是 300kb, 我們對比了PolarDB VS aurora VS 自建MySQL 的數(shù)據(jù)PolarDB 8.0 相對有最高的QPS 1877.44, 峰值QPS最高可以到2000, CPU bound場景PolarDB的性能大概是Aurora的5.7倍, 是自建 MySQL 本地盤的3倍. IO bound場景PolarDB的性能是Aurora的15倍。
CPU bound場景：
|
DB |
并發(fā)數(shù)據(jù) |
QPS |
|
PolarDB 8.0 |
5 |
1877.44 |
|
MySQL 8.0 本地盤 |
4 |
600.22 |
|
Aurora 8.0 |
200 |
328.47 |
IO bound場景：
|
DB |
并發(fā)數(shù)據(jù) |
QPS |
|
PolarDB 8.0 |
200 |
1035.30 |
|
MySQL 8.0 本地盤 |
200 |
610 |
|
Aurora 8.0 |
200 |
69.15 |
跨region 容災(zāi)
目前游戲行業(yè)紛紛出海, 包含了游戲服和平臺服. 用戶在自建MySQL/RDS 的場景中, 用戶可能需要在另外一個region 建立一個新的實例, 然后通過同步工具或者DTS 進行跨region 備份. 用戶需要處理region 錯誤場景如何進行切換等等。
筆者認為對數(shù)據(jù)庫而言, 穩(wěn)定性 > 易用性 > 性能.在這個場景中, 用戶如果使用云廠商的話, 使用的是云廠商提供的原子能力, 自己通過組裝這些原子能力實現(xiàn)容災(zāi)的需求, 而PolarDB 針對這樣場景提出來PolarDB GlobalDataba 的解決方案, 將跨region 的容災(zāi)放在解決方案中, 提供了一個更加易容的解決方案, 從而用戶可以關(guān)注自身的業(yè)務(wù)邏輯, 而不需要處理這些容災(zāi)的場景。
在具體跨region 的同步場景方案中, PolarDB 是通過多通道物理復(fù)制能力, 從而保證跨region 的容災(zāi)在1s 以內(nèi)。
分享文章：為什么游戲行業(yè)喜歡用PolarDB
文章分享：http://m.fisionsoft.com.cn/article/dhogoie.html
