資料庫選擇歷程

我們的專案一直使用MySQL作為資料庫. 無論是從C++的伺服器, 還是到Golang伺服器. 當年搞伺服器時, 看大部分人都是用SQL(MySQL/SQLServer), 而Mongo感覺像邪教一樣, 再加上伺服器還是Linux比較正統, 所以果斷選了MySQL.

剛開始感覺,遊戲伺服器的資料儲存其實應該是蠻神聖的過程. 那麼多的資料, 需要按照MySQL一樣分表, 分欄位儲存, 為了查詢, 還要乖乖的學一下SQL的語法

就這麼折騰了幾年. 在雲DB的矇蔽下, 一直認為MySQL就是做遊戲伺服器儲存的專業技術. 分散式和儲存壓力一定交給雲DB來做. 直到真正試了下NoSQL在遊戲伺服器開發裡的思路.

用了Golang, 才發現同步寫邏輯是多麼的優雅.

用了NoSQL系列的資料庫, 才意識到: 遊戲伺服器的資料儲存和遊戲伺服器的存檔兩個概念差異其實蠻大的.

MySQL中, 揹包其實跟角色完全沒有關係, 只是通過1個角色id對映過去, 人為的割裂了資料的關聯性. 還硬生生的整出個概念叫結構化查詢讓你學

NoSQL中, 只是把資料庫當成是儲存點, 每個角色的資料是完整的一塊. 裡面怎麼存隨你便. 每個角色通過id來查詢, 其他都沒有了

於是乎, 遊戲開發變得異常簡單. MySQL角色進門查詢4~5次才能搞定要的資料.而NoSQL一口氣全查出來, 存檔也無需增量, 直接存檔就可以了

所以現在覺得, NoSQL的思路對於遊戲伺服器儲存來說簡直是完美的!

NoSQL資料庫方案對比

NoSQL下實現方案很多, 遊戲常用的就這麼3家: mongo, redis, memcached

下面說下優缺點

mongo

磁碟對映記憶體資料庫

value為document型別, 基於BSON的value序列化

應用場景:

適合多寫少讀, 例如日誌和備份

redis

記憶體資料庫

單核

value限制512M

多種value型別, 遊戲用途使用私有的序列化協議(例如protobuf)

支援落地(bgsave)

使用者: 新浪, 淘寶, Flickr, Github

應用場景: 適合讀寫都很高, 資料處理複雜等

memcached

記憶體資料庫

多核

value限制1M

不支援落地(持久化)

使用者: LiveJournal、hatena、Facebook、Vox

應用場景: 動態系統中的緩衝, 適合多讀少寫

個人評價

memcached 適合網頁緩衝, 遊戲裡很少有使用. 目前只有騰訊雲支援雲memcached

redis非常適合遊戲的記憶體資料庫, 但是落地策略會比較複雜, 需要具體分析, 可以參考後面的連結看下雲風怎麼處理這個問題

mongo資料庫在早期還是非常不錯的NoSQL的資料庫. 工具比較方便, 視覺化. 但是隨著近年來遊戲的併發度越來越高, 所以為了一次到位, 很多人還是選擇了redis

下圖參考自知乎問題. 連結在後面有提示, 若侵權請聯絡刪除

參考連結:

    談談陌陌爭霸在資料庫方面踩過的坑( Redis 篇)

Memcache,Redis,MongoDB（資料快取系統）方案對比與分析