MongoDB中的一些坑（最好不要用）

更新時間：2015年03月23日 10:34:26 投稿：junjie

這篇文章主要介紹了MongoDB中的一些坑（最好不要用）,本文總結了MongoDB 數(shù)據(jù)庫級鎖、建索引導致數(shù)據(jù)庫阻塞、不合理使用嵌入 embed document、不合理使用 Array 字段等4個坑,需要的朋友可以參考下

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

MongoDB 數(shù)據(jù)庫級鎖

坑爹指數(shù)：5星（最高5星）

MongoDB的鎖機制和一般關系數(shù)據(jù)庫如 MySQL（InnoDB）, Oracle 有很大的差異，InnoDB 和 Oracle 能提供行級粒度鎖，而 MongoDB 只能提供庫級粒度鎖，這意味著當 MongoDB 一個寫鎖處于占用狀態(tài)時，其它的讀寫操作都得干等。

初看起來庫級鎖在大并發(fā)環(huán)境下有嚴重的問題，但是 MongoDB 依然能夠保持大并發(fā)量和高性能，這是因為 MongoDB 的鎖粒度雖然很粗放，但是在鎖處理機制和關系數(shù)據(jù)庫鎖有很大差異，主要表現(xiàn)在：

MongoDB 沒有完整事務支持，操作原子性只到單個 document 級別，所以通常操作粒度比較小；
MongoDB 鎖實際占用時間是內存數(shù)據(jù)計算和變更時間，通常很快；
MongoDB 鎖有一種臨時放棄機制，當出現(xiàn)需要等待慢速 IO 讀寫數(shù)據(jù)時，可以先臨時放棄，等 IO 完成之后再重新獲取鎖。
通常不出問題不等于沒有問題，如果數(shù)據(jù)操作不當，依然會導致長時間占用寫鎖，比如下面提到的前臺建索引操作，當出現(xiàn)這種情況的時候，整個數(shù)據(jù)庫就處于完全阻塞狀態(tài)，無法進行任何讀寫操作，情況十分嚴重。

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

建索引導致數(shù)據(jù)庫阻塞

坑爹指數(shù)：3星

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

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

復制代碼代碼如下:

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

而應該使用

復制代碼代碼如下:

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

不合理使用嵌入 embed document

坑爹指數(shù)：5星

embed document 是 MongoDB 相比關系數(shù)據(jù)庫差異明顯的一個地方，可以在某一個 document 中嵌入其它子 document，這樣可以在父子 document 保持在單一 collection 中，檢索修改比較方便。

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

復制代碼代碼如下:

class Group
include Mongoid::Document
...
embeds_many :group_requests
...
end

class GroupRequest
include Mongoid::Document
...
embedded_in :group
...
end

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

仔細分析后，發(fā)現(xiàn)某些活躍的 Group 的 group_requests 增加（當有新申請時）和更改（當通過或拒絕用戶申請時）異常頻繁，而這些操作經(jīng)常長時間占用寫鎖，導致整個數(shù)據(jù)庫阻塞。原因是當有增加 group_request 操作時，Group 預分配的空間不夠，需要重新分配空間（內存和硬盤都需要），耗時較長，另外 Group 上建的索引很多，移動 Group 位置導致大量索引更新操作也很耗時，綜合起來引起了長時間占用鎖問題。

解決問題的方法，說起來也簡單，就是把 embed 關聯(lián)更改成的普通外鍵關聯(lián)，就是類似關系數(shù)據(jù)庫的做法，這樣 group_request 增加或修改都只發(fā)生在 GroupRequest 上，簡單快速，避免長時間占用寫鎖問題。當關聯(lián)對象的數(shù)據(jù)不固定或者經(jīng)常發(fā)生變化時，一定要避免使用 embed 關聯(lián)，不然會死的很慘。

不合理使用 Array 字段

坑爹指數(shù)：4星

MongoDB 的 Array 字段是比較獨特的一個特性，它可以在單個 document 里存儲一些簡單的一對多關系。

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

復制代碼代碼如下:

class User

  include Mongoid::Document

  ...

  field :follower_user_ids, type: Array, default: []

  ...

end

User 中通過一個 Array 類型字段 follower_user_ids 保存用戶關注的人的 id，用戶關注的人從 10個到 3000 個不等，變化是比較頻繁的，和上面 embed 引發(fā)的問題類似，頻繁的 follower_user_ids 增加修改操作導致大量長時間數(shù)據(jù)庫寫鎖，從而引發(fā) MongoDB 數(shù)據(jù)庫性能急劇下降。

解決問題的方法：我們把 follower_user_ids 轉移到了內存數(shù)據(jù)庫 redis 中，避免了頻繁更改 MongoDB 中的 User, 從而徹底解決問題。如果不使用 redis，也可以建立一個 UserFollower 集合，使用外鍵形式關聯(lián)。

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

您可能感興趣的文章: