MongoDB優(yōu)化心得分享

這里總結(jié)下這段時間使用mongo的心得，列出了幾個需要注意的地方。

1. 系統(tǒng)參數(shù)及mongo參數(shù)設置

mongo參數(shù)主要是storageEngine和directoryperdb，這兩個參數(shù)一開始不選定后續(xù)就無法再更改。

directoryperdb主要是將數(shù)據(jù)庫分文件夾存放，方便后續(xù)的備份及數(shù)據(jù)遷移。

storageEngine（存儲引擎）默認使用的是MMAPv1，推薦使用3.0新加入的引擎wiredTiger。經(jīng)實際使用wiredTiger占用的磁盤空間是MMAP的1/5，索引大小是其1/2，查詢速度也提高很多，更重要的是該引擎提供了document級別的鎖，當集合插入或更新數(shù)據(jù)時不需要阻塞讀操作了。唯一的問題是市面上支持該引擎查詢的工具不多，MongoVUE無法查到該引擎存儲的集合，NosqlManager-mongo可以查到但需要.net環(huán)境支持。個人覺得熟悉下mongo command用mongo shell就足夠了，所以還是強烈推薦使用wiredTiger引擎。

2. 無需對集合進行水平切分

由于之前一直使用關系型數(shù)據(jù)庫，關系型數(shù)據(jù)庫當單表數(shù)據(jù)量超大時經(jīng)常使用的一直方法是對數(shù)據(jù)表進行分表。在使用mongo時便很自然的覺得這招仍然有用。由于該系統(tǒng)的分表都是動態(tài)生成的，做到后面發(fā)現(xiàn)這招對mongo帶來的性能提升遠遠抵不過維護成本的增加。

分析一下關系型數(shù)據(jù)庫分表會提高性能的最大原因是很多關系型數(shù)據(jù)庫一張表是一個文件，分表可以避免一個文件過大所造成數(shù)據(jù)提取速度變慢。但是mongo并不是這樣存儲的，所以這條并不成立了。

用過的都知道m(xù)ongo對索引的依賴非常大，如果集合不能一開始就設計好，那后續(xù)索引就得寫腳本來創(chuàng)建。這里貢獻個給mongo大表動態(tài)創(chuàng)建索引的腳本：

eval(function () {
  var infos = [];
  var collNames = db.getCollectionNames();
  for (var i = 0; i < collNames.length; i++) {
    var collName = collNames[i];
    var collSize = db.getCollection(collName).count();
    if (collSize > 1000000 && collName.indexOf("info_")==0) {
     db.getCollection(collName).ensureIndex({publishDate:-1,blendedScore:-1,publishTime:-1,isRubbish:1},{name:"ScoreSortIdx",background:true});
      db.getCollection(collName).ensureIndex({similarNum:-1,publishTime:-1,isRubbish:1},{name:"HotSortIdx",background:true});
      db.getCollection(collName).ensureIndex({publishTime:-1,isRubbish:1},{name:"TimeSortIdx",background:true});
      infos.push("name:" + collName + "索引創(chuàng)建成功");
    }
  }
  return infos;
}());

這么看動態(tài)創(chuàng)建索引勉強還是可以解決的，但是最坑的一個地方是sharding完全沒辦法做了。shard需要指定要shard的集合和分區(qū)鍵，這個就沒法提前動態(tài)指定了。所以mongo集合不需要做水平切分（至少千萬級不需要了，更大直接shard掉），只需要按業(yè)務分開就可以了。

3. 使用Capped Collection

有人使用mongo做數(shù)據(jù)緩存，而且是緩存固定數(shù)量的數(shù)據(jù)，仍然用正常的集合，然后定期清理數(shù)據(jù)。其實這時用capped collection性能會好很多。

4. 生產(chǎn)環(huán)境一定要用副本集

很多人線上環(huán)境還是用單機版，雖然部署快但是很多mongo自然提供的功能都沒有用到像自動故障轉(zhuǎn)移、讀寫分離，這些對后續(xù)系統(tǒng)擴容及性能優(yōu)化太重要了。我想會使用mongo的應該是數(shù)據(jù)量達到一定級別，查詢性能會非常重要，所以強烈建議上線時直接使用副本集。

5. 學會使用explain

之前一直習慣用工具來查詢，現(xiàn)在發(fā)現(xiàn)應該多使用mongo shell命令來查詢，并使用explain查看查詢計劃。另外在尋找最優(yōu)索引的時候hint命令也是非常有用的。

db.info.find({publishDate:{$gte:20160310,$lte:20160320},isRubbish:{$in:[0,1]},title:{$regex:".*test.*"},$or:[{useId:10},{groupId:20}]}).explain("executionStats");

6. 寫操作頻繁無法使用讀寫分離

由于系統(tǒng)寫操作較多，造成各種w級別鎖經(jīng)常出現(xiàn)（這種鎖一般是block read的）而且系統(tǒng)對于數(shù)據(jù)一致性要求不會太多（大多是后臺寫入，前臺讀取，因此允許有一定延遲）所以想用副本集來做讀寫分離。當真正測試后發(fā)現(xiàn)副本集上的讀取也經(jīng)常出現(xiàn)阻塞的情況。通過db.currentOp()發(fā)現(xiàn)經(jīng)常出現(xiàn)一個op:none的操作在申請global write lock，這時所有操作的狀態(tài)都是在waitingForLock:true，這個問題google了很久都沒找到解決方法。后面在官方文檔有關并發(fā)的FAQ中發(fā)現(xiàn)下面這個大坑：

How does concurrency affect secondaries?

In replication, MongoDB does not apply writes serially to secondaries.
Secondaries collect oplog entries in batches and then apply those
batches in parallel. Secondaries do not allow reads while applying the
write operations, and apply write operations in the order that they
appear in the oplog.

原來mongodb的副本在復制主節(jié)點數(shù)據(jù)執(zhí)行oplog的時候，讀取是被阻塞的，這基本宣告無法在副本上去讀取數(shù)據(jù)了，白白耗費了幾天精力。所以mongo官方不推薦做讀寫分離，原來坑是在這里。。。其實寫多讀少的情況做讀寫分離作用也不大，因為性能瓶頸主要是在寫入，讀取一般不消耗多少資源（另外wiredTiger引擎的鎖做到了doc級別，所以鎖的情況相對較少）。官方推薦的做法是shard，可以有效的將寫入分配到多臺服務器提高寫入速度，使系統(tǒng)實現(xiàn)水平擴容。

7、千萬不要讓磁盤滿了

80%的時候就要開始注意從集拆分片，如果你的數(shù)據(jù)增長特別快，很可能你還沒有拆分磁盤就滿了導致MongoDB掛掉了。如果數(shù)據(jù)量很大，盡量使用分片，不要使用副本集，做好磁盤容量規(guī)劃，就是使用分片了也提前擴容，畢竟chunk遷移還是那么的慢。

8、安全風險

MongoDB是默認不提示用戶設置密碼的，所以，如果你沒有配置密碼又把MongoDB放在公網(wǎng)上面了，那么「恭喜」，你可能已經(jīng)成為了肉雞

9、數(shù)據(jù)庫級鎖

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

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

•MongoDB 沒有完整事務支持，操作原子性只到單個 document 級別，所以通常操作粒度比較?。?/p>

•MongoDB 鎖實際占用時間是內(nèi)存數(shù)據(jù)計算和變更時間，通常很快；

•MongoDB 鎖有一種臨時放棄機制，當出現(xiàn)需要等待慢速 IO 讀寫數(shù)據(jù)時，可以先臨時放棄，等 IO 完成之后再重新獲取鎖。

通常不出問題不等于沒有問題，如果數(shù)據(jù)操作不當，依然會導致長時間占用寫鎖，比如下面提到的前臺建索引操作，當出現(xiàn)這種情況的時候，整個數(shù)據(jù)庫就處于完全阻塞狀態(tài)，無法進行任何讀寫操作，情況十分嚴重。

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