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

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

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

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

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

2. 無需對(duì)集合進(jìn)行水平切分

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

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

用過的都知道m(xù)ongo對(duì)索引的依賴非常大，如果集合不能一開始就設(shè)計(jì)好，那后續(xù)索引就得寫腳本來創(chuàng)建。這里貢獻(xiàn)個(gè)給mongo大表動(dòng)態(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;
}());

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

3. 使用Capped Collection

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

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

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

5. 學(xué)會(huì)使用explain

之前一直習(xí)慣用工具來查詢，現(xiàn)在發(fā)現(xiàn)應(yīng)該多使用mongo shell命令來查詢，并使用explain查看查詢計(jì)劃。另外在尋找最優(yōu)索引的時(shí)候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í)別鎖經(jīng)常出現(xiàn)（這種鎖一般是block read的）而且系統(tǒng)對(duì)于數(shù)據(jù)一致性要求不會(huì)太多（大多是后臺(tái)寫入，前臺(tái)讀取，因此允許有一定延遲）所以想用副本集來做讀寫分離。當(dāng)真正測試后發(fā)現(xiàn)副本集上的讀取也經(jīng)常出現(xiàn)阻塞的情況。通過db.currentOp()發(fā)現(xiàn)經(jīng)常出現(xiàn)一個(gè)op:none的操作在申請(qǐng)global write lock，這時(shí)所有操作的狀態(tài)都是在waitingForLock:true，這個(gè)問題google了很久都沒找到解決方法。后面在官方文檔有關(guān)并發(fā)的FAQ中發(fā)現(xiàn)下面這個(gè)大坑：

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

7、千萬不要讓磁盤滿了

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

8、安全風(fēng)險(xiǎn)

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

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

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

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

•MongoDB 沒有完整事務(wù)支持，操作原子性只到單個(gè) document 級(jí)別，所以通常操作粒度比較小；

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

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

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

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