• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            戰(zhàn)魂小筑

            討論群:309800774 知乎關(guān)注:http://zhihu.com/people/sunicdavy 開源項目:https://github.com/davyxu

               :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
              257 隨筆 :: 0 文章 :: 506 評論 :: 0 Trackbacks

            數(shù)據(jù)庫選擇歷程

            我們的項目一直使用MySQL作為數(shù)據(jù)庫. 無論是從C++的服務器, 還是到Golang服務器. 當年搞服務器時, 看大部分人都是用SQL(MySQL/SQLServer), 而Mongo感覺像邪教一樣, 再加上服務器還是Linux比較正統(tǒng), 所以果斷選了MySQL.

            剛開始感覺,游戲服務器的數(shù)據(jù)存儲其實應該是蠻神圣的過程. 那么多的數(shù)據(jù), 需要按照MySQL一樣分表, 分字段存儲, 為了查詢, 還要乖乖的學一下SQL的語法

            就這么折騰了幾年. 在云DB的蒙蔽下, 一直認為MySQL就是做游戲服務器存儲的專業(yè)技術(shù). 分布式和存儲壓力一定交給云DB來做. 直到真正試了下NoSQL在游戲服務器開發(fā)里的思路.

            用了Golang, 才發(fā)現(xiàn)同步寫邏輯是多么的優(yōu)雅.

            用了NoSQL系列的數(shù)據(jù)庫, 才意識到: 游戲服務器的數(shù)據(jù)存儲和游戲服務器的存盤兩個概念差異其實蠻大的.

            MySQL中, 背包其實跟角色完全沒有關(guān)系, 只是通過1個角色id映射過去, 人為的割裂了數(shù)據(jù)的關(guān)聯(lián)性. 還硬生生的整出個概念叫結(jié)構(gòu)化查詢讓你學

            NoSQL中, 只是把數(shù)據(jù)庫當成是存儲點, 每個角色的數(shù)據(jù)是完整的一塊. 里面怎么存隨你便. 每個角色通過id來查詢, 其他都沒有了

            于是乎, 游戲開發(fā)變得異常簡單. MySQL角色進門查詢4~5次才能搞定要的數(shù)據(jù).而NoSQL一口氣全查出來, 存盤也無需增量, 直接存盤就可以了

            所以現(xiàn)在覺得, NoSQL的思路對于游戲服務器存儲來說簡直是完美的!

            轉(zhuǎn)載請注明: 戰(zhàn)魂小筑http://www.shnenglu.com/sunicdavy

             

            NoSQL數(shù)據(jù)庫方案對比

            NoSQL下實現(xiàn)方案很多, 游戲常用的就這么3家: mongo, redis, memcached

            下面說下優(yōu)缺點

            mongo

            磁盤映射內(nèi)存數(shù)據(jù)庫

            value為document類型, 基于BSON的value序列化

            應用場景:

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

            轉(zhuǎn)載請注明: 戰(zhàn)魂小筑http://www.shnenglu.com/sunicdavy

             

            redis

            內(nèi)存數(shù)據(jù)庫

            單核

            value限制512M

            多種value類型, 游戲用途使用私有的序列化協(xié)議(例如protobuf)

            支持落地(bgsave)

            用戶: 新浪, 淘寶, Flickr, Github

            應用場景: 適合讀寫都很高, 數(shù)據(jù)處理復雜等

            轉(zhuǎn)載請注明: 戰(zhàn)魂小筑http://www.shnenglu.com/sunicdavy

             

            memcached

            內(nèi)存數(shù)據(jù)庫

            多核

            value限制1M

            不支持落地(持久化)

            用戶: LiveJournal、hatena、Facebook、Vox

            應用場景: 動態(tài)系統(tǒng)中的緩沖, 適合多讀少寫

            轉(zhuǎn)載請注明: 戰(zhàn)魂小筑http://www.shnenglu.com/sunicdavy

            個人評價

            memcached 適合網(wǎng)頁緩沖, 游戲里很少有使用. 目前只有騰訊云支持云memcached

            redis非常適合游戲的內(nèi)存數(shù)據(jù)庫, 但是落地策略會比較復雜, 需要具體分析, 可以參考后面的鏈接看下云風怎么處理這個問題

            mongo數(shù)據(jù)庫在早期還是非常不錯的NoSQL的數(shù)據(jù)庫. 工具比較方便, 可視化. 但是隨著近年來游戲的并發(fā)度越來越高, 所以為了一次到位, 很多人還是選擇了redis

            下圖參考自知乎問題. 鏈接在后面有提示, 若侵權(quán)請聯(lián)系刪除

            轉(zhuǎn)載請注明: 戰(zhàn)魂小筑http://www.shnenglu.com/sunicdavy

            image

            參考鏈接:

                談談陌陌爭霸在數(shù)據(jù)庫方面踩過的坑( Redis 篇)

            http://blog.codingnow.com/2014/03/mmzb_redis.html

            轉(zhuǎn)載請注明: 戰(zhàn)魂小筑http://www.shnenglu.com/sunicdavy

            Memcache,Redis,MongoDB(數(shù)據(jù)緩存系統(tǒng))方案對比與分析

            http://blog.csdn.net/suifeng3051/article/details/23739295

             

            http://www.zhihu.com/question/31417262


            評論

            # re: 游戲數(shù)據(jù)庫選型mysql,mongo, redis, memcached[未登錄] 2015-07-12 02:11 楊粼波
            有redis就用redis,沒有就用memcached,memcached是redis的子集,也可以稱之為memcached的升級版。redis的查詢語句要豐富得多,當然,也是要復雜的多。

            mongoDB雖然也是NoSQL數(shù)據(jù)庫,但是與以上兩者有很大的區(qū)別。首先,它是磁盤數(shù)據(jù)庫,而不是內(nèi)存數(shù)據(jù)庫,雖然也可以搞成內(nèi)存數(shù)據(jù)庫,但是那是歪門邪道。而且,該數(shù)據(jù)庫的穩(wěn)定性有待改進,對于數(shù)據(jù)庫而言,穩(wěn)定性是我們首要考慮的,服務不能出問題,數(shù)據(jù)不能出問題。而mysql這樣發(fā)展了許多年的數(shù)據(jù)庫就是我們的首選了,通常將其作為熱備數(shù)據(jù)庫。

            redis的熱備份看起來很美好,但其實不好用,還有損性能。通常都會被關(guān)閉掉。

            以前新浪是用的memcached,現(xiàn)在不知道了,他們還好像自己改進了,當然,主要是做分布式。

            淘寶也有基于memcached開發(fā)的Tair,不過據(jù)說現(xiàn)在他們自己也慢慢開始放棄了,主要也是在分布式上作了點文章。http://code.taobao.org/p/tair/src/

            對于游戲這樣的應用而言,只要不是騰訊那樣的用戶量級,都不需要考慮分布式的問題。只需要省心便可,用redis功能多,自然是首選。  回復  更多評論
              

            # re: 游戲數(shù)據(jù)庫選型mysql,mongo, redis, memcached[未登錄] 2015-07-12 02:27 楊粼波
            再啰嗦幾句。

            阿里云也支持memcached的,當然也支持redis,
            騰訊云太挫了,我對它印象不好,有用過,redis是今年才支持的,要不是因為不支持redis,我也就不會選擇memcached了,很多功能本可以用redis里面很簡單一條命令搞定的,不過話說回來,至少也沒有它搞不定的事情。

            memcached有個最郁悶的事情就是沒有什么稱手的工具,只有一個php的memAdmin以及http://www.cnblogs.com/xffy1028/archive/2013/02/01/2861706.html

            而Redis有一個http://www.oschina.net/p/redisdesktop,這個很好用。

            內(nèi)存數(shù)據(jù)庫相對于磁盤數(shù)據(jù)庫而言,不要抱有太大期望。只不過是說,磁盤數(shù)據(jù)庫隨著數(shù)據(jù)量增大,它的性能會呈指數(shù)級降低。而內(nèi)存數(shù)據(jù)庫基本上是沒有太大的影響,僅此而已。磁盤數(shù)據(jù)庫數(shù)據(jù)量少的時候,可能跟內(nèi)存數(shù)據(jù)庫的性能差不多哦。  回復  更多評論
              

            # re: 游戲數(shù)據(jù)庫選型mysql,mongo, redis, memcached 2015-07-13 09:24 戰(zhàn)魂小筑
            @楊粼波
            感謝楊大大專業(yè)級回答  回復  更多評論
              

            # re: 游戲數(shù)據(jù)庫選型mysql,mongo, redis, memcached[未登錄] 2015-07-14 12:50 楊粼波
            @戰(zhàn)魂小筑
            專業(yè)倒稱不上,因為做過,這些都比較了解了,只能說是過來人罷了。我那個數(shù)量級,簡直要笑掉大牙的。要專家級,起碼得經(jīng)歷過大用戶量的沖擊才行啊。  回復  更多評論
              

            # re: 游戲數(shù)據(jù)庫選型mysql,mongo, redis, memcached 2015-07-20 20:29 T
            mongo號稱程序員的最愛,運維的噩夢。
            過了開發(fā)期的甜蜜時光,后面就有的痛苦了。  回復  更多評論
              

            国内精品久久久久影院老司 | 色综合久久久久无码专区| 久久丝袜精品中文字幕| 2020久久精品亚洲热综合一本| 超级97碰碰碰碰久久久久最新| 午夜天堂av天堂久久久| 久久青草国产精品一区| 久久这里有精品| 狠狠狠色丁香婷婷综合久久俺| 久久综合亚洲色HEZYO国产| 亚洲中文字幕久久精品无码APP| 91久久香蕉国产熟女线看| 久久久久亚洲AV片无码下载蜜桃| 蜜臀av性久久久久蜜臀aⅴ| 久久e热在这里只有国产中文精品99| 久久久久亚洲国产| 久久国产综合精品五月天| 久久久一本精品99久久精品66| 青青青青久久精品国产h久久精品五福影院1421 | 国产精品青草久久久久福利99 | 久久久国产99久久国产一| 久久国产精品久久精品国产| 久久久久久久久久久精品尤物| 国产激情久久久久影院老熟女| 麻豆一区二区99久久久久| 偷窥少妇久久久久久久久| 久久免费视频6| 久久精品国产一区二区三区不卡| 国产成年无码久久久久毛片| 久久精品免费一区二区| 久久免费视频1| 久久笫一福利免费导航 | 日韩久久无码免费毛片软件| 88久久精品无码一区二区毛片| 精品无码久久久久国产| 亚洲va久久久噜噜噜久久 | 久久香综合精品久久伊人| 日产精品久久久久久久性色| 亚洲精品国精品久久99热一| 久久人妻少妇嫩草AV无码专区| 久久久无码一区二区三区|