使用YCSB测试mongodb分片集群性能

为什么80%的码农都做不了架构师？>>>   

1. 测试工具

    本次测试选取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%访问请求），最新数据。

2. 测试步骤

    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. 测试系统架构

    集群配置服务器的3个实例部署在configs服务器上，YCSB，mongos实例，shard1，shard2各自部署在一台服务器。shard1和shard2都是单独的mongodb instance，不是replicate set。mongodb 使用2.6版本。

4. 服务器的配置

	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

5. 测试结果

    表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

6. 测试结果分析

    图1，一个分片时各个场景下吞吐量随记录量的变化曲线。

    图2，两个分片时各个场景下吞吐量随记录量的变化曲线。

    图3，重写场景(workloada) 不同分片数量的吞吐量随记录量的变化曲线。

    图4，重读场景(workloadb) 不同分片数量的吞吐量随记录量的变化曲线。

图1

图2

图3

图4

    由图1，workloada可以看出，mongodb的写性能率先达到瓶颈，随着记录数量增加，下降很快，而读取的性能变化很小。

    由图3和图4，可以看出，当mongodb遇到写瓶颈时，增加分片，大大增加写性能，少量增加读性能。

    可能由于数据量，或者YCSB的瓶颈，测试中mongodb读性能未出现瓶颈。

7.结论

    1.Mongodb的读性能很高，适合重读的场景。

    2.通过增加分片，可以大大增加mongodb集群的写性能， 部分增加读性能。

    3.与关系型数据库相比，mongodb 的优势

• • 文档型数据库，json风格的文件存储，结构清晰，无需ORM。

  • 复制和高可用性，易于扩展。

  • 自动分片

  • 使用基于文档的查询语言，有一定的查询能力。

  • 任何属性可索引。

    所以对于不太复杂的查询场景下，mongodb可以很方便的作为mysql的替代方案，提高db的读写能力。对于大数据场景，内容管理和交付平台，用户数据管理中心，日志平台等都适合使用mongodb。

转载于:https://my.oschina.net/mxs/blog/529452