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秒没有插入一条数据的状况

读取速度的测试稍后放出