MGO 設計調優。

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

MGO 設計調優。

真的是那句話，不是你不行，知識你不瞭解。而已。

1. 肯定是不能加兩個索引了。
   1. 索引的代價實在是太大了，不但佔用記憶體還還大量損失查詢效能，真心不能忍耐啊。
2. 設計的時候DBRef肯定是需要的，直接用有意義的ID查詢肯定是效能最好的。
3. 控制key的數量肯定是必須的。比如說使用者數量就是key的數量這就夠了。別整那麼多。collection不然損失效能。
   1. 如果真的想控制數量的話，那麼資料關聯肯定是十分必須的。

4. 流量控制肯定也是必須的。

   1. 流量的來源在於Find直接返回所有查詢結果。臥槽。直接吃掉所有流量。
   2. 直接用FindOne 避免查詢多個結果回來肯定是必須的

   3. FindOne就夠了嗎？我確實遇到這個坑了。在博文中已經提到關於這種情況適用filter的方法了。直接參考就OK了。

      1	FindOne({_id:xxx},{Items:{"$slice":[3,1]}})

      雖然適用了這種方法來設計，使得查詢結果減少流量降低了。但是依然存在問題

      1. 一定更要注意，不能直接dbref因為slice不好加啊。可以用過順序id加分頁，或者算時間。233 很實用，典型的用空間換時間。

      1 2 3 4 5 6 7

      db.user.findOne({user_id:2}, {"book.price":1,"book.price.":{$slice:[-10,4]}}) 解釋下其含義哈： 1. user集合 2. user.book.price 表示使用者擁有書籍， 書籍呢有很多價格列表 3. 注意紅色字型 "book.price." 末尾必須有個點 4. 尋找價格列表裡的4條資料， 從右邊第10個位置開始便宜

      但是也有不同的文法說明，到時候試試吧。

5. update 要做精細修改。

1	比如Update({_id:xxx},{$set:{"Items.3.Item.Health":38}});//修改第三把武器的健康值

至於一次修改和批量修改，MongoDB預設100ms flush一次(2.x),只要兩次修改比較貼近,被一起儲存的可能性很高。

上面這些是引用別人說的話,還是全要直接精細修改，然後資料庫會自動一起修改的，效能不成問題

1. 最後幾點注意
   1. 控制io（系統吞吐）這事整個系統的核心，也是系統效能的核心。
   2. 控制記憶體（不要讓index膨脹）
      1. 控制index個數，
      2. 控制key的個數
   3. CPU控制不要讓js做大量的計算，能遷移到用戶端的計算就遷移到用戶端，讓他們算完之後在通訊
   4. 第一個效能不夠的估計是硬碟，可以通過RAID或者企業級SSD搞定整個問題。

Golang MGO驅動使用

ref1

ref2