mysql cluster 测试_MySql Cluster 测试结果

安装步骤->安装步骤

查看错误->错误集锦

节点作用->节点作用

测试结果->测试结果

性能测试

测试环境搭建:

Mysql Cluster 管理节点1个，Sql节点2个，数据节点2个。搭建过程见安装步骤。这里不再赘述。

测试表准备:

CREATE DATABASE IF NOT EXISTS testdb;

DROP TABLE IF EXISTS student;

CREATE TABLE IF NOT EXISTS student (

UUID VARCHAR(50) NOT NULL,

name VARCHAR(25) NOT NULL,

age INT(3) NOT NULL,

gentle INT(1) NOT NULL,

province VARCHAR(5) NOT NULL,

post_code VARCHAR(10) NOT NULL,

school_code VARCHAR(2) NOT NULL,

school_level VARCHAR(8) NOT NULL,

class VARCHAR(10) NOT NULL,

create_ts TIMESTAMP NOT NULL DEFAULT now()，

PRIMARY KEY (UUID),

INDEX (create_ts)

)

ENGINE = NDBCLUSTER;

DROP TABLE IF EXISTS `order`;

CREATE TABLE IF NOT EXISTS `order` (

UUID VARCHAR(50) NOT NULL,

stu_uuid VARCHAR(50) NOT NULL,

is_pay BOOLEAN NOT NULL,

money BIGINT NOT NULL,

create_ts TIMESTAMP NOT NULL DEFAULT now(),

PRIMARY KEY (UUID),

INDEX (create_ts)

)

ENGINE = NDBCLUSTER;

测试过程及详情:

我们安装jemeter测试工具，用于发送请求。并且用二维折线图来展示测试关系。先测试单节点情况。

SQL插入测试:

INSERT INTO testdb。student (UUID,name,age,gentle,province,post_code, school_code,school_level, class,create_ts) VALUES (UUID(),'zs',77,1,'JX', '400000','21','middle','A99','2018-05-22 11:35:33');

通过测试得到下图：

上图的x轴是jemeter测试工具的并发量，X坐标代表并发量。Y代表时间，或者数量。淡蓝的线代表吞吐量，单位是K，深蓝是代表平均响应时间，单位ms。

根据公式得知，并发数=吞吐量/平均响应时间。在并发数量90的时候也就是，吞吐量在11K的时候，系统的响应时间上涨，但是吞吐量开始下降，这个点可以理解为服务器的瓶颈，也就是说，过了这个点，服务器性能开始下降。那导致服务器性能下降的原因是什么？数据量过大？还是服务器本身的因素。然后，我们做了如下的测试：

上图的蓝线还是原来的线条。但是，黄线的执行顺序是反向的。打个比方:蓝线执行顺序是，10-20-30-40-50......黄线的执行顺序是110-100-90-80.....由图可以看出来，数据库存储的数据量并不是造成SQL性能下降的原因。因为，插入行为反向执行，但是并没有影响平局响应时间的变化。我们再看下面一张：

前面说过，我们的服务器是2核4G的虚拟机，可以明显看到，发送请求的机器，内存和CPU并没有什么太大的变化。然而，SQL节点CPU高达166%(总共200%)，说明CPU这时候已经很繁忙了。

到这里我们可以得到一个结论:插入效率也可以叫事务提交效率，在机器硬件是如下的情况(2核4G，CPU: Intel Core Processor (Broadwell))，最高并发量是100左右。当吞吐量超过11K之后，并发量不仅仅会下降，响应时间也会加长，就是这个机器的性能瓶颈。当我们业务需要更多的机器的时候，我们可以通过增长集群的SQL节点来优化这个问题。理论上，2个SQL节点的效率至少是1个的2倍。

多SQL节点插不测了，由于只有一台物理机器，无法测试出真正的效果，不过理论上应该是2倍效率。

SQL连表查询：

SELECT * from student r1 RIGHT JOIN `order` r2 on r1.UUID = r2.stu_uuid ;

数据量：student， 200W条， order ， 600W条。

下面看图：

如上图所示，并发量增大，平均响应时间(ms)和吞吐量(单位x100)也一起增大。但是在测试的时候，由于并发超过250左右时候，数据库会出现一个错误“'Too many active scans' from NDBCLUSTER”。官网也没有给出解决方法。大概意思就是查询请求过多。修改了最大扫描的参数依旧无效，这个错误还有待解决。我们在选择每个SQL节点分配多少资源的时候，可以根据这种图做出选择，需要快速反应的节点，应该尽量减少并发量，让响应时间保持在100ms以下。由于没有测试到吞吐量和响应时间的交叉点，所以不知道这个服务器瓶颈点在什么位置。不过，由于数据库的特殊性，建议单个服务器不要超过250并发。

总结：经过测试可以得知，插入正常情况下5ms能过响应，连表查询100ms左右，考虑到测试环境机器是虚拟机，这样的速度是正常的。以及网络带宽的原因，mysql cluster的效率受到网络的影响比较大。官网给出的测试是在万兆带宽情况下进行。在不同的机器环境，软件环境下，我们的测试就可能会有很大的差距。不过，测试的目地在于帮助我们在不同的环境下选择搭建数量合适的集群机器。根据这样的效率，我认为mysql cluster可以应用在生产环境，但是需要经过大量测试，保证集群机器之间的带宽。

一些建议：

1.SQL节点CPU越好性能越高。

2.数据节点内存越大越好，如果数据分片的越多，对查询效率会有一定影响。

3.Mysql cluster 集群前，应通过测试决定合适的机器数量。