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

1. 系統參數及mongo參數設置

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

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

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

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

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

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

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

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 + "索引創建成功");    }  }  return infos;}());

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

3. 使用Capped Collection

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

4. 生產環境一定要用副本集

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

5. 學會使用explain

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

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

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

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

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

7、千萬不要讓磁盤滿了

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

8、安全風險

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

9、數據庫級鎖

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

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

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

•MongoDB 鎖實際占用時間是內存數據計算和變更時間，通常很快；

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

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

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