導讀：中國TOP1沙盒遊戲，如何解決資料儲存難題？

提到推薦系統，很多人都在電商購物、資訊或娛樂平臺中體驗過。比如，你剛在某電商APP買了一部手機，過兩天再登入時，首頁推薦中必定有耳機、手機殼等手機配件。

本質上，推薦系統是網際網路世界的資源排程系統，決定了使用者體驗和企業核心競爭力。比如，根據亞馬遜2019年度報告，其40%的營收來自內部穩定的推薦系統。如今，推薦系統已不再是電商、網際網路行業的專用技術，越來越多行業將其作為核心業務之一。

一個聰明的推薦系統，背後有很多關鍵技術，KV資料庫便是其中之一。以《迷你世界》遊戲場景推薦系統為例，《迷你世界》是國內頭部沙盒創意平臺，目前月活使用者超過1億。透過使用華為雲企業級KV資料庫GaussDB（for Redis），《迷你世界》的推薦業務不僅成本降低了60%，而且提升了畫像資料承載量，讓玩家更容易、更快速找到自己喜歡的遊戲場景。

中國TOP1沙盒遊戲的資料儲存攻堅戰

瞭解遊戲的讀者一定知道，沙盒類遊戲最吸引人的就是層出不窮的新場景。如何將新個性化場景推薦給最感興趣的玩家，成為持續提升使用者體驗的關鍵。

在《迷你世界》中，推薦系統對兩類玩家的體驗都至關重要。對於第一次登入的新玩家，茫然不知道該玩哪個遊戲場景時，需要及時指引。對於老玩家，則有海量新鮮有趣的遊戲場景等待探索。要知道《迷你世界》的UGC生態非常活躍，平臺上有超過7000萬創作者，累計創造的場景超過2億個。因此，《迷你世界》推薦系統亟需一個強大的KV資料庫來承載持續增長的海量場景特徵，提升推薦系統的服務效率。

提到KV資料庫，一般會讓人立刻想到Redis。但在推薦系統這類AI場景下，開源Redis卻顯得捉襟見肘，並非最佳選型。經過長期實踐和調研，《迷你世界》最終選擇了華為雲GaussDB（for Redis）作為推薦業務的核心儲存選型。

完勝開源版本，GaussDB（for Redis）助力《迷你世界》加速創新

在《迷你世界》的遊戲場景推薦系統中，GaussDB（for Redis）主要承載了特徵平臺的核心特徵資料儲存功能，起著“承上啟下”的作用。因為，在一個推薦系統中，確保特徵資料的可靠儲存、彈性擴容，是極為關鍵的一環，這也是GaussDB（for Redis）在《迷你世界》推薦系統中的重要價值。

早期，《迷你世界》使用開源Redis做特徵資料儲存，開源Redis在成本、擴容、可靠性等方面存在諸多短板，越來越無法滿足業務高速增長的需求。在華為雲GaussDB（for Redis）幫助下，《迷你世界》整體成本降低60%，特徵資料總承載量提升3倍，並大幅提升了玩家的遊戲體驗。概括來說，GaussDB（for Redis）的優勢可以總結為：

低成本、高穩定、高可靠、強一致、強擴充套件、強抗寫。

相比開源Redis在大資料場景下存在顯而易見的痛點， GaussDB（for Redis）更適合儲存特徵資料：

開源Redis丟資料 VS 高斯Redis提供DB級別可靠儲存

開源Redis中的資料是可丟失的，生產中只適合用在純快取場景。開源Redis的AOF持久化也僅僅是磁碟中保留一個簡單的文字檔案而已，並不可靠。假如寫入速度是2000條/秒，那麼即使開了AOF持久化，故障場景下開源Redis也會丟失至少2000條資料。《迷你世界》遊戲場景推薦系統的特徵資料關係到使用者體驗，長久可靠儲存是基本要求。

GaussDB（for Redis）是真正意義上的KV資料庫，對儲存引擎、LSM-tree儲存結構、WAL日誌、menifest元資料儲存、SSTable檔案格式等方面均做了深度最佳化，搭配華為獨有的高效能分散式儲存池DFV，做到資料三副本強一致儲存，相當可靠。即使在節點故障場景，GaussDB（for Redis）也能夠秒級恢復，業務僅會感知一個小小的“抖動”。

開源Redis燒錢 VS 高斯Redis省錢40%以上

從成本上看，記憶體儲存的一大特點就是貴，相同容量的記憶體與極速SSD相比，一般價格要貴10倍以上。尤其是《迷你世界》這類客戶，資料量激增很快，當資料量達到幾十GB、幾百GB，開源Redis只會越來越“燒錢”。而且，開源Redis自身fork問題導致容量利用率低，硬體資源有很大的浪費。

華為雲GaussDB（for Redis）則是幫企業省錢的小能手。一方面，GaussDB（for Redis）的所有資料全部落在高效能分散式儲存池，其成本比開源Redis降低了75%~90%。另一方面，華為雲GaussDB（for Redis）自帶的資料壓縮功能，可以對序列化後的資訊進行高壓縮比的壓縮，

實際佔用空間僅為開源Redis的50%左右，

進一步降低了儲存成本。此外，GaussDB（for Redis）會進行自動冷熱資料交換，最大程度保證了熱資料的低時延訪問。

開源Redis擴容慢，影響業務 VS 高斯Redis無感熱擴容

如果一個開源Redis快寫滿了，需要從64G擴容到128G，耗時至少半小時。這是因為過程中要將老分片中的資料遠端copy到新分片，導致耗時久、業務受影響時間長。《迷你世界》此前不得不凌晨熬夜擴容，而且還要承受業務受小時級影響的損失。

華為雲GaussDB（for Redis）採用存算分離架構，天然可以做到按需擴容，即“計算不夠擴計算，儲存不夠擴儲存”。在存算分離的架構下，底層資料可以被任意上層計算節點訪問，儲存擴容過程不發生資料複製搬遷，只需修改一個配額即可瞬間完成擴容。因此，GaussDB（for Redis）可以做到秒級擴容，無論是擴節點還是擴儲存容量，對業務的影響幾乎為0，真正做到線上無感熱擴容。

開源Redis灌庫表現不佳 VS 高斯Redis強抗寫能力，應對超高併發挑戰

特徵資料需要定期更新，往往以小時或天為週期進行大規模資料灌入任務。如果儲存元件不夠“皮實”，大量寫入造成資料庫故障，將導致整個推薦系統發生異常。開源Redis抗寫能力不強 ，當大批次寫入到來時，推薦系統就容易出問題，影響使用者體驗。這是由於：

1）單執行緒架構，灌庫過程影響整體讀寫效能；

2）叢集中有一半節點是備節點，它們只能處理讀請求。

華為雲GaussDB（for Redis）採用多執行緒設計+全部節點可寫，抗寫能力足夠強大，從容應對Spark灌庫壓力和實時更新。

此外，基於存算分離架構，GaussDB（for Redis）底層共享資源池可以為《迷你世界》海量遊戲場景及創作內容資料提供三副本強一致，實現全球多區域TB級遊戲場景資料實時同步更新，加速全球玩家的協同創作。

“《迷你世界》有大量的KV資料庫的需求，華為雲GaussDB（for Redis）存算分離的架構和領先的效能確實非常好地滿足了我們產品的需求。”迷你創想雲服技術總監劉琪表示。

在現代商業體系中，推薦系統的重要性與日俱增。GaussDB（for Redis）在頭部沙盒遊戲《迷你世界》的成功應用，證明了其是推薦系統核心資料的極佳選型。不僅如此，GaussDB（for Redis）還展現了多行業場景的適用性。在電商行業，擁有億級使用者的華為商城也採用了GaussDB（for Redis），其在特徵工程平臺建設中起到了關鍵作用。

END

本文為「智慧進化論」原創作品。