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

刘 勇  Email:[email protected]

简介

针对实际应用中并发访问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;

Table TAQ_201504

  备注:`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。

表-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。

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

3)场景3

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

select cp from TAQ_201504 where ttime=‘145910‘

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

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

4)场景4

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

select cp from TAQ_201504 where tdate=‘20150409‘ and  ttime=‘145910‘

测试结果见表-4。

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

总结

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

  



  作者:志青云集
  出处:http://www.cnblogs.com/lyssym
  如果,您认为阅读这篇博客让您有些收获,不妨点击一下右下角的【推荐】。
  如果,您希望更容易地发现我的新博客,不妨点击一下左下角的【关注我】。
  如果,您对我的博客所讲述的内容有兴趣,请继续关注我的后续博客,我是【志青云集】。
  本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接。



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

时间: 2024-10-14 23:33:11

数据库选型之亿级数据量并发访问(MySQL集群)的相关文章

【转】Mongodb亿级数据量的性能测试

进行了一下Mongodb亿级数据量的性能测试,分别测试如下几个项目: (所有插入都是单线程进行,所有读取都是多线程进行) 1) 普通插入性能 (插入的数据每条大约在1KB左右) 2) 批量插入性能 (使用的是官方C#客户端的InsertBatch),这个测的是批量插入性能能有多少提高 3) 安全插入功能 (确保插入成功,使用的是SafeMode.True开关),这个测的是安全插入性能会差多少 4) 查询一个索引后的数字列,返回10条记录(也就是10KB)的性能,这个测的是索引查询的性能 5) 查

Mongodb亿级数据量的性能测试

Mongodb亿级数据量的性能测试 ——转载 进行了一下Mongodb亿级数据量的性能测试,分别测试如下几个项目: (所有插入都是单线程进行,所有读取都是多线程进行) 1) 普通插入性能 (插入的数据每条大约在1KB左右) 2) 批量插入性能 (使用的是官方C#客户端的InsertBatch),这个测的是批量插入性能能有多少提高 3) 安全插入功能 (确保插入成功,使用的是SafeMode.True开关),这个测的是安全插入性能会差多少 4) 查询一个索引后的数字列,返回10条记录(也就是10K

MySQL集群数据库表的主键设计

使用MySQL数据库的人,毫无例外的在设计时都会碰到主键的选型,一般都会在下面三种中选择一个或多个,自增长列.UUID以及UUID_SHORT,这集中主键的特性,想必大家都非常了解了,我就不再细说了,在InnoDB引擎中,选择哪种主键更好,网上也有很多帖子有描述,基本上都是建议是自增长列或者搭配UUID作为逻辑主键一起使用,但是如果是ndbcluster引擎呢? 为此我专门做了一下测试,环境为4台物流机器(2C,8G内存)做的数据节点,NoOfReplicas=2,首先建立三张表. CREATE

Mysql集群讲解(三)Mysql多实例(多个数据库)搭建

Mysql集群讲解(三) Mysql多实例(多个数据库)搭建 多实例概述: MySQL多实例是指安装MySQL之后,我们可以在一台Linux服务器上同时启动多个MySQL数据库(实例),不需要安装多个MySQL: 如果是有多台Linux服务器,那么我们需要每台服务器都分别安装MySQL: 在一台Linux服务器上启动多个MySQL数据库(实例),通过为各个数据库实例配置独立的配置文件来实现,即每个数据库实例有自己单独的配置文件: 多实例配置: 1. 在MySQL安装主目录下创建/data/330

高并发访问mysql时的问题(一):库存超减

如果在对某行记录的更新时不采取任何防范措施,在多线程访问时,就容易出现库存为负数的错误. 以下用php.mysql,apache ab工具举例说明: mysql表结构 CREATE TABLE `yxt_test_concurrence` ( `id` int(11) NOT NULL AUTO_INCREMENT, `value` int(11) NOT NULL COMMENT '库存', PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=2

2017最新技术java高级架构、千万高并发、分布式集群、架构师入门到精通视频教程

* { font-family: "Microsoft YaHei" !important } h1 { color: #FF0 } 15套java架构师.集群.高可用.高可扩 展.高性能.高并发.性能优化.Spring boot.Redis.ActiveMQ.Nginx.Mycat.Netty.Jvm大型分布 式项目实战视频教程 视频课程包含: 高级Java架构师包含:Spring boot.Spring  cloud.Dubbo.Redis.ActiveMQ.Nginx.Mycat

数据库优化 | 亿级数据量系统数据库性能优化方案

一.数据库性能瓶颈主要原因 1.数据库连接 MySQL数据库默认连接为100,我们可以通过配置initialSize.minIdle.maxActive等进行调优,但由于硬件资源的限制,数据库连接不可能无限制的增加,对大型单体应用单实例数据库可能会出现最大连接数不能满足实际需求的情况,这时就会系统业务阻塞. 2.表数据量大(空间存储问题) 普遍观点认为单表数据量超过1000万条时就是出现数据库读取性能瓶颈.从索引角度分析,如果索引未被命中,数据库系统就会全表扫描,数据量越大,扫描全表的时间就会越

财务平台亿级数据量毫秒级查询优化之elasticsearch原理解析(转)

https://blog.csdn.net/wang123459/article/details/81045416 财务平台进行分录分表以后,随着数据量的日渐递增,业务人员对账务数据的实时分析响应时间越来越长,体验性慢慢下降,之前我们基于mysql的性能优化做了一遍,可以说基于mysql该做的优化已经基本上都做了,本次是基于elasticsearch对其做进一步的性能优化 正文 1mysql索引原理 基于mysql最常用也最直接有效的性能优化也就是添加索引. mysql索引是怎么实现的呢?数据库

SQL优化(SQL TUNING)之10分钟完毕亿级数据量性能优化(SQL调优)

前几天.一个用户研发QQ找我,例如以下: 自由的海豚. 16:12:01 岛主,我的一条SQL查不出来结果,能帮我看看不? 兰花岛主 16:12:10 多久不出结果? 自由的海豚 16:12:17 多久都没出结果,一直没看到结果过. 兰花岛主 16:12:26 呵呵.好. 兰花岛主 16:12:39 发下sql和运行计划. 自由的海豚 16:12:55 select n.c1, n.c2,n.c3,n.c4,n.c5 from (select  count(t.c1), t.c1, t.c2,t