故事背景，天書世界，現在專案已經屬於成熟維護期，是時候總結一下當時的想法
第一個問題，為什麼使用mongodb?
- 資料庫對於遊戲專案本身的要求與傳統業務系統差異較大，所以nosql的弱結構性對於我那是相當的有吸引力，
- c++程式碼裡面夾雜著sql這種方式實在是有點醜
- 由於要實現“秒合”，那麼就意味所有的資料必須放到一起，遍尋當時的所有的資料庫，支援熱分片也就mongodb，僅此一家，別無分店
- mongodb號稱與傳統的sql最為接近，你可以像使用sql一樣的去用他
第二個要回答的問題，mongodb有什麼讓人糾結點？
- mongdb的庫級鎖，真是讓人心傷，就是因為你需要用到大量的資料都需要分片，結果你告訴我我這是庫級鎖 ！你是想讓我一張表一個庫吧？
- 連線數過多，就是不想自己做中件間，或者說是資料庫訪問層，才想到你的分片，你居然告訴我連線數過多，差不多到10000多連線就卡得跟鬼一樣！
- mongdb客戶端的不成熟，編譯個c++版本，還得引入個巨大無比的boost，c版本各種混亂，現在可倒好，升級到3.x，直接連這些驅動都不能用了。
- 沒有lua官方驅動，只好網上找開源實現，但畢竟不是官方，我猜連線有洩漏
- 號稱跟傳統mysql之類最為接近，結果索引的效果跟mysql差異非常大，特別是聯合索引，表的設計模式也是相當的不同，否則的話夠你受的
- 做了分片之後mongodb效能分析就非常難用了，沒有辦法用很簡單的方式找到慢查詢
- 有時候我們還是需要有一個自增id的，由於mongodb的實現方式也好，或者說分片機制也罷，總之，如果需要實現一個自增id對於mongodb是個難題
- 記憶體過大，硬碟空間過大
第三個問題，都這樣了，有什麼要說的嗎？
- 出來混的，總是要還的！所有妄圖解決業務問題的開源解決方案，最終還是解決不了問題，並帶給你一堆苦惱。所以，這麼大的資料量，自己實現中介軟體，自己基於業務進行分片，還是最好的解決方式，對於效能也有一個更清楚的認識，合併查詢
- 如果僅僅是基於資料大集中，還是把資料大集中的資料庫作為一個備份庫更加合適一些，防止出現當總個遊戲服的大資料集中依賴於這個點，導致當這個點出現問題時風險過份集中
- mongodb只要轉變思路還是一個相當不錯的資料庫，nosql的優點一覽無疑，對於遊戲這種弱資料結構的場景是非常合適的，並且最好採用單機方案，不去做分片，很方便的慢查詢非常快就找到了
- 儘量做好分表，或者說要儘量能分的表儘量分掉，如果可以用日期分表，然後，讓新舊資料隔離，效能會非常出色
- 規劃好索引，特別是聯合索引，mongodb要直接命中聯合索引效能才能比較好
- 如果能用3.x還是用3.x吧，至少庫級鎖的問題就解決了，2.x的話，儘量從業務上把庫分掉
- 至於佔用記憶體過大，及空間過大的問題，3.x的新引擎據說已經很好的處理了一下
- 如果採用3.x的話，意味著lua客戶端的庫就有很多不支援了。。因為驗證方式的改變，那麼可以採用我新實現的方案,由於是採用luajit的ffi實現的，所以，可能很多不能用，自己看著辦吧，https://github.com/linbc/mongo-clua-driver
常規經驗貼，推薦
http://www.cnblogs.com/cswuyg/p/4595799.html
http://www.cnblogs.com/cswuyg/p/4355948.html