MongoDB 那些坑(轉)

標籤：http   io   ar   os   使用   java   sp   strong   資料   

MongoDB 是目前炙手可熱的 NoSQL 文檔型資料庫，它提供的一些特性很棒：如自動 failover 機制，自動 sharding，無模式 schemaless，大部分情況下效能也很棒。但是薄荷在深入使用 MongoDB 過程中，遇到了不少問題，下面總結幾個我們遇到的坑。特別申明：我們目前用的 MongoDB 版本是 2.4.10，曾經升級到 MongoDB 2.6.0 版本，問題依然存在，又回退到 2.4.10 版本。

MongoDB 資料庫級鎖

坑爹指數：5星（最高5星）

MongoDB的鎖機制和一般關聯式資料庫如 MySQL（InnoDB）, Oracle 有很大的差異，InnoDB 和 Oracle 能提供行級粒度鎖，而 MongoDB 只能提供 庫級粒度鎖，這意味著當 MongoDB 一個寫鎖處於佔用狀態時，其它的讀寫操作都得乾等。

初看起來庫級鎖在大並發環境下有嚴重的問題，但是 MongoDB 依然能夠保持大並發量和高效能，這是因為 MongoDB 的鎖粒度雖然很粗放，但是在鎖處理機制和關聯式資料庫鎖有很大差異，主要表現在：

• MongoDB 沒有完整事務支援，操作原子性只到單個 document 層級，所以通常操作粒度比較小；
• MongoDB 鎖實際佔用時間是記憶體資料計算和變更時間，通常很快；
• MongoDB 鎖有一種臨時放棄機制，當出現需要等待慢速 IO 讀寫資料時，可以先臨時放棄，等 IO 完成之後再重新擷取鎖。

通常不出問題不等於沒有問題，如果資料操作不當，依然會導致長時間佔用寫鎖，比如下面提到的前台建索引操作，當出現這種情況的時候，整個資料庫就處於完全阻塞狀態，無法進行任何讀寫操作，情況十分嚴重。

解決問題的方法，盡量避免長時間佔用寫鎖操作，如果有一些集合操作實在難以避免，可以考慮把這個集合放到一個單獨的 MongoDB 庫裡，因為 MongoDB 不同庫鎖是相互隔離的，分離集合可以避免某一個集合操作引發全域阻塞問題。

建索引導致資料庫阻塞

坑爹指數：3星

上面提到了 MongoDB 庫級鎖的問題，建索引就是一個容易引起長時間寫鎖的問題，MongoDB 在前台建索引時需要佔用一個寫鎖（而且不會臨時放棄），如果集合的資料量很大，建索引通常要花比較長時間，特別容易引起問題。

解決的方法很簡單，MongoDB 提供了兩種建索引的訪問，一種是 background 方式，不需要長時間佔用寫鎖，另一種是非 background 方式，需要長時間佔用鎖。使用 background 方式就可以解決問題。
例如，為超大表 posts 建立索引，
千萬不用使用

db.posts.ensureIndex({user_id: 1}) 

而應該使用

db.posts.ensureIndex({user_id: 1}, {background: 1}) 

不合理使用嵌入 embed document

坑爹指數：5星

embed document 是 MongoDB 相比關聯式資料庫差異明顯的一個地方，可以在某一個 document 中嵌入其它子 document，這樣可以在父子 document 保持在單一 collection 中，檢索修改比較方便。

比如薄荷的應用情景中有一個 Group document，使用者申請加入 Group 建模為 GroupRequest document，我們最初的時候使用 embed 方式把 GroupRequest 放置到 Group 中。
Ruby 代碼如下所示（使用了 Mongoid ORM）:

?

12345678910111213

class Group  include Mongoid::Document  ...  embeds_many :group_requests  ...end class GroupRequest  include Mongoid::Document  ...  embedded_in :group  ...end

這個使用方式讓我們掉到坑裡了，差點就爬不出來，它導致有接近兩周的時間系統問題，高峰時段常有幾分鐘的系統卡頓，最嚴重一次甚至引起 MongoDB 宕機。

仔細分析後，發現某些活躍的 Group 的 group_requests 增加（當有新申請時）和更改（當通過或拒絕使用者申請時）異常頻繁，而這些操作經常長時間佔用寫鎖，導致整個資料庫阻塞。原因是當有增加 group_request 操作時，Group 預分配的空間不夠，需要重新分配空間（記憶體和硬碟都需要），耗時較長，另外 Group 上建的索引很多，移動 Group 位置導致大量索引更新操作也很耗時，綜合起來引起了長時間佔用鎖問題。

解決問題的方法，說起來也簡單，就是把 embed 關聯更改成的普通外部索引鍵關聯，就是類似關聯式資料庫的做法，這樣 group_request 增加或修改都只發生在 GroupRequest 上，簡單快速，避免長時間佔用寫鎖問題。當關聯對象的資料不固定或者經常發生變化時，一定要避免使用 embed 關聯，不然會死的很慘。

不合理使用 Array 欄位

坑爹指數：4星

MongoDB 的 Array 欄位是比較獨特的一個特性，它可以在單個 document 裡儲存一些簡單的一對多關聯性。

薄荷有一個應用情景使用遇到嚴重的效能問題，直接上代碼如下所示：

?

123456

class User  include Mongoid::Document  ...  field :follower_user_ids, type: Array, default: []  ...end

User 中通過一個 Array 類型欄位 follower_user_ids 儲存使用者關注的人的 id，使用者關注的人從 10個到 3000 個不等，變化是比較頻繁的，和上面 embed 引發的問題類似，頻繁的 follower_user_ids 增加修改操作導致大量長時間資料庫寫鎖，從而引發 MongoDB 資料庫效能急劇下降。

解決問題的方法：我們把 follower_user_ids 轉移到了記憶體資料庫 redis 中，避免了頻繁更改 MongoDB 中的 User, 從而徹底解決問題。如果不使用 redis，也可以建立一個 UserFollower 集合，使用外鍵形式關聯。

先列舉上面幾個坑吧，都是害人不淺的陷阱，使用 MongoDB 過程一定要多加註意，避免掉到坑裡。

參考資料：
* 1.MongoDB 鎖機制詳解
* 2.MongoDB 建立索引操作文檔

來自：http://xiewenwei.github.io/

MongoDB 那些坑(轉)