朱肖穎，梁朝湘，陸科達(dá)

(1.桂林電子科技大學(xué) 計(jì)算機(jī)與信息安全學(xué)院，廣西 桂林 541004；2.3.梧州學(xué)院，廣西 梧州 543002)

企業(yè)二維碼微信營銷平臺(tái)中的大數(shù)據(jù)優(yōu)化處理

朱肖穎1，梁朝湘2，陸科達(dá)3

(1.桂林電子科技大學(xué) 計(jì)算機(jī)與信息安全學(xué)院，廣西 桂林 541004；2.3.梧州學(xué)院，廣西 梧州 543002)

針對(duì)企業(yè)二維碼微信營銷平臺(tái)中高并發(fā)、大數(shù)據(jù)處理過程效率低的問題，對(duì)大數(shù)據(jù)的存取過程和大數(shù)據(jù)高并發(fā)情況下的代碼邏輯做相應(yīng)的優(yōu)化處理。這個(gè)優(yōu)化處理包括數(shù)據(jù)庫的設(shè)計(jì)，SQL語句的優(yōu)化，算法結(jié)構(gòu)的優(yōu)化和建立高效索引等措施的配合。結(jié)果表明，優(yōu)化后的系統(tǒng)平臺(tái)讀寫速度顯著提高。

營銷平臺(tái)；大數(shù)據(jù)；高并發(fā)；數(shù)據(jù)庫

2015年3月“互聯(lián)網(wǎng)+”戰(zhàn)略在十二屆全國人大三次會(huì)議上由全國人大代表、騰訊董事會(huì)主席兼CEO馬化騰提出。馬化騰解釋說，“互聯(lián)網(wǎng)+”戰(zhàn)略就是利用互聯(lián)網(wǎng)的平臺(tái)，利用信息通信技術(shù)，把互聯(lián)網(wǎng)和包括傳統(tǒng)行業(yè)在內(nèi)的各行各業(yè)結(jié)合起來，在新的領(lǐng)域創(chuàng)造一種新的生態(tài)[1]。

微信，作為當(dāng)下最受歡迎的一款超級(jí)APP，已成功融入了許多人的生活。截至2016年第三季度，微信的智能手機(jī)覆蓋率已經(jīng)由2015年底的90.1%提升至92.5%，月活躍用戶達(dá)到 8.46 億，比去年同期增長 30%，用戶覆蓋 200 多個(gè)國家、超過 20 種語言。此外，各品牌的微信公眾賬號(hào)總數(shù)已經(jīng)超過 800 萬個(gè)，移動(dòng)應(yīng)用對(duì)接數(shù)量超過 85000個(gè)，微信支付用戶則達(dá)到了 4 億左右[2]。微信正是信息通訊技術(shù)和各行業(yè)結(jié)合的重要手段，企業(yè)傳統(tǒng)的營銷方式如電視廣告、報(bào)紙、宣傳海報(bào)等通常要耗費(fèi)大量的人力、物力和財(cái)力。微信營銷基于微信這一平臺(tái)，由于微信的各項(xiàng)功能都是免費(fèi)的，使用過程中僅僅產(chǎn)生少量的流量費(fèi)，因此，相較于傳統(tǒng)營銷方式，微信營銷的成本極為低廉，幾乎接近免費(fèi)。這讓微信營銷得到了許多企業(yè)的追捧，企業(yè)二維碼微信營銷平臺(tái)正是“互聯(lián)網(wǎng)+”時(shí)代下的產(chǎn)物。

企業(yè)二維碼微信營銷平臺(tái)以二維碼技術(shù)為切入點(diǎn)，依托微信平臺(tái)搭建起實(shí)時(shí)動(dòng)態(tài)智能化大數(shù)據(jù)的營銷服務(wù)平臺(tái)，包括對(duì)二維碼值的大批量生成、導(dǎo)出、生效、失效、報(bào)廢處理。因此，高并發(fā)和大數(shù)據(jù)處理的需求顯得格外重要。隨著企業(yè)生產(chǎn)規(guī)模的擴(kuò)大和消費(fèi)者對(duì)營銷產(chǎn)品認(rèn)知度的提升，平臺(tái)的使用率會(huì)爆炸性地增長。如一次性生成導(dǎo)出幾十萬甚至上千萬的二維碼值，多個(gè)客戶端同時(shí)對(duì)二維碼值進(jìn)行生效失效處理。此外，在互聯(lián)網(wǎng)技術(shù)日益發(fā)達(dá)的今天，對(duì)于用戶而言，平臺(tái)的訪問速度，服務(wù)質(zhì)量，平臺(tái)的健壯性和穩(wěn)定性等都會(huì)直接影響用戶體驗(yàn)。因此，在高并發(fā)、大數(shù)據(jù)量訪問的情況下，如何保證平臺(tái)的穩(wěn)定性、健壯性，是企業(yè)二維碼微信營銷平臺(tái)需要面對(duì)的巨大的挑戰(zhàn)，也是本文在優(yōu)化處理過程中需要考慮的問題。

1數(shù)據(jù)庫設(shè)計(jì)

影響系統(tǒng)平臺(tái)訪問速度快慢的因素歸根結(jié)底是數(shù)據(jù)庫模型的建立是否合理、高效[3]。一個(gè)不良的數(shù)據(jù)庫模型，輕則加大開發(fā)者開發(fā)的難度，影響軟件系統(tǒng)平臺(tái)的運(yùn)行性能，重則可能直接導(dǎo)致系統(tǒng)崩潰。因此，一個(gè)完整準(zhǔn)確的數(shù)據(jù)庫模型必須在整個(gè)企業(yè)二維碼微信營銷平臺(tái)開始實(shí)施前設(shè)計(jì)好。

數(shù)據(jù)庫模型的建立需注意以下幾大問題。

首先要注重?cái)?shù)據(jù)的需求分析過程。系統(tǒng)平臺(tái)的設(shè)計(jì)初期，需要處理的數(shù)據(jù)比較小，功能也相對(duì)簡(jiǎn)單，所以功能的完整性必然會(huì)在我們的考慮范圍之內(nèi)，但卻往往忽視了性能的要求。這種情況常常導(dǎo)致軟件系統(tǒng)平臺(tái)正常工作了一陣子之后性能不斷下降，但這個(gè)時(shí)候，系統(tǒng)的架構(gòu)已基本定型，推倒重做的代價(jià)非常大，往往不可行。因此，我們大多只會(huì)在現(xiàn)有軟件系統(tǒng)的基礎(chǔ)上不斷修改，這個(gè)過程也必定會(huì)消耗不少的人力物力和資源資金。有鑒于此，在本平臺(tái)的設(shè)計(jì)中，數(shù)據(jù)庫模型建立之初，并不急于設(shè)計(jì)與實(shí)現(xiàn)，而是先討論分析系統(tǒng)可能存在的瓶頸，并將可能出現(xiàn)的問題扼殺在初生的搖籃里，降低開發(fā)成本，提高系統(tǒng)性能。

其次是減少非必要的數(shù)據(jù)冗余。大量的數(shù)據(jù)冗余會(huì)導(dǎo)致數(shù)據(jù)庫中的數(shù)據(jù)重復(fù)出現(xiàn)，不僅占用大量的存儲(chǔ)資源，還會(huì)影響數(shù)據(jù)庫查詢的效率[4]。所以在數(shù)據(jù)庫設(shè)計(jì)中，要盡可能降低數(shù)據(jù)冗余，達(dá)到數(shù)據(jù)的簡(jiǎn)潔，易用。為了達(dá)到最低冗余，在設(shè)計(jì)中需要進(jìn)行模式的規(guī)范化，一般情況下，達(dá)到BC范式就可以大幅度地降低數(shù)據(jù)冗余。

另外，數(shù)據(jù)字段是數(shù)據(jù)庫最小的單位，它的設(shè)計(jì)對(duì)軟件系統(tǒng)性能的影響很大。因此，在數(shù)據(jù)表的建立過程中，需要注意以下幾點(diǎn)。

第一，數(shù)據(jù)類型盡量用數(shù)字型。數(shù)字型會(huì)比字符型快很多，因?yàn)閿?shù)據(jù)類型在檢索過程中只會(huì)掃描一次，而字符型會(huì)重復(fù)掃描，因此，用數(shù)字型會(huì)提高數(shù)據(jù)庫查詢效率。

第二，在滿足預(yù)見未來需求的前提下盡量選擇較小的數(shù)據(jù)類型。因?yàn)閿?shù)據(jù)在磁盤中被讀取出來之后會(huì)先儲(chǔ)存在內(nèi)存，再通過處理器和磁盤的輸入/輸出從內(nèi)存中讀取。由此可知，數(shù)據(jù)類型小，占用的空間也相對(duì)較小，過程中讀取數(shù)據(jù)的效率也會(huì)提升。

第三，靈活選擇char和varchar數(shù)據(jù)類型，數(shù)據(jù)庫中的字符類型char和varchar大小一樣，都是8000個(gè)字節(jié)，但兩者都分別有自己的特性，char查詢速度快，但占用較多內(nèi)存，varchar查詢速度要比char慢一些，但是可節(jié)省內(nèi)存。

第四，少用text和image數(shù)據(jù)類型，text和image類型是用二進(jìn)制存儲(chǔ)的，而二進(jìn)制字段的讀寫速度相對(duì)較慢，所以能不用text和image數(shù)據(jù)類型的情況下最好不用。

第五，自增字段需要慎重使用，因?yàn)樽栽鲎侄尾焕跀?shù)據(jù)的遷移。

2數(shù)據(jù)查詢的優(yōu)化

企業(yè)二維碼微信營銷平臺(tái)涉及幾十萬二維碼值的生成、生效、失效、報(bào)廢、導(dǎo)出等處理，頻繁操作大數(shù)據(jù)量的數(shù)據(jù)必定導(dǎo)致系統(tǒng)性能降低。所以我們要盡可能做到以下幾點(diǎn)：在滿足用戶需求的基礎(chǔ)上，盡量減少客戶端對(duì)數(shù)據(jù)庫的訪問次數(shù)；使用搜索參數(shù)搜索數(shù)據(jù)時(shí)，盡量使表的訪問行數(shù)最小化，使結(jié)果集最優(yōu)，使網(wǎng)絡(luò)負(fù)擔(dān)最小；在條件許可的情況下，最小化操作，提高查詢的響應(yīng)速度。

沒有索引，數(shù)據(jù)庫要查找某條數(shù)據(jù)就必須得對(duì)整個(gè)表的數(shù)據(jù)進(jìn)行掃描，直到找出符合條件的數(shù)據(jù)。當(dāng)表的數(shù)據(jù)量少時(shí)，系統(tǒng)性能沒有太大的差異，但當(dāng)數(shù)據(jù)表中的數(shù)據(jù)增長到一定的量，系統(tǒng)的性能就顯得極為糟糕了。因此，在企業(yè)二維碼微信營銷平臺(tái)的大數(shù)據(jù)處理過程中，必須優(yōu)化數(shù)據(jù)庫的查詢語句，適當(dāng)?shù)氖褂盟饕夹g(shù)進(jìn)行查詢，盡量避免全盤掃描。

數(shù)據(jù)庫查詢語句的優(yōu)化可以遵循以下幾個(gè)規(guī)則。

(1)在 WHERE 子句中避免對(duì)字段進(jìn)行 NULL 值判斷，避免使用不等號(hào)操作符，如：!=或<>，否則將導(dǎo)致索引無法正確使用從而進(jìn)行全表掃描。

(2)避免在 WHERE的等號(hào)(“=”)左邊進(jìn)行表達(dá)式運(yùn)算，否則將可能導(dǎo)致系統(tǒng)無法正確使用索引。

(3)能使用EXISTS和NOTEXISTS盡量使用，盡量不用IN或NOTIN。因?yàn)镮N或NOT IN會(huì)導(dǎo)致引擎進(jìn)行全表掃描而放棄索引的使用。

(4)合理使用UNION和UNION ALL語句，UNION語句會(huì)執(zhí)行SELECT DISTINCT函數(shù)而UNION ALL不會(huì)，所以對(duì)于一些單純地想使用分表來提高效率的查詢，完全可以使用UNION ALL語句，因?yàn)閁NION ALL語句會(huì)減少許多不必要的資源。

(5)避免使用SELECT INTO語句。 因?yàn)镾ELECT INTO 的使用會(huì)鎖定數(shù)據(jù)表，導(dǎo)致其他用戶無法訪問該表。

(6)盡量使用表變量來代替臨時(shí)表，減少頻繁創(chuàng)建和刪除臨時(shí)表操作，以防止系統(tǒng)數(shù)據(jù)表資源的消耗。

3算法結(jié)構(gòu)的優(yōu)化

3.1程序優(yōu)化

企業(yè)二維碼微信營銷平臺(tái)生成、生效、失效操作都需要一次性處理幾十萬甚至上千萬的數(shù)據(jù)，如果采用普通的執(zhí)行更新(executeUpdate)方法對(duì)一千萬的數(shù)據(jù)量進(jìn)行處理，就會(huì)導(dǎo)致數(shù)據(jù)庫和服務(wù)器之間有一千萬次的交互，正常情況下數(shù)據(jù)庫服務(wù)器處理一萬次數(shù)據(jù)交互需要一秒，則要處理完一千萬的數(shù)據(jù)量就得花費(fèi)一千秒。如果采用的是批處理提交模式，一千條數(shù)據(jù)才提交一次，即和服務(wù)器交互次數(shù)為一萬次，交互次數(shù)大大減少。平臺(tái)系統(tǒng)應(yīng)用了Hibernate批處理操作，優(yōu)化存儲(chǔ)程序，在程序上進(jìn)行分段插入并及時(shí)清空緩存數(shù)據(jù)，減少訪問數(shù)據(jù)庫的次數(shù)，這種操作對(duì)于數(shù)據(jù)庫服務(wù)器中物理I/O的減少不會(huì)太明顯，但會(huì)大大加快數(shù)據(jù)庫執(zhí)行速度，減少網(wǎng)絡(luò)延時(shí)開銷，此外，還會(huì)降低數(shù)據(jù)庫服務(wù)器端的處理器開銷。

3.2存儲(chǔ)過程的優(yōu)化

基于游標(biāo)的方法不僅效率差，還會(huì)占用內(nèi)存和寬帶，減少可用的并發(fā)[5]。通常情況下，基于集的方法會(huì)更優(yōu)于基于游標(biāo)的方法，但某些情況下又必須通過游標(biāo)來實(shí)現(xiàn)，所以在使用時(shí)，最好先對(duì)比基于游標(biāo)和基于集的方法，看哪種方法更優(yōu)，從而得到更好的實(shí)現(xiàn)途徑。

4高效索引的建立

索引是一把雙刃劍，索引使用得當(dāng)可顯著提升系統(tǒng)檢索性能，相反，則會(huì)導(dǎo)致系統(tǒng)性能降低[6]。因?yàn)閿?shù)據(jù)庫的工作量會(huì)隨著索引的增多而增大，索引過多的使用甚至可能導(dǎo)致索引碎片的出現(xiàn)，所以我們必須建立高效的索引，精益求精，讓數(shù)據(jù)庫得到高性能的發(fā)揮。

創(chuàng)建索引往往有兩個(gè)目的：保證數(shù)據(jù)庫表中每一行數(shù)據(jù)的唯一性和加快對(duì)表中記錄的查找或排序。在大型的數(shù)據(jù)庫中，經(jīng)常會(huì)使用聚集索引和非聚集索引，聚集索引的表中鍵值的邏輯順序決定了表中相應(yīng)行的物理順序，采用聚集索引的方式找到含有第一個(gè)值的行后，就能夠保證含有后邊索引值的行物理位置鄰近，且一個(gè)表只允許有一個(gè)聚集索引。非聚集索引的表數(shù)據(jù)的邏輯存儲(chǔ)順序和物理存儲(chǔ)順序無關(guān)，索引通過二叉樹來進(jìn)行描述，它的葉節(jié)點(diǎn)仍然是索引節(jié)點(diǎn)，但會(huì)有一個(gè)指針指向?qū)?yīng)的數(shù)據(jù)塊，非聚集索引的表行數(shù)會(huì)和數(shù)據(jù)表行數(shù)保持一致。所以，可以認(rèn)為無論添加何種索引技術(shù)都能夠有效提高數(shù)據(jù)查詢速度，但是同時(shí)某種程度上會(huì)導(dǎo)致增、刪、改的操作性能降低，當(dāng)填充因子大時(shí)性能降低的情況就越發(fā)明顯。因此，如果需要頻繁地對(duì)具有較多索引的表進(jìn)行增、刪、改操作，首當(dāng)其沖應(yīng)設(shè)置較小的填充因子，給各個(gè)數(shù)據(jù)頁留足空間，從而減少數(shù)據(jù)頁分割及重組操作。

5實(shí)驗(yàn)結(jié)果分析

優(yōu)化前一次性生成25萬和50萬二維碼值總耗時(shí)如圖1和圖2所示。

圖1 優(yōu)化前一次生成25萬二維碼值總耗時(shí)

圖2 優(yōu)化前一次生成50萬二維碼值總耗時(shí)

優(yōu)化后一次性生成25萬和50萬二維碼值總耗時(shí)如圖3和圖4所示。

圖3 優(yōu)化后一次生成25萬二維碼值總耗時(shí)

圖4 優(yōu)化后一次生成50萬二維碼值總耗時(shí)

優(yōu)化前后一次性生成各數(shù)據(jù)量二維碼值耗時(shí)分布對(duì)比如圖5所示。

優(yōu)化前一次性導(dǎo)出25萬和50萬二維碼值總耗時(shí)如圖6和圖7最后一行文字所示。

圖6 優(yōu)化前一次導(dǎo)出25萬二維碼值總耗時(shí)

圖7 優(yōu)化前一次導(dǎo)出50萬二維碼值總耗時(shí)

優(yōu)化后一次性導(dǎo)出25萬和50萬二維碼值總耗時(shí)如圖8和圖9最后一行文字所示。

圖8 優(yōu)化后一次導(dǎo)出25萬二維碼值總耗時(shí)

圖9 優(yōu)化后一次導(dǎo)出50萬二維碼值總耗時(shí)

實(shí)驗(yàn)結(jié)果表明，隨著一次性生成/導(dǎo)出二維碼值數(shù)量的增多，優(yōu)化前后總耗時(shí)的差別就越大，即從數(shù)據(jù)庫的設(shè)計(jì)，SQL語句的優(yōu)化，算法結(jié)構(gòu)的優(yōu)化以及高效索引的建立四個(gè)方面對(duì)大數(shù)據(jù)的存取過程和高并發(fā)情況下的代碼邏輯做相應(yīng)的優(yōu)化處理，可以有效地提高企業(yè)二維碼微信營銷平臺(tái)數(shù)據(jù)的讀寫效率，大幅度提升用戶體驗(yàn)滿足感。

6結(jié)論

本文呈現(xiàn)了在企業(yè)二維碼微信營銷平臺(tái)中出現(xiàn)的高并發(fā)、大數(shù)據(jù)量的情況下，如何從數(shù)據(jù)庫的設(shè)計(jì)，SQL語句的優(yōu)化，算法結(jié)構(gòu)的優(yōu)化以及高效索引的建立等四個(gè)方面對(duì)代碼邏輯所做的優(yōu)化處理。對(duì)比優(yōu)化前后的耗時(shí)數(shù)據(jù)可知，該優(yōu)化方法使得企業(yè)二維碼微信營銷平臺(tái)的讀寫效率得到了顯著的提升。這些優(yōu)化方法對(duì)處理大數(shù)據(jù)有一定的指導(dǎo)意義。

[1]馬化騰.“互聯(lián)網(wǎng)+”戰(zhàn)略應(yīng)上升至國家層面[EB/OL].http://tech.sina.com.cn/i/2015-03-04/doc-iawzuney0462159.shtml,2015-03-04.

[2]2016年中國互聯(lián)網(wǎng)報(bào)告:人們最愛的還是微信朋友圈[EB/OL]. [2016-08-05].http://mt.sohu.com/20160805/n462722481.shtml.

[3]高珍,謝玉婧.電子商務(wù)系統(tǒng)中的大數(shù)據(jù)處理[J].計(jì)算機(jī)光盤軟件和應(yīng) 用,2012(21):111-112.

[4]謝姍姍,周國祥，石雷.多用戶大數(shù)據(jù)量的數(shù)據(jù)庫訪問優(yōu)化與設(shè)計(jì)[J].合肥工業(yè)大學(xué)學(xué)報(bào)(自然科學(xué)版),2014,37(11):1311-1316.

[5]宋亞奇，周國亮，朱永利，等.云平臺(tái)下輸變電設(shè)備狀態(tài)監(jiān)測(cè)大數(shù)據(jù)存儲(chǔ)優(yōu)化與并行處理[J].中國電機(jī)工程學(xué)報(bào),2015(2).

[6]趙灼.淺談如何優(yōu)化SQL Server數(shù)據(jù)庫[J].中國管理信息化,2014,17(3):125-127.

(責(zé)任編輯：覃華巧)

Large Data Optimization of Enterprise's QR Code WeChat Marketing Platform

Zhu Xiaoying1, Liang Chaoxiang2, Lu Keda3

(1. Graduate School, School of Computer and Information Security, Guilin University of Electronic Technology, Guilin 541004, China;2. 3. Wuzhou University, Wuzhou 543002, China)

In view of the problem of the high concurrency and low data processing efficiency of the enterprise's QR code WeChat marketing platform, the process of the large data access and the code logic in the case of large data and high concurrency are optimized, including the design of the database, the optimization of the SQL statement, the optimization of the algorithm structure and the establishment of efficient index. The results show that the reading and writing speed of the optimized system is significantly improved.

Marketing platform; Large data; High concurrency; Database

2016-09-28

TP311

A

1673-8535(2016)06-0009-07

朱肖穎(1991-)，女，廣西玉林市人，梧州學(xué)院信息與電子工程學(xué)院教師，桂林電子科技大學(xué)在讀碩士，研究方向：軟件工程。

梁朝湘(1967-)，男，廣西桂平市人，梧州學(xué)院信息與電子工程學(xué)院副教授，研究方向：數(shù)值模擬。

陸科達(dá)(1978-)，男，廣西賀州市人，梧州學(xué)院信息與電子工程學(xué)院高級(jí)系統(tǒng)架構(gòu)師，研究生，研究方向：計(jì)算機(jī)軟件和理論。