2019独角兽企业重金招聘Python工程师标准>>> 
测试目标：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秒没有插入一条数据的情况
读取速度的测试稍后放出