标签:文件存储 关系 部分 read 优势 bsp 日志 core 工具
本次测试选取YCSB(Yahoo! Cloud System Benchmark)作为测试客户端工具。YCSB是Yahoo开源的一个nosql测试工具,用来测试比较各种nosql的性能,项目地址:https://github.com/brianfrankcooper/YCSB。项目的mongodb目录下有详细的安装和测试方法。
YCSB支持常见的nosql数据库读写,如插入,修改,删除,读取等。它可以使用多线程来提高客户端的性能。可以方便的自定义各种场景,如95%插入5%读,或者90%读5%更新5%插入等等。可以自定义数据请求分布方式:平均分布,zipfian(大约20%数据获得80%访问请求),最新数据。
1. 选择客户端线程数。使用YCSB测试,要选择一个合适的线程数,否则测试的瓶颈可能在客户端而不是数据库,经过比较,大概100个线程时,YCSB达到最大性能。
2.定义测试场景。本次测试的场景如下:
workloada | 写多读少,90%插入,5%读,5%更新。 |
workloadb | 读多写少,95%读,5%更新。 |
workloadc | 读多写少,100%读。 |
workloadd | 读多写少,95%读,5%插入。 |
workloadf | 读多写少,50%读,50%读写修改同一条记录。 |
workloadg | 读多写少,60%读,20%读,20%更新。 |
3.测试不同数量记录下的各种场景。分成两个阶段:
1),load。加载数据。命令为:
./bin/ycsb load mongodb -threads 100 -s -P workloads/workloada -p mongodb.url=mongodb://mongos:28000/ycsb?w=0 > outputLoad.txt
执行load 命令时,仅有recordcount参数起作用,如recordcount=60000000表示加载六千万条记录。执行run命令时,recordcount不起作用。mongos是集群中mongos实例的ip地址。
2),run。load数据完成后,各种场景运行测试。
测试场景workloada,位于workloads目录下:
./bin/ycsb run mongodb -threads 100 -s -P workloads/workloada -p mongodb.url=mongodb://mongos:28000/ycsb?w=0 > outputRun.txt
每次load数据前要把上次测试中产生的数据删除,包括各个分片,配置服务器,mongos等的数据。
集群配置服务器的3个实例部署在configs服务器上,YCSB,mongos实例,shard1,shard2各自部署在一台服务器。shard1和shard2都是单独的mongodb instance,不是replicate set。mongodb 使用2.6版本。
OS | CPU | RAM | |
YCSB | ubuntu14.04 | Intel(R) Core(TM) i5-4440 CPU @ 3.10GHz 4核 | 1G |
mongos | Red Hat 4.4 | Intel(R) Xeon(R) CPU E5645 @ 2.40GHz 1核 | 8G |
shards | Red Hat 4.4 | Intel(R) Xeon(R) CPU E5645 @ 2.40GHz 1核 | 16G |
configs | ubuntu14.04 | Intel(R) Core(TM) i5-4440 CPU@3.10GHz 1核 | 1G |
表1, 一个分片,1百万,1千万,6千万,1亿记录时各个场景的吞吐量(ops/sec)。
表2,两个分片,1百万,1千万,6千万记录时各个场景的吞吐量(ops/sec)。
数据量(百万) | workloada | workloadb | workloadc | workloadd | workloadf | workloadg |
1 | 4878 | 7352 | 7536 | 7885 | 2131 | 5986 |
10 | 4343 | 7282 | 7442 | 6996 | 2164 | 6119 |
60 | 1669 | 7242 | 7847 | 7810 | 2577 | 6054 |
100 | 157 | 7333 | 6796 | 7766 | 2082 | 4389 |
表1
数据量(百万) | workloada | workloadb | workloadc | workloadd | workloadf | workloadg |
1 | 6462 | 7416 | 7518 | 7633 | 2622 | 6777 |
10 | 5826 | 8198 | 7664 | 8073 | 2093 | 7376 |
60 | 5662 | 7707 | 7546 | 7716 | 2181 | 6540 |
表2
图1,一个分片时各个场景下吞吐量随记录量的变化曲线。
图2,两个分片时各个场景下吞吐量随记录量的变化曲线。
图3,重写场景(workloada) 不同分片数量的吞吐量随记录量的变化曲线。
图4,重读场景(workloadb) 不同分片数量的吞吐量随记录量的变化曲线。
图1
图2
图3
图4
由图1,workloada可以看出,mongodb的写性能率先达到瓶颈,随着记录数量增加,下降很快,而读取的性能变化很小。
由图3和图4,可以看出,当mongodb遇到写瓶颈时,增加分片,大大增加写性能,少量增加读性能。
可能由于数据量,或者YCSB的瓶颈,测试中mongodb读性能未出现瓶颈。
1.Mongodb的读性能很高,适合重读的场景。
2.通过增加分片,可以大大增加mongodb集群的写性能, 部分增加读性能。
3.与关系型数据库相比,mongodb 的优势
文档型数据库,json风格的文件存储,结构清晰,无需ORM。
复制和高可用性,易于扩展。
自动分片
使用基于文档的查询语言,有一定的查询能力。
任何属性可索引。
所以对于不太复杂的查询场景下,mongodb可以很方便的作为mysql的替代方案,提高db的读写能力。对于大数据场景,内容管理和交付平台,用户数据管理中心,日志平台等都适合使用mongodb。
标签:文件存储 关系 部分 read 优势 bsp 日志 core 工具
原文地址:http://www.cnblogs.com/wuhl-89/p/6846238.html