楊振靈
(桂林電子科技大學(xué)信息與通信學(xué)院,廣西 桂林 541004)
高并發(fā)數(shù)據(jù)庫(kù)訪問(wèn)性能測(cè)試與制約因素分析
楊振靈
(桂林電子科技大學(xué)信息與通信學(xué)院,廣西 桂林 541004)
網(wǎng)上訂票、在線購(gòu)物等服務(wù)是一類(lèi)典型的基于數(shù)據(jù)庫(kù)的高并發(fā)訪問(wèn)應(yīng)用。高并發(fā)帶來(lái)的系統(tǒng)性能瓶頸為這類(lèi)應(yīng)用的擴(kuò)展帶來(lái)了極大挑戰(zhàn),影響了用戶(hù)體驗(yàn)。從客戶(hù)端發(fā)出請(qǐng)求到服務(wù)端產(chǎn)生響應(yīng),中間涉及并發(fā)訪問(wèn)量、原始數(shù)據(jù)集和查詢(xún)結(jié)果集大小、內(nèi)存容量、不同軟件性能以及CPU利用率等諸多因素影響系統(tǒng)整體性能。針對(duì)這些影響因素給出充分的分析和廣泛的實(shí)驗(yàn),以挖掘可提高整體系統(tǒng)性能的因素,為新型高效系統(tǒng)的建設(shè)提供依據(jù)。
高并發(fā);數(shù)據(jù)庫(kù);性能瓶頸;用戶(hù)體驗(yàn)
今天,數(shù)據(jù)處理正在接受來(lái)自?xún)蓚€(gè)方面的挑戰(zhàn),一是數(shù)據(jù)量的急劇增長(zhǎng);二是訪問(wèn)數(shù)據(jù)的用戶(hù)數(shù)的快速膨脹。第一類(lèi)挑戰(zhàn)通常需要借助于系統(tǒng)的橫向擴(kuò)展進(jìn)行解決;第二類(lèi)挑戰(zhàn)通??梢曰诂F(xiàn)有系統(tǒng)硬件,調(diào)優(yōu)等措施,采用縱向擴(kuò)展模式解決。網(wǎng)上訂票、在線購(gòu)物等應(yīng)用屬于典型的第二類(lèi)挑戰(zhàn)制造者,其核心特征是以數(shù)據(jù)庫(kù)為核心構(gòu)建應(yīng)用,具有廣泛用戶(hù)群,在多數(shù)情況下系統(tǒng)性能穩(wěn)定,但在一些特定政策和活動(dòng)的影響下,例如春運(yùn)的訂票、淘寶的雙11活動(dòng)和秒殺活動(dòng)等,常常出現(xiàn)訪問(wèn)量急劇增長(zhǎng),從而使得系統(tǒng)負(fù)荷短時(shí)間內(nèi)快速攀升,導(dǎo)致服務(wù)器響應(yīng)變慢、處理出錯(cuò)、宕機(jī)、甚至整個(gè)系統(tǒng)的癱瘓。
本文針對(duì)系統(tǒng)的現(xiàn)有設(shè)施和需求,具體結(jié)合用戶(hù)并發(fā)度、數(shù)據(jù)庫(kù)訪問(wèn)接口、內(nèi)存大小、索引等因素,聚焦于單表查詢(xún)和多表連接查詢(xún),基于大規(guī)模綜合實(shí)驗(yàn)和深入分析從縱向擴(kuò)展角度來(lái)審視系統(tǒng)性能提升的可能途徑。
數(shù)據(jù)庫(kù)的核心任務(wù)是保證數(shù)據(jù)的可用性和一致性,但兩者又相互制約。由于數(shù)據(jù)庫(kù)會(huì)有極大一部分開(kāi)銷(xiāo)用于維護(hù)事務(wù)特性,在一定程度上影響了系統(tǒng)可用性,并發(fā)訪問(wèn)數(shù)越高,對(duì)系統(tǒng)的可用性影響越大,因此需要權(quán)衡數(shù)據(jù)的一致性和可用性。其中,CΑP理論從理論視角給出了一致性、可用性和分區(qū)容錯(cuò)性三者之間的制約關(guān)系[1]。訂票、購(gòu)物等應(yīng)用數(shù)據(jù)量不算龐大,但對(duì)數(shù)據(jù)一致性與系統(tǒng)可用性均具有高要求,即實(shí)時(shí)響應(yīng)是用戶(hù)體驗(yàn)的核心,文獻(xiàn)[2-3]等從程序優(yōu)化視角進(jìn)行了研究,提出了的解決方案。
關(guān)于系統(tǒng)橫向擴(kuò)展的研究也不斷深入。例如,針對(duì)新型計(jì)算機(jī)體系結(jié)構(gòu)為數(shù)據(jù)處理帶來(lái)了新的可能和機(jī)遇,文獻(xiàn)[4-5]等進(jìn)行了研究。國(guó)內(nèi)的電商平臺(tái)淘寶為解決用戶(hù)訪問(wèn)瞬時(shí)爆炸增長(zhǎng)的困擾,設(shè)計(jì)了 OceanBase系統(tǒng),基于其數(shù)據(jù)訪問(wèn)特點(diǎn),采用分布式方案來(lái)解決問(wèn)題。文獻(xiàn)[6-7]等從云計(jì)算視角審視了大數(shù)據(jù)和大量用戶(hù)訪問(wèn)的數(shù)據(jù)應(yīng)用系統(tǒng)的性能優(yōu)化技術(shù)。
2.1 數(shù)據(jù)庫(kù)基本訪問(wèn)模式與性能影響因素
以數(shù)據(jù)庫(kù)為核心構(gòu)建應(yīng)用,基本的環(huán)節(jié)包括數(shù)據(jù)庫(kù)、數(shù)據(jù)庫(kù)管理系統(tǒng)、軟件開(kāi)發(fā)框架和客戶(hù)端,這四者構(gòu)成了多級(jí)客戶(hù)端/服務(wù)端的訪問(wèn)模式,如瀏覽器向軟件開(kāi)發(fā)框架提出訪問(wèn)請(qǐng)求,軟件開(kāi)發(fā)框架將其提交給數(shù)據(jù)庫(kù)管理系統(tǒng),進(jìn)而實(shí)際操作數(shù)據(jù)庫(kù)中的數(shù)據(jù)。
在上述數(shù)據(jù)庫(kù)訪問(wèn)模式中,就數(shù)據(jù)庫(kù)本身而言,其性能影響因素主要包括,數(shù)據(jù)表本身的大小、是否建有索引等。對(duì)數(shù)據(jù)庫(kù)管理系統(tǒng)而言,高并發(fā)訪問(wèn)的制約因素包括:內(nèi)存的大小、CPU的性能、選用數(shù)據(jù)庫(kù)管理系統(tǒng)的響應(yīng)能力等。對(duì)某個(gè)具體的查詢(xún)請(qǐng)求而言,性能影響因素主要包括返回結(jié)果集的大小、查詢(xún)涉及數(shù)據(jù)源的大小以及需要進(jìn)行I/O的次數(shù)等。同時(shí),為了進(jìn)行快速開(kāi)發(fā),系統(tǒng)采用合適的軟件開(kāi)發(fā)框架進(jìn)行構(gòu)建,因此,軟件開(kāi)發(fā)框架的性能也是影響的數(shù)據(jù)庫(kù)訪問(wèn)性能的核心因素之一。下面將針對(duì)上述因素進(jìn)行實(shí)驗(yàn)設(shè)計(jì)和測(cè)試。
2.2 實(shí)驗(yàn)設(shè)計(jì)方案
2.2.1 實(shí)驗(yàn)設(shè)計(jì)
圍繞2.1節(jié)中的各項(xiàng)性能影響因素,基于數(shù)據(jù)庫(kù)在經(jīng)過(guò)查詢(xún)優(yōu)化分解后最頻繁的兩類(lèi)查詢(xún)操作,即單表查詢(xún)和多表連接查詢(xún),進(jìn)行實(shí)驗(yàn)設(shè)計(jì)。實(shí)驗(yàn)選用開(kāi)源數(shù)據(jù)庫(kù)系統(tǒng)MySQL,根據(jù)各影響因素的不同屬性,設(shè)計(jì) 5組實(shí)驗(yàn),分別進(jìn)行有無(wú)軟件開(kāi)發(fā)框架的性能對(duì)比、不同數(shù)據(jù)源大小的性能對(duì)比、不同查詢(xún)結(jié)果集大小的性能對(duì)比、不同內(nèi)存大小的性能對(duì)比、基于索引的性能對(duì)比。對(duì)每一組實(shí)驗(yàn),分別進(jìn)行單表查詢(xún)實(shí)驗(yàn)和多表連接查詢(xún)實(shí)驗(yàn)。為了避免其它因素影響,每一組實(shí)驗(yàn)重復(fù)執(zhí)行5次,采用平均值作為評(píng)測(cè)時(shí)間。
針對(duì)開(kāi)發(fā)框架對(duì)系統(tǒng)性能的影響,采用Hibernate框架和Java數(shù)據(jù)庫(kù)連接(Java Data Base Connectivity, JDBC)直接連接的模式進(jìn)行實(shí)驗(yàn),以驗(yàn)證開(kāi)發(fā)框架在帶來(lái)開(kāi)發(fā)便捷性的同時(shí),也付出了性能開(kāi)銷(xiāo)。
具體實(shí)現(xiàn)方面,設(shè)計(jì)一個(gè)模擬客戶(hù)端來(lái)發(fā)起并發(fā)訪問(wèn),在一個(gè)客戶(hù)端中采用多線程模擬不同用戶(hù),向服務(wù)器發(fā)出訪問(wèn)請(qǐng)求。
2.2.2 實(shí)驗(yàn)環(huán)境
硬件環(huán)境上,CPU配置為Intel core i5-3230M 2.6GHz,最大內(nèi)存8G。實(shí)驗(yàn)所用的服務(wù)器采用真機(jī)和虛擬機(jī)兩種模式,即由虛擬機(jī)模擬2G和4G內(nèi)存時(shí)的實(shí)驗(yàn)環(huán)境。在軟件環(huán)境方面,編碼語(yǔ)言采用Java語(yǔ)言,Java開(kāi)發(fā)環(huán)境是jdk 1.6,Web服務(wù)器采用apache tomcat 6,數(shù)據(jù)庫(kù)管理系統(tǒng)采用MySQL 5.7。
2.2.3 實(shí)驗(yàn)數(shù)據(jù)集
數(shù)據(jù)集由三張基本表構(gòu)成,分別是消息表(message)、用戶(hù)表(human)和消息類(lèi)型表(kind),模擬生成三張表的中數(shù)據(jù)。不同實(shí)驗(yàn)條件下,每張表中含有不同數(shù)目的記錄。message表中存在外鍵與human表和kind表進(jìn)行連接,連接結(jié)果集的大小也根據(jù)實(shí)際需求進(jìn)行變化。
表1 用戶(hù)信息表
表2 消息表
表3 消息類(lèi)型表
所有查詢(xún)時(shí)間以毫秒(ms)為單位,具體查詢(xún)語(yǔ)句如下,
(1)單表查詢(xún):select * from message;
(2)表連接查詢(xún):select * from message m inner join human h on m.from_user = h.id inner join kind k on m.type = k.id;
3.1 軟件開(kāi)發(fā)框架對(duì)查詢(xún)性能影響與分析
本組實(shí)驗(yàn)主要驗(yàn)證Hibernate框架和JDBC對(duì)高并發(fā)數(shù)據(jù)庫(kù)訪問(wèn)的性能影響。實(shí)驗(yàn)中,在數(shù)據(jù)庫(kù)的 message表中存放11 100條記錄,服務(wù)器端分別設(shè)置成基于Hibernate和JDBC訪問(wèn)數(shù)據(jù)模式,客戶(hù)端則采用多線程模擬并發(fā)數(shù)分別為10、20、40、80、160、320、640、1280數(shù)量的訪問(wèn)請(qǐng)求。分別從單表查詢(xún)和多表連接查詢(xún)兩個(gè)方面進(jìn)行比較,其中多表連接查詢(xún)采用內(nèi)連接模式,實(shí)驗(yàn)結(jié)果如圖1和圖2所示。
圖1 軟件開(kāi)發(fā)框架的單表查詢(xún)性能對(duì)比
圖2 軟件開(kāi)發(fā)框架的多表連接查詢(xún)性能對(duì)比
從實(shí)驗(yàn)結(jié)果看,在結(jié)果集大小固定的情況下,由于Hibernate框架本身占用了一定的系統(tǒng)資源,其與數(shù)據(jù)庫(kù)的交互效率要低于 JDBC的直接訪問(wèn)效率。但開(kāi)發(fā)框架在提交大量相同查詢(xún)的情形下,可以借助二級(jí)緩存機(jī)制來(lái)提升效率,即第一個(gè)查詢(xún)返回結(jié)果后,后續(xù)的相同查詢(xún)則可直接訪問(wèn)緩存中的數(shù)據(jù)。JDBC并不具備這方面的靈活性??傮w上,開(kāi)發(fā)框架雖然提供了開(kāi)發(fā)的便捷性,但加重了系統(tǒng)負(fù)擔(dān),導(dǎo)致了大規(guī)模并發(fā)訪問(wèn)的性能下降。
3.2 原始數(shù)據(jù)大小對(duì)查詢(xún)性能影響與分析
本組實(shí)驗(yàn)主要驗(yàn)證在不同并發(fā)用戶(hù)訪問(wèn)數(shù)下,原始數(shù)據(jù)集大小對(duì)高并發(fā)數(shù)據(jù)庫(kù)訪問(wèn)的性能影響。實(shí)驗(yàn)中,讓message表中記錄數(shù)從千條、萬(wàn)條、十萬(wàn)條變化到百萬(wàn)條,同時(shí)保持著每張表中的索引和固定查詢(xún)的返回記錄數(shù)為100,客戶(hù)端模擬的并發(fā)用戶(hù)數(shù)分別為10,20,40,80,160,320,640,1280,進(jìn)行單表查詢(xún)和多表連接查詢(xún),實(shí)驗(yàn)結(jié)果如圖3和圖4所示。
圖3 不同原始數(shù)據(jù)集下的單表查詢(xún)性能
圖4 不同原始數(shù)據(jù)集下的多表連接查詢(xún)性能
根據(jù)該組實(shí)驗(yàn)結(jié)果,數(shù)據(jù)表的總記錄數(shù)對(duì)查詢(xún)性能的影響不明顯,但當(dāng)并發(fā)訪問(wèn)用戶(hù)數(shù)上升時(shí),由于存在資源競(jìng)爭(zhēng),導(dǎo)致了系統(tǒng)性能下降較快。
3.3 查詢(xún)結(jié)果集大小對(duì)查詢(xún)性能影響與分析
該組實(shí)驗(yàn)的主要目標(biāo)是驗(yàn)證查詢(xún)結(jié)果集大小對(duì)高并發(fā)數(shù)據(jù)庫(kù)訪問(wèn)的性能影響。基于上述實(shí)驗(yàn)環(huán)境,分別限定查詢(xún)結(jié)果集為 30、300、3000條記錄,客戶(hù)端模擬并發(fā)訪問(wèn)用戶(hù)數(shù)為10,20,40,80,160,320,640,1280,原始數(shù)據(jù)表中總記錄數(shù)為100 000,分別進(jìn)行單表查詢(xún)和多表連接查詢(xún)測(cè)試。實(shí)驗(yàn)結(jié)果如圖5和圖6所示。
圖5 不同查詢(xún)結(jié)果集下的單表查詢(xún)性能
圖6 不同查詢(xún)結(jié)果集下的多表連接查詢(xún)性能
從該組實(shí)驗(yàn)的結(jié)果可以看出數(shù)據(jù)表的查詢(xún)返回的記錄數(shù)對(duì)查詢(xún)速度的影響是非常直接的。當(dāng)返回的記錄數(shù)分別為30、300、3000時(shí),查詢(xún)的速度完全不同,存在較大差異。在單表查詢(xún)中,30與300之間查詢(xún)時(shí)間增長(zhǎng)平均倍率為2.93,而300與3000之間查詢(xún)時(shí)間增長(zhǎng)平均倍率為5.26。也就是說(shuō),隨著查詢(xún)返回記錄數(shù)的增加,查詢(xún)所用的時(shí)間也會(huì)增加。
3.4 內(nèi)存對(duì)查詢(xún)性能影響與分析
本組實(shí)驗(yàn)主要測(cè)試內(nèi)存的大小對(duì)高并發(fā)數(shù)據(jù)庫(kù)訪問(wèn)的性能影響。實(shí)驗(yàn)中,將內(nèi)存分別設(shè)置成2G、4G和8G,查詢(xún)數(shù)據(jù)表總記錄為100000條,模擬用戶(hù)并發(fā)數(shù)為10,20,40,80,160,320,640,1280,進(jìn)行查詢(xún)結(jié)果集大小為100條記錄的單表查詢(xún)和多表連接查詢(xún)。實(shí)驗(yàn)結(jié)果如圖7和圖8所示。
圖7 不同內(nèi)存下的單表查詢(xún)性能
圖8 不同內(nèi)存下的多表連接查詢(xún)性能
該組實(shí)驗(yàn)的實(shí)驗(yàn)結(jié)果表明內(nèi)存對(duì)于查詢(xún)速度的影響比較明顯,隨著并發(fā)訪問(wèn)數(shù)的增多,大的內(nèi)存由于能夠提供足夠的存儲(chǔ)空間,不會(huì)引發(fā)資源競(jìng)爭(zhēng),從而表現(xiàn)出了很好的性能。
3.5 索引對(duì)查詢(xún)性能影響與分析
本組實(shí)驗(yàn)的主要目標(biāo)是測(cè)試索引對(duì)高并發(fā)數(shù)據(jù)庫(kù)訪問(wèn)的性能影響。實(shí)驗(yàn)中,數(shù)據(jù)表中總記錄數(shù)仍保持為100 000,查詢(xún)返回記錄數(shù)為 100,模擬用戶(hù)并發(fā)數(shù)為 10,20,40,80,160,320,640,1280,分別在表未建索引和建有索引的情況下進(jìn)行單表查詢(xún)和多表連接查詢(xún)。實(shí)驗(yàn)結(jié)果如圖9和圖10所示。
圖9 有無(wú)索引下的單表查詢(xún)性能
圖10 有無(wú)索引下的多表連接查詢(xún)性能
該組實(shí)驗(yàn)表明索引對(duì)查詢(xún)性能具有很大影響,有效的索引能提升數(shù)據(jù)庫(kù)的并發(fā)訪問(wèn)性能。建有索引的查詢(xún)比沒(méi)有索引的查詢(xún)大約在查詢(xún)性能上提升了 3倍,而且隨著并發(fā)數(shù)、總記錄數(shù)、查詢(xún)記錄數(shù)的增加,沒(méi)有索引時(shí)的查詢(xún)時(shí)間相比于有索引時(shí)的查詢(xún)時(shí)間的倍數(shù)會(huì)增加。
基于大量的實(shí)驗(yàn)和分析,高并發(fā)訪問(wèn)數(shù)據(jù)庫(kù)時(shí)的主要性能影響因素有:(1)返回記錄數(shù);(2)索引;(3)內(nèi)存。在各影響因素中,查詢(xún)結(jié)果集大小是最有影響的。當(dāng)返回記錄數(shù)在增加時(shí),查詢(xún)所用的時(shí)間也會(huì)不斷的增長(zhǎng),而且當(dāng)返回記錄數(shù)每增加10倍時(shí),查詢(xún)時(shí)間的倍數(shù)差異也會(huì)越大。索引對(duì)查詢(xún)性能也具有顯著影響,在模擬并發(fā)用戶(hù)數(shù)為1280時(shí),基于索引的查詢(xún)性能比沒(méi)有索引的查詢(xún)性能提升了3倍左右。不使用索引,MySQL必須從第一條記錄開(kāi)始查找。表越大,花費(fèi)的時(shí)間越多。內(nèi)存對(duì)于查詢(xún)所用時(shí)間的影響也比較明顯,隨著內(nèi)存的增加,多用戶(hù)訪問(wèn)不在內(nèi)存資源競(jìng)爭(zhēng),從而減少了查詢(xún)時(shí)間。開(kāi)發(fā)框架盡管本身占用了一部分系統(tǒng)資源,對(duì)并發(fā)訪問(wèn)存在影響,但其通過(guò)二級(jí)緩存、偽靜態(tài)頁(yè)面等多種技術(shù)能減少用戶(hù)訪問(wèn)數(shù)據(jù)庫(kù)的次數(shù),從而在大量用戶(hù)提交相同請(qǐng)求時(shí)(例如查詢(xún)某趟車(chē)次余票,)減少了數(shù)據(jù)庫(kù)服務(wù)器的壓力。上述影響因素在指導(dǎo)高并發(fā)訪問(wèn)模式下的系統(tǒng)建設(shè)和優(yōu)化,具有高的應(yīng)用價(jià)值。
另外,本文的研究焦點(diǎn)仍聚焦于集中模式下數(shù)據(jù)訪問(wèn)的性能制約因素。在實(shí)際應(yīng)用中,可在探尋應(yīng)用的縱向擴(kuò)展能力的同時(shí),結(jié)合平臺(tái)的橫向擴(kuò)展,例如采取負(fù)載均衡分擔(dān)并發(fā)壓力等,多視角地改進(jìn)從而搭建高效的應(yīng)用。
[1] 倪超.1.2.3 CΑP和BΑSE理論[EB/OL].[2015-03-20].http:// book.51cto.com/art/201503/469187.htm.
[2] 王峰,顧明,李麗.基于J2EE應(yīng)用的數(shù)據(jù)庫(kù)訪問(wèn)的性能優(yōu)化[J].計(jì)算機(jī)工程,2003,29(1):278-279.
[3] 張志寬,羅曉沛.基于Web Dynpro Java平臺(tái)的查詢(xún)技術(shù)應(yīng)用分析[J].計(jì)算機(jī)工程與設(shè)計(jì),2009,30(20):4808-4810.
[4] Bruno N,Kwon YC,Wu MC.Αdvanced Join Strategies for Large-Scale Distributed Computation[J].Proceedings of the Vldb Endowment, 2014,7:1484-1495.
[5] Pirk H,Manegold S,Kersten M.Waste.Not...Efficient Co-Processing of Relational Data[J].Data Engineering (ICDE),2014 IEEE 30th International Conference,2014:508-519.
[6] 史英杰,孟小峰.云數(shù)據(jù)管理系統(tǒng)中查詢(xún)技術(shù)研究綜述[J].計(jì)算機(jī)學(xué)報(bào),2013,36(2):209-225.
[7] 林子雨,賴(lài)永炫,林琛,等.云數(shù)據(jù)庫(kù)研究[J].軟件學(xué)報(bào),2012,23(5):1148-1166.
Performance test of database access and analysis of restraining factors with high concurrency
The services of online booking and online shopping are typical high concurrent applications based on database. Αnd the system’s performance bottleneck which results from high concurrency brings great challenges to the extension of these applications and it also affects user experience. From the client which sends a request to the server which returns the response, it involves many factors such as the number of concurrent access, raw data set, result set, the memory, the performance of different softwares and CPU utilization,of which any factor will affect the overall system performance. Αiming at the factors, full analysis and extensive experiments are presented to mine the factor of improving the overall system performance, and it also provides basis for building a new efficient system.
High concurrency; database; performance bottleneck; user experience
TP392
Α
1008-1151(2016)06-0007-04
2016-05-11
國(guó)家自然科學(xué)基金(61362021);廣西自然科學(xué)基金(2013GXNSFDΑ019030, 2014GXNSFDΑ118035);廣西科技創(chuàng)新能力與條件建設(shè)計(jì)劃(桂科能 1598025-21);桂林科技開(kāi)發(fā)項(xiàng)目(20150103-6);桂林電子科技大學(xué)研究生教育創(chuàng)新計(jì)劃資助項(xiàng)目(YJCXS201516)。
楊振靈(1991-),男,桂林電子科技大學(xué)碩士研究生,研究方向?yàn)橹悄苄畔⑻幚怼?/p>