測試目標：mongodb gridfs

1 海量小檔案（1K－50K）的插入速度測試

2 億級檔案儲存的讀取速度測試

3 瞭解mongodb擴充套件對儲存容量、讀寫速度的影響

4 mongodb的穩定性和缺陷

測試一：單節點測試（4核 ＊ 32G記憶體）官方Client

每秒插入速度：8000條（4000個1K檔案）

單節點儲存1億個檔案後，硬碟寫滿了

測試二：shard叢集測試一，每個Replica Set中member數量為3，總共2個叢集 自己重寫Client

shard1: dxud3c006 + dxud3c007 + dxud3c008

shard2: dxud3c009 + dxud3c010 + dxud3c011

config server:  dxud3c006 + dxud3c009 + dxud3c005

mongos: dxud3c005(4個）

每秒插入速度：3500條（1750個1K檔案）

平均每個shard插入速度：1500－2000條（750－1000個1K檔案）

測試三：shard叢集測試二，每個Replica Set中member數量為2，總共3個叢集 自己重寫Client

shard1: dxud3c006 + dxud3c007 

shard2: dxud3c008 + dxud3c009

shard3: dxud3c010 + dxud3c011

config server:  dxud3c006 + dxud3c008 + dxud3c010

mongos: dxud3c005(4個）

每秒插入速度：6000條（2000個1K檔案）

平均每個shard插入速度：1800－2300條（900－1150個1K檔案）

說明：

1 官方的java－client中沒有對shard叢集模式做任何優化

2 針對本專案的場景（按ID存取檔案）對java－client進行優化：

    a 建立collection（files，chunks）時，指定使用_id作為files的shard key，使用files_id作為chunks的shard key

    b 建立files的collection時，使用自己生成的uuid作為_id，以避免插入時，壓力集中在一個shard

    c 建立collection（files，chunks）後，手動建立15個chunks，min～1,1～2,2～3......f～max，並且手動將chunks移動到不同的shard上面去

    d 由於專案的性質問題，對資料的完整性和一致性要求很高，導致insert時指定使用REPLICAS_SAFE模式

測試過程中發現的問題：

1 mongodb的叢集模式感覺不是很穩定，常出現RS102的問題：指primary節點與secondary節點同步差距過大，而導致secondary節點變為不可用狀態。需要手動將primary的資料檔案到secondary上（當資料檔案很大時，非常慢非常慢）

2 mongodb在插入時的速度不是很穩定，經常會出現3－5秒沒有插入一條資料的情況

讀取速度的測試稍後放出

轉載：http://my.oschina.net/timtech/blog/38521