mongodb亿级文件存储方案测试：报错

测试目标：mongodb gridfs version：2.0.2

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

读取速度的测试稍后放出