数据库选型之亿级数据量并发访问（MySQL集群）

男娘i 2022-08-09 09:42 169阅读 0赞

#### 简介 ####

针对实际应用中并发访问MySQL的场景，本文采用多线程对MySQL进行并发读取访问，其中以返回用户所需的数据并显示在终端为测试结束节点，即将数据从MySQL集群读取后存储于客户端本地内存中。测试过程如下：分别针对4种应用场景，从10、20、50、100个线程对MySQL展开测试。测试结果表明：对场景1）一般的并发访问能够满足需求；对于场景2）和3）响应时间在分钟级，分别处于1-3分钟和10分钟左右；对于场景4）则经常会抛出异常，并且以异常点为基准，其响应时间在30分钟左右。

#### 测试环境 ####

硬件环境：

Localhost：CPU： Intel Core I5, 主频：3.10G,  内存：4G

MySQL集群：9台服务器

软件环境：

Localhost: Win7，jdk 1.8

MySQL集群： MySQL5.6.25（社区版）

数据规模：

数据条目：一个月的股票数据，2亿4千万余条记录，表结构为50个字段左右，具体内容见下面表结构。

表结构：

1 DROP TABLE IF EXISTS `TAQ_201504`; 2 CREATE TABLE `TAQ_201504` ( 3   `SECCODE` varchar(6) NOT NULL, 4   `SECNAME` varchar(20) NOT NULL, 5   `TDATE` varchar(10) NOT NULL, 6   `TTIME` varchar(6) NOT NULL, 7   `LASTCLOSE` decimal(19,3) DEFAULT NULL, 8   `OP` decimal(19,3) DEFAULT NULL, 9   `CP` decimal(19,3) DEFAULT NULL, 10   `TQ` decimal(19,3) DEFAULT NULL, 11   `TM` decimal(19,3) DEFAULT NULL, 12   `TT` decimal(18,0) DEFAULT NULL, 13   `CQ` decimal(18,0) DEFAULT NULL, 14   `CM` decimal(19,3) DEFAULT NULL, 15   `CT` decimal(19,3) DEFAULT NULL, 16   `HIP` decimal(19,3) DEFAULT NULL, 17   `LOP` decimal(19,3) DEFAULT NULL, 18   `SYL1` decimal(19,3) DEFAULT NULL, 19   `SYL2` decimal(19,3) DEFAULT NULL, 20   `RF1` decimal(19,3) DEFAULT NULL, 21   `RF2` decimal(19,3) DEFAULT NULL, 22   `BS` varchar(18) DEFAULT NULL, 23   `S5` decimal(19,3) DEFAULT NULL, 24   `S4` decimal(19,3) DEFAULT NULL, 25   `S3` decimal(19,3) DEFAULT NULL, 26   `S2` decimal(19,3) DEFAULT NULL, 27   `S1` decimal(19,3) DEFAULT NULL, 28   `B1` decimal(19,3) DEFAULT NULL, 29   `B2` decimal(19,3) DEFAULT NULL, 30   `B3` decimal(19,3) DEFAULT NULL, 31   `B4` decimal(19,3) DEFAULT NULL, 32   `B5` decimal(19,3) DEFAULT NULL, 33   `SV5` decimal(20,0) DEFAULT NULL, 34   `SV4` decimal(20,0) DEFAULT NULL, 35   `SV3` decimal(15,0) DEFAULT NULL, 36   `SV2` decimal(15,0) DEFAULT NULL, 37   `SV1` decimal(15,0) DEFAULT NULL, 38   `BV1` decimal(15,0) DEFAULT NULL, 39   `BV2` decimal(15,0) DEFAULT NULL, 40   `BV3` decimal(15,0) DEFAULT NULL, 41   `BV4` decimal(15,0) DEFAULT NULL, 42   `BV5` decimal(15,0) DEFAULT NULL, 43   `BSRATIO` decimal(19,3) DEFAULT NULL, 44   `SPD` decimal(19,3) DEFAULT NULL, 45   `RPD` decimal(19,3) DEFAULT NULL, 46   `DEPTH1` decimal(20,3) DEFAULT NULL, 47   `DEPTH2` decimal(20,3) DEFAULT NULL, 48   `UNIX` bigint(20) DEFAULT NULL, 49   `MARKET` varchar(4) DEFAULT NULL, 50   KEY `SECCODE` (`SECCODE`,`TDATE`,`TTIME`) 51 ) /*!50100 TABLESPACE ts_cloudstore STORAGE DISK */ ENGINE=ndbcluster DEFAULT CHARSET=utf8;

备注：\`SECCODE\`,\`TDATE\`,\`TTIME\`为组合索引，存于内存中。

#### 性能测试 ####

本文针对4中应用场景展开测试，分别从10、20、50、100个线程对MySQL展开测试。

1） 场景1

对某天的业务进行访问查询，即多个线程交互访问如下示例：

select CP from TAQ\_201504 where SECCODE='000001' AND TDATE = '20150401';

select CP from TAQ\_201504 where SECCODE='000002' AND TDATE = '20150401';

select CP from TAQ\_201504 where SECCODE='000003' AND TDATE = '20150401';

select CP from TAQ\_201504 where SECCODE='000004' AND TDATE = '20150401';

select CP from TAQ\_201504 where SECCODE='000005' AND TDATE = '20150401';

即每5个线程各自执行其中一条查询，以10个线程举例，则各自有2个线程会执行其中1条语句，其它线程与之类同，不再赘述。测试结果见表-1。

![image][]

表-1结果表明：对于20-50个线程并发的场景下，按天查询1-3个字段，数据响应时间大概在3s 以内。然而，在大量并发（100个线程）的场景下，数据显示所需时间明显增大。需要指出，虽然该测试能够反映一些问题，但是增大多线程间切换所需的时间也是造成该时延增大的原因。

2) 场景2

对某个字段所处范围，批量返回查询结果，即多个线程并发访问如下示例：

select CP from TAQ\_201504  where SECCODE in ('000005','600010','000001','600100','600180','000002','000007','000008')

测试结果见表-2。

[![image][image 1]][image_image 1]

表-2结果表明：测试所需时间都已达到分钟级。此外，对于表中异常情形，其症结在于，在单台机器上采用多线程测试，因此受限于本文测试的机器的存储空间。本文作者认为，并非已达到MySQL数据库的极限。

3）场景3

指定具体某一个字段，对全表进行查询，即多线程并发访问如下示例：

select cp from TAQ\_201504 where ttime='145910'

测试结果见表-3。需要指出，本文未对50、100个线程展开测试，只是因为其耗时过长，故此，并未展开测试。

[![image][image 2]][image_image 2]

表-3结果表明：随着字段个数增加，其处理耗时也逐渐增加，而且已达到分钟级，而且基本达到10分钟以上。

4）场景4

指定具体某些字段，对全表进行查询，即多线程并发访问如下示例：

select cp from TAQ\_201504 where tdate='20150409' and  ttime='145910'

测试结果见表-4。

[![image][image 3]][image_image 3]

从表-4可知：在查询中指定多个字段会增加查询所需的时间。需要指出，由于上述SQL语句在查询时，扫描数据库花费的时间较多，导致Got error 4008 'Receive from NDB failed' from NDBCLUSTER，因此，表-4红色部分，由于异常过早抛出，因此，在统计时间时存在偏差。本文作者认为，由于每次查询差不多花费半个小时，造成数据访问超时，很大程度上造成上述异常，此外，在单台机器上并发访问该数据库，线程间切换的时间也会对其造成一定的影响。

#### 总结 ####

从上述4中场景测试结果来看，对于查询返回数据量相对较少时，多线程访问MySQL是能够满足用户需求的；当访问数据量较大时，多线程访问时能够满足连接需求的，但是具体向用户进行展示时，其处理时间多在分钟级，返回的字段、数据量越多，所耗的时间也逐渐增多。

[image]: /images/20220731/786c0e6724324191bddeeb62723ba184.png
[image 1]: http://images2015.cnblogs.com/blog/798916/201510/798916-20151018104317929-1537618792.png
[image_image 1]: /images/20220731/dc74c533fb9c48d4ace729ba93b65166.png
[image 2]: http://images2015.cnblogs.com/blog/798916/201510/798916-20151018104319038-80502363.png
[image_image 2]: /images/20220731/83c443f4bd4b4bea9090df3b8f23d995.png
[image 3]: http://images2015.cnblogs.com/blog/798916/201510/798916-20151018104319741-549237534.png
[image_image 3]: /images/20220731/2e3427c95d18429b86695e14960a041b.png