數據庫選型之億級數據量並發訪問（MySQL集群）

劉 勇  Email：[e-mail]

簡介

        針對實際應用中並發訪問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個字段左右，具體內容見下面表結構。

表結構：

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。

        表-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
　　如果，您認為閱讀這篇博客讓您有些收獲，不妨點擊一下右下角的【推薦】。
　　如果，您希望更容易地發現我的新博客，不妨點擊一下左下角的【關注我】。
　　如果，您對我的博客所講述的內容有興趣，請繼續關注我的后續博客，我是【志青雲集】。
　　本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接。

---