數(shù)據(jù)庫選擇歷程
我們的項目一直使用MySQL作為數(shù)據(jù)庫. 無論是從C++的服務器, 還是到Golang服務器. 當年搞服務器時, 看大部分人都是用SQL(MySQL/SQLServer), 而Mongo感覺像邪教一樣, 再加上服務器還是Linux比較正統(tǒng), 所以果斷選了MySQL.
剛開始感覺,游戲服務器的數(shù)據(jù)存儲其實應該是蠻神圣的過程. 那么多的數(shù)據(jù), 需要按照MySQL一樣分表, 分字段存儲, 為了查詢, 還要乖乖的學一下SQL的語法
就這么折騰了幾年. 在云DB的蒙蔽下, 一直認為MySQL就是做游戲服務器存儲的專業(yè)技術. 分布式和存儲壓力一定交給云DB來做. 直到真正試了下NoSQL在游戲服務器開發(fā)里的思路.
用了Golang, 才發(fā)現(xiàn)同步寫邏輯是多么的優(yōu)雅.
用了NoSQL系列的數(shù)據(jù)庫, 才意識到: 游戲服務器的數(shù)據(jù)存儲和游戲服務器的存盤兩個概念差異其實蠻大的.
MySQL中, 背包其實跟角色完全沒有關系, 只是通過1個角色id映射過去, 人為的割裂了數(shù)據(jù)的關聯(lián)性. 還硬生生的整出個概念叫結構化查詢讓你學
NoSQL中, 只是把數(shù)據(jù)庫當成是存儲點, 每個角色的數(shù)據(jù)是完整的一塊. 里面怎么存隨你便. 每個角色通過id來查詢, 其他都沒有了
于是乎, 游戲開發(fā)變得異常簡單. MySQL角色進門查詢4~5次才能搞定要的數(shù)據(jù).而NoSQL一口氣全查出來, 存盤也無需增量, 直接存盤就可以了
所以現(xiàn)在覺得, NoSQL的思路對于游戲服務器存儲來說簡直是完美的!
轉載請注明: 戰(zhàn)魂小筑http://m.shnenglu.com/sunicdavy
NoSQL數(shù)據(jù)庫方案對比
NoSQL下實現(xiàn)方案很多, 游戲常用的就這么3家: mongo, redis, memcached
下面說下優(yōu)缺點
mongo
磁盤映射內(nèi)存數(shù)據(jù)庫
value為document類型, 基于BSON的value序列化
應用場景:
適合多寫少讀, 例如日志和備份
轉載請注明: 戰(zhàn)魂小筑http://m.shnenglu.com/sunicdavy
redis
內(nèi)存數(shù)據(jù)庫
單核
value限制512M
多種value類型, 游戲用途使用私有的序列化協(xié)議(例如protobuf)
支持落地(bgsave)
用戶: 新浪, 淘寶, Flickr, Github
應用場景: 適合讀寫都很高, 數(shù)據(jù)處理復雜等
轉載請注明: 戰(zhàn)魂小筑http://m.shnenglu.com/sunicdavy
memcached
內(nèi)存數(shù)據(jù)庫
多核
value限制1M
不支持落地(持久化)
用戶: LiveJournal、hatena、Facebook、Vox
應用場景: 動態(tài)系統(tǒng)中的緩沖, 適合多讀少寫
轉載請注明: 戰(zhàn)魂小筑http://m.shnenglu.com/sunicdavy
個人評價
memcached 適合網(wǎng)頁緩沖, 游戲里很少有使用. 目前只有騰訊云支持云memcached
redis非常適合游戲的內(nèi)存數(shù)據(jù)庫, 但是落地策略會比較復雜, 需要具體分析, 可以參考后面的鏈接看下云風怎么處理這個問題
mongo數(shù)據(jù)庫在早期還是非常不錯的NoSQL的數(shù)據(jù)庫. 工具比較方便, 可視化. 但是隨著近年來游戲的并發(fā)度越來越高, 所以為了一次到位, 很多人還是選擇了redis
下圖參考自知乎問題. 鏈接在后面有提示, 若侵權請聯(lián)系刪除
轉載請注明: 戰(zhàn)魂小筑http://m.shnenglu.com/sunicdavy
參考鏈接:
談談陌陌爭霸在數(shù)據(jù)庫方面踩過的坑( Redis 篇)
http://blog.codingnow.com/2014/03/mmzb_redis.html
轉載請注明: 戰(zhàn)魂小筑http://m.shnenglu.com/sunicdavy
Memcache,Redis,MongoDB（數(shù)據(jù)緩存系統(tǒng)）方案對比與分析
http://blog.csdn.net/suifeng3051/article/details/23739295
http://www.zhihu.com/question/31417262