MongoDB亿级文件存储方案测试
2015-05-30 15:07
357 查看
测试目标: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
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
相关文章推荐
- MongoDB性能测试与Python测试代码
- mongodb分片部署
- 闲谈MongoDb+GridFS+Nginx
- 使用 MongoDB 的兄弟,有没有采用 GridFS 做分布式文件系统的?
- Mongodb配置
- nginx+mongodb-gridfs+squid
- 基于MongoDB GridFS的图片存储
- MongoDB GridFS 数据读取效率 benchmark
- MongoDB文件存取操作
- MongoDB对图片进行CRUD操作——与JAVA结合
- MongoDB学习笔记~批量插入方法的实现
- Mongodb启动配置
- MongoDB服务的启动
- MongoDB内存管理机制
- 阿里云搭建NODEJS+EXPRESS+MONGODB实战
- MongoDB副本集配置系列四:节点的关闭顺序
- mongodb-manual-3.0.0 indexes2
- MongoDB常见错误解决方式
- debian安装 Mongodb
- MongoDB安全配置详解