數據庫選擇歷程
我們的項目一直使用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的思路對于游戲服務器存儲來說簡直是完美的!
轉載請注明: 戰魂小筑http://m.shnenglu.com/sunicdavy
NoSQL數據庫方案對比
NoSQL下實現方案很多, 游戲常用的就這么3家: mongo, redis, memcached
下面說下優缺點
mongo
磁盤映射內存數據庫
value為document類型, 基于BSON的value序列化
應用場景:
適合多寫少讀, 例如日志和備份
轉載請注明: 戰魂小筑http://m.shnenglu.com/sunicdavy
redis
內存數據庫
單核
value限制512M
多種value類型, 游戲用途使用私有的序列化協議(例如protobuf)
支持落地(bgsave)
用戶: 新浪, 淘寶, Flickr, Github
應用場景: 適合讀寫都很高, 數據處理復雜等
轉載請注明: 戰魂小筑http://m.shnenglu.com/sunicdavy
memcached
內存數據庫
多核
value限制1M
不支持落地(持久化)
用戶: LiveJournal、hatena、Facebook、Vox
應用場景: 動態系統中的緩沖, 適合多讀少寫
轉載請注明: 戰魂小筑http://m.shnenglu.com/sunicdavy
個人評價
memcached 適合網頁緩沖, 游戲里很少有使用. 目前只有騰訊云支持云memcached
redis非常適合游戲的內存數據庫, 但是落地策略會比較復雜, 需要具體分析, 可以參考后面的鏈接看下云風怎么處理這個問題
mongo數據庫在早期還是非常不錯的NoSQL的數據庫. 工具比較方便, 可視化. 但是隨著近年來游戲的并發度越來越高, 所以為了一次到位, 很多人還是選擇了redis
下圖參考自知乎問題. 鏈接在后面有提示, 若侵權請聯系刪除
轉載請注明: 戰魂小筑http://m.shnenglu.com/sunicdavy
參考鏈接:
談談陌陌爭霸在數據庫方面踩過的坑( Redis 篇)
http://blog.codingnow.com/2014/03/mmzb_redis.html
轉載請注明: 戰魂小筑http://m.shnenglu.com/sunicdavy
Memcache,Redis,MongoDB（數據緩存系統）方案對比與分析
http://blog.csdn.net/suifeng3051/article/details/23739295
http://www.zhihu.com/question/31417262