一直想知道mongodb的效能如何，今天對壓測結果做了下總結

資料：每條記錄約208 Byte，僅壓測update操作(存在就修改，不存在則插入)。

配置1：單機的mongodb，單表記錄數6百萬左右。

1.啟用journal約6500 qps, 每隔60秒有一次抖動，因為配置成60秒將記憶體資料落盤一次，落盤期間磁碟的tps會大增，約700，其他時刻僅50左右的tps。

2.不啟用journal穩定在7000qps。沒有抖動。磁碟的tps和情況1一樣，只是未開啟journal，即使落盤也不影響效能。

3.同一臺機器啟動兩個不相干的mongodb服務，都啟用journal，分別由兩個client寫入資料。初始時總寫入qps有2*6000左右，

一段時間後會降到6000左右，服務A的qps約2000，服務B的qps約4000。關閉服務B的壓力，服務A的qps能上升到6000。

因此可以推測一臺機器上，開啟journal時只能維持6000左右的寫入qps。

配置2：

一個sharding， 一主兩從部署在不同的機器上，單表記錄數8百萬左右。

1.    主庫從庫都開啟journal，當單表8百萬記錄時，update操作約5000qps，比單機效能略低，可能是主從同步的原因。和單機一樣每隔60秒落盤會有一次抖動。

2.    主庫關閉journal，從庫關閉journal，update操作穩定在6500qps。

3.    在機器A上同時部署兩個sharding的從庫，兩個sharding的主庫分別部署在機器B和機器C，都開啟journal，這兩個sharding的總寫入量約1萬qps。一段時間後，發現這臺從庫跟不上主庫的寫入速度，差了1000多秒，如圖1：

圖1. 從庫落後主庫的時間

配置3：

4個sharding，每個一主兩從，由於機器有限，12個數據混布在四臺機器上，壓測一段時間後，寫入qps只能達到3000左右，原因：

1.    由於一臺機器混布了3個數據節點，承受了3倍的壓力。

2.      Mongodb的auto sharding將資料劃分不均勻，壓力主要落在兩個sharding上。每個sharding的記錄數嚴重不均勻：

總結：

在不混布的情況下，單個sharding資料節點能承受5000qps左右update操作(先查詢再寫入)，由於autosharding不均勻可以考慮採用pre-sharding的方式。