MongoDB V3 & V2 版本鎖效能對比測試及鎖的基本概況，mongodbv3

MongoDB V3 & V2 版本鎖效能對比測試及鎖的基本概況，mongodbv3
1.mongo鎖概況：

各版本鎖的特性：

目前的版本 生產版本最高是 2.6.7[Production Release (2.6.7)]  開發版本是 3.0.0-rc7[Development Releases (unstable)3.0.0] Version < 2.2 : 只支援進程級鎖，一個Mongod執行個體一個鎖。2.8 >Version >= 2.2 : 支援庫級鎖，一個db一把鎖。目前3.0.0 支援 collection 層級的鎖。

ps:Mysql的innoDB和Oracle是支援行鎖的。目Production Release的最高版本是2.6.7，即只支援庫級鎖，當一個MongoDB處於寫狀態時，其他的操作都得乾等。mongo雖然擁有庫鎖，但是還能保持高效能的原因是它在如下幾個層面做了讓步或者叫最佳化：

（1）Mongo沒有完整的事物支援，原子操作僅僅到document層級，粒度比較小。<br>（2）Mongo鎖實際的佔用時間是記憶體資料計算和變更時間，通常很快。<br>（3）Mongo鎖有一種臨時放棄機制，當出現需要等待慢速IO讀寫資料時，可以先臨時放棄，等IO完成之後重新擷取鎖。<br>

而目前的2.8版本已經將鎖的粒度降低到了collection基本，官網的說法是：

MongoDB 2.8版本的最重要的特性應該就是對WiredTiger的支援，從而實現對文檔級鎖的支援。在過去使用MongoDB時，自己就遇到了缺少文檔級鎖的問題。每次進行寫入操作時，必須等待寫操作的一個反饋，整個資料庫層級的鎖給寫入操作帶來了很大的延遲。這次能帶來穩定層級的鎖特性，真是令人興奮。

官方鎖相關的介紹：http://docs.mongodb.org/manual/faq/concurrency/

2.針對庫鎖的最佳化策略（使用方式）：

（1）索引的構建變成後台操作：
當有大規模的資料需要構建索引時，如果在前台構建會建立一個（最佳化策略：不會臨時放棄）的寫鎖，如果集合的資料量很大，建索引通常會很耗時。最佳化手段，將建索引的動作有前台切換到後台。

example:    前台索引：db.trends.ensureIndex({user_id:1})    後台索引：db.trends.ensureIndex({user_id:1},{background:1})

（2）鎖的效能測試：
a. mongo 2.6 和 mongo 3.0 針對並發寫入同一個DB的2個不同集合的效能對比（主要測試mongoV3.0 針對collection鎖的支援）:
情境：為了測試mongoV3.0 針對collection層級鎖的效能的提升，在我們的daily機器上，開了兩個針對同一個DB但不同collection的寫線程各20個，每個線程一直進行寫操作，得出的qps分析結果如下：

結果分析： mongo2.6.4版本是db層級的鎖，針對同一個庫中的兩個不同集合也會存在鎖的競爭，而mongo3.0.0是collection層級的鎖，所以從理論和測試結果上看，其效能確實有提升。

b. MongoV2.6.4 隨著鎖衝突的變化，其讀寫輸送量的變化趨勢：
情境：這個是在我自己的開發機上進行測試的，開了10條並發的讀寫線程進行測試，橫座標代表：鎖的比率（鎖等待時間/讀寫事務完成的時間） 

結果分析： 從結果看能反應出隨著鎖等待比率的升高，整體輸送量有下降的趨勢。

c. MongoV2.6.4 測試DB的前台索引、後台索引、以及不加索引的情況下的效能對比效果：
情境：MongoDB分為前台索引、後台索引、以及不加索引，前台索引會和讀寫事務產生嚴重的衝突，而後台索引進行了最佳化，當後台索引耗時較長的時候會讓出鎖給讀寫事務。不加索引則讀事務耗時很長，寫事務耗時較短。如下： 

結果分析：在不加索引的情況下讀事務qps很低，可以理解為，讀取資料在無索引情況下耗時較長，且寫事務一直搶佔著寫鎖，導致讀事務饑餓等待。

3.鎖對副本模式（replica)和sharding模式的影響：

（1）sharding模式：在讀寫鎖方面，每個Mongod執行個體是和其他執行個體相互獨立。在一個Mongod上的操作不會阻塞其他mongod執行個體的操作。
（2）replica模式：在對Primary結點進行寫操作的時候，同時還會向 Primary's OpLog寫入，此時需要鎖定2個庫，一個是當前寫入collection所在的庫，另外一個是OpLog所在的 local 庫。即 Primary會在這兩個庫上添加寫鎖。另外，Secondary結點會同步Primary結點的OpLog，將Oplog順序批量並發的在自己的結點上執行，此時為寫操作，在該寫操作執行的過程中，Secondary也是不能提供讀操作的。