• <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://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序列化

            應用場景:

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

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

             

            redis

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

            單核

            value限制512M

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

            支持落地(bgsave)

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

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

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

             

            memcached

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

            多核

            value限制1M

            不支持落地(持久化)

            用戶: LiveJournal、hatena、Facebook、Vox

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

            轉(zhuǎn)載請注明: 戰(zhàn)魂小筑http://m.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://m.shnenglu.com/sunicdavy

            image

            參考鏈接:

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

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

            轉(zhuǎn)載請注明: 戰(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


            評論

            # 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ā)期的甜蜜時光,后面就有的痛苦了。  回復  更多評論
              

            国产精品美女久久久久网| 国产精品无码久久四虎| 久久精品国产亚洲av麻豆图片| 亚洲精品乱码久久久久久不卡| 久久久国产视频| 国产综合久久久久| 色天使久久综合网天天| 久久精品午夜一区二区福利 | 久久99九九国产免费看小说| 久久国语露脸国产精品电影| 99国产精品久久| 佐藤遥希在线播放一二区 | 99久久国产热无码精品免费| 久久久久久国产精品免费免费| 久久综合狠狠综合久久| 久久影院午夜理论片无码 | 偷窥少妇久久久久久久久| 久久综合久久综合久久| 午夜不卡久久精品无码免费| 久久亚洲高清综合| 国产精品九九久久精品女同亚洲欧美日韩综合区| 久久久国产99久久国产一| 精品久久久久久无码人妻热| 丰满少妇高潮惨叫久久久| 中文精品久久久久人妻不卡| 欧美久久一级内射wwwwww.| 久久亚洲欧美日本精品| 久久99精品久久只有精品| 久久久亚洲欧洲日产国码是AV| 精品国产热久久久福利| 国内精品久久久久影院网站 | 久久精品国产男包| 免费精品国产日韩热久久| 天天综合久久一二三区| 久久久精品人妻无码专区不卡| 久久精品国产亚洲精品2020| 国产A三级久久精品| 色88久久久久高潮综合影院 | 久久精品国产亚洲网站| 色播久久人人爽人人爽人人片aV | 久久久久久久97|