MongoDB億級文件存儲方案測試

測試目標：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秒沒有插入一條數據的狀況

讀取速度的測試稍後放出