面向互聯網應用的大規模數據實時查詢優化方法研究

沙夢釩 徐蘭梅 滕慶勇 王小林

摘? 要：JSON通常被廣泛應用于服務器與客戶端瀏覽器之間的數據交互。某些場景下，由于客戶端請求數據量過大，會導致服務器運算時間及網絡傳輸時間加長，嚴重影響用戶體驗。針對此問題，提出了一種數據壓縮、數據緩存及分頁傳輸的優化處理策略，查詢數據庫的數據緩存至服務器內存中，在相同的查詢條件下不再查詢數據庫而是通過讀取內存數據庫Redis直接調取數據，并通過Gzip將數據壓縮之后再通過分頁方法，每次僅傳輸數據量的一部分到客戶端瀏覽器。通過真實金融大規模數據集進行方法驗證，結果表明，該方法能提高了45%以上的查詢效率，有效地改善用戶體驗。

關鍵詞：數據壓縮;緩存;內存數據庫;分頁

中圖分類號：TP393.01? ? ?文獻標識碼：A

Abstract： JSON （JavaScript Object Notation） is widely used for data exchange between server and client. However， large amount of data requests may result in long time delay on searching and transmission which will seriously affect users' experience. To solve these problems， this paper proposes an optimization strategy of data compression， data cache and paging transmission. Data of the query database is cached in memory. Next time with the same query conditions， data can be directly retrieved by reading Redis， a memory-based database， instead of being queried from within a disk-based database. The data will be compressed by Gzip compression technology and then transferred only a part by paging method to the browser each time. It is verified though the real large-scale financial data sets. The results show that the proposed strategy can effectively improve query efficiency by more than 45%， with improved user experience.

Keywords： data compression; cache; memory database; paging

1? ?引言（Introduction）

隨著社會的不斷發展，計算機技術越來越成熟，大量的軟件系統不斷地被研發出來服務于人們。人們一般通過瀏覽器或者APP去獲取一些自己需要的信息或者對一些信息進行操作，前后端的信息交互就是實現各類需求的一種重要的手段。然而有些時候我們需要實時查詢一些大規模數據，這些大型數據的傳輸會產生費時、占用過多網絡資源等不利影響，嚴重影響用戶體驗。如何解決這個問題成為一個重要課題。目前已有人提出過幾種類型的解決方案：第一類是查詢優化，通常為對數據結構的優化[1]或者對索引的優化，索引是為了加速對表中數據行的檢索而創建的一種分散的存儲結構。索引是針對表而建立的，它是由數據頁面以外的索引頁面組成的，每個索引頁面中的行都會含有邏輯指針，以便加速檢索物理數據[2，3]。第二類是采用了分布式儲存查詢，分布式網絡存儲采用可擴展的系統結構，利用多臺存儲服務器分擔存儲負荷，利用位置服務器定位存儲信息，提高了系統的可靠性、可用性和存取效率[4]。第三類是數據壓縮，通過對數據量的壓縮再進行查詢，之后再進行解壓，該方案在查詢效率上有很大提升[5，6]。

本文提出了一種思路，把查詢數據或查詢條件存入內存數據庫，再次做相同請求的時候不再查詢數據庫而是直接讀取緩存，并通過分頁的方法將大規模數據切割成許多部分，每次僅傳輸一部分給前端[7，8]。并在傳輸的過程中利用Gzip壓縮技術壓縮數據的方法[9]。本文在查詢數百萬級及更大量的數據的情況下，進行了多次實驗，通過設置對照實驗得出結論。

2? ?相關知識（Relevant knowledge）

Redis（Remote Dictionary Server），即遠程字典服務，是一個開源的使用ANSI C語言編寫、支持網絡、可基于內存亦可持久化的日志型、Key-Value數據庫，并提供多種語言的API。Redis是一個key-value存儲系統，支持各種不同方式的排序。為了保證效率，數據都是緩存在內存中。Redis會周期性的把更新的數據寫入磁盤或者把修改操作寫入追加的記錄文件，并且在此基礎上實現了master-slave（主從）同步。Redis支持主從同步。數據可以從主服務器向任意數量的從服務器上同步，從服務器可以是關聯其他從服務器的主服務器。同步對讀取操作的可擴展性和數據冗余很有幫助。

在Web開發的過程中，通常會遇到分頁技術。分頁技術的核心思想就是當人們需要提取大量數據的時候，不可能一次提取所有的數據，通過提取其中的一部分給用戶，在用戶需要的情況下再次提取剩下的部分。做到了大塊切割成小塊，每次只利用小塊部分。常見的分頁方法為客戶端分頁、數據庫分頁和服務器分頁三種方法。

（1）客戶端分頁。將全部或多頁結果數據一次返回給客戶端，客戶端通過展現組件進行分頁控制，優點是減少了客戶端和服務器的交互次數，客戶端進行數據緩存，提高了系統交互性，缺點則是增加了第一次交互的負荷。

（2）數據庫分頁。進行數據查詢時，數據庫返回一頁數據給客戶端。優點是每次從返回的數據庫返回較少數據，當次交互負荷較輕。缺點則是每次切頁都需要訪問數據庫，增加了數據庫訪問并發性。

（3）服務器分頁。是介于上述兩種方法之間的方法。優點是在1、2之間達到了平衡，既減少了數據庫并發又使服務器和客戶端當次交互的負荷減少，缺點則是需要考慮數據緩存，數據同步等問題，增加了系統復雜性。

Gzip是GNUzip的縮寫，最早用于UNIX系統的文件壓縮。HTTP協議上的Gzip編碼是一種用來改進web應用程序性能的技術，web服務器和客戶端（瀏覽器）必須共同支持Gzip。目前主流的瀏覽器，Chrome、firefox、IE等都支持該協議。常見的服務器如Apache、Nginx、IIS同樣支持Gzip。Gzip壓縮比率在3到10倍左右，可以大大節省服務器的網絡帶寬。Gzip 對于要壓縮的文件，首先使用LZ77算法的一個變種進行壓縮，對得到的結果再使用Huffman編碼的方法（實際上gzip根據情況，選擇使用靜態Huffman編碼或者動態Huffman編碼）進行壓縮。其工作原理如下：

首先由瀏覽器請求url，并在request header中設置屬性accept-encoding：gzip。表明瀏覽器支持Gzip。在服務器收到瀏覽器發送的請求之后，判斷瀏覽器是否支持Gzip，如果支持Gzip，則向瀏覽器傳送壓縮過的內容，不支持則向瀏覽器發送未經壓縮的內容。一般情況下，瀏覽器和服務器都支持Gzip，response headers返回包含content-encoding：Gzip。最后瀏覽器接收到服務器的響應之后判斷內容是否被壓縮，如果被壓縮則解壓縮顯示頁面內容。如圖1所示。

3? ?實時查詢優化方法（Real-time query optimization strategy）

本文針對大規模數據實時查詢的情況進行了方法優化，當我們需要查詢大規模的數據時，將數據通過key-value的形式儲存在Redis里。在后續的查詢請求里，我們可以直接查詢Redis數據庫調取出相應的數據。該操作大大減少了連接數據庫的時間，減少了resultSet封裝成對象的過程，避免了重復查詢數據庫的操作。在本文實驗中并沒有直接將百萬級數據放在Redis數據庫中，因為數據量龐大，不適合這樣操作處理。本次采取的方法是將構造特殊的查詢參數放入Redis中，在查詢數據的時候從數據庫中取出，并結合相應算法快速得出前端所需要的部分并返回給前端。

本次實驗的數據采用金融資產原始數據，對于整張視圖查出來的數據，要根據nvc_code和dtm_share_date這兩個字段進行排序返回前端進行顯示。按照這兩個字段進行排序。每次后臺只向前臺返回n條數據。如何正確地選出這n條數據很關鍵。思路的關鍵就是從數據庫count出每個資產的總條數，保存在numberList[i]，i指該資產在所選的資產里排序第幾。對于某些頁顯示的數據存在多個資產的數據，因此，把某頁的數據的組成，用下面這句話來描述：第page頁的數據由A資產的第start到第end，一共end-start+1條數據和B資產的第begin到stop，一共top-begin+1條數據和C資產組成。為了確定這些start、end、begin、stop等值，定義一個數組remaList。把該資產數據填充完之后，位于第幾頁還剩多少條數據需要后面資產填充的，這個多少條數據的數值存在remaList[i]，i指該資產在所選的資產里排序第幾。為了與前端傳來的page字段掛鉤，需要在定義一個數組pageList。該數組存放每個資產填充完之后的起始頁，若該資產的總條數小于需要填充的條數，該資產存放的值等于前一個資產存放的pageList中的值。下式描述了每一頁的分頁條數n與資產數據Xi的填充關系。

n為設置的分頁數，即每一頁有多少條數據，m為資產數，α為第i個資產所需要填充的數據量，λ為常量，取值為0或者1，當Xi資產的總條數大于分頁數n時，λ取0，否則λ取1。

將上述List數組存入redis中后，每當瀏覽器傳回page頁請求相應數據時，可以通過讀取redis中的數組快速計算出前端所需要的那部分數據并返回給瀏覽器。

再取得數據后，開始通過服務器開啟Gzip壓縮，以NGINX為例，首先設置gzip on參數開gzip模式，接下來通過gzip_min_length參數配置壓縮起點，例如文件至少大于1k才開啟壓縮，然后通過gzip_comp_level設置gzip的壓縮級別，該級別分為1—9級，級別越大壓縮的程度越大，同時對CPU的負擔也會逐漸增大。再通過gzip_type參數設置一下壓縮的文件類型，本文中為了解決請求大規模數據的優化策略，前后端交互是采取json的數據格式，因此這里配置的文本類型一般設置為application/json，這樣就可以針對此類型的請求操作進行壓縮。接下來通過gzip_vary參數配置是否在http-header開啟Accept-Encoding，開啟該參數配置是為了讓瀏覽器通知服務器自己是支持Gzip壓縮模式的，當瀏覽器接收到壓縮數據后會自動解壓操作。再通過gzip_buffers參數設置緩沖區大小，以4k為單位，若大于4k時，例如7k則分配為2*4k的緩沖區。最后設置一下gzip_http_version參數，該參數是協議版本，例如版本為1.1則設置1.1即可。

在壓縮完數據后，服務器向前端開始傳輸數據，此時通過頁數參數，選擇其中的部分數據返還給前端瀏覽器。例如頁碼參數為1時，我們可以傳第1至100條的數據，假設此時查詢的數據共計100萬條，本次僅僅只傳輸了萬分之一，當用戶需要下一批數據時，我們在通過頁碼參數2再次請求服務器，服務器從redis緩存的100萬條數據中直接取出第101至200條數據。在每一次的請求操作過程中，用戶都只拿到大規模數據的一小部分。每一次請求的數據量可以根據具體需求做出改變。

4? 實驗結果及分析（Experimental results and analysis）

本次實驗環境為一臺PC機，8G內存，i5-5200U，2.20GHz處理器，100M移動寬帶，瀏覽器為Chrome。服務器部分是采用分布式系統架構，每臺服務器的硬件環境為CPU：4核Intel（R） Xeon（R） Gold 6130 CPU @ 2.10GHz，內存16GB，硬盤200GB，操作系統采用Linux發行版之一的Centos 7.8版本。

本文通過設置對照實驗，開啟Gzip壓縮和未開啟Gzip壓縮時的效果對比、分頁傳輸效果對比試驗。本文中的實例因數據查詢條件過于復雜，在未分頁的情況下，百萬級數據會顯示超時，且對瀏覽器負擔較重。所以在Gzip壓縮對比實驗中在保證相同的分頁數情況下獲取實驗數據以此觀察壓縮效果（表2），在分頁效果對比實驗中，在相同數據量級下不同級別的分頁數量來獲取實驗數據以此觀察出分頁效果（表3）。以百萬級的數據為基準，逐漸增大數據量，通過10次采樣取平均值的方法開始試驗。試驗對比結果如圖2所示。

從圖2和表2可得知，本次實驗開啟的Gzip壓縮率約為50%，在分頁數量分別設置為一頁傳輸7200條數據，一頁傳輸14000條數據，一頁傳輸18000條數據，一頁傳輸23000條數據，一頁傳輸27000條數據共五組情況下，在壓縮前文件大小分別約為254kB、501kB、690kB、854kB、1000kB，傳輸數據所需要的時間分別約為26秒、47秒、59秒、73秒、86秒。當開啟Gzip壓縮后文件大小分別約為127kB、250kB、346kB、427kB、502kB，傳輸數據所需要的時間分別約為18秒、26秒、35秒、43秒、48秒。兩組數據的對比可以明顯看出，隨著每一頁分頁量的增加，從查詢到傳輸給前端的時間也逐漸增加，呈線性增長。開啟Gzip壓縮后，數據的大小減少了約50%，所花費的時間也是比未壓縮時少了很多，通過此次類比可以得出：在百萬級的數據量級別下，Gzip壓縮有著非常有效地優化效果。

從圖2和表3可知，在都設置了Gzip壓縮的條件下，分別設置了分頁數為50、10000、20000、30000的四組對照實驗。由圖中可得知，在分頁數為50條一頁的情況下，平均僅僅需要0.2秒便可獲取到數據，并且隨著量的增加，最后到700百萬的時候時間也保持著穩定，在0.27秒左右便可傳輸完畢。在分頁數為10000時，七組數據量的實驗下，時間平均在27秒左右。在分頁數為20000時，七組數據量的時間則平均在41秒左右。在分頁數為30000時，七組數據量的時間則平均在55秒左右。四組的對照實驗可以看出，時間在數據量的增大下，幾乎保持著水平趨勢，相對穩定。且隨著分頁數越來越小，所需要的時間也越來越少。由此可以推斷出，在大規模數據傳輸下，合理的分頁能有效地提高傳輸效率，縮短傳輸時間，很好的改善用戶的體驗。

試驗結果表明，未采用內存數據庫、Gzip壓縮及分頁傳輸的數據查詢在數據規模較小時，處理時間在接受范圍之內。當數據規模足夠龐大時，處理時間過長，客戶端瀏覽器負擔很重。而基于內存數據庫、Gzip壓縮和分頁傳輸的大規模數據查詢時，較好地解決了困難，在不同等級的數據量下均有良好的表現。

5? ?結論（Conclusion）

在傳統的B/S模式的互聯網應用遇到大規模數據查詢時的高計算延時、高傳輸時間問題下，本文從內存數據庫、Gzip壓縮及分頁傳輸的角度去改善效率問題。從大量數據實驗測試，該方案的確改善了效率問題，減少了查詢時間，提高了網絡傳輸效率，證實了該方案的可行性。該方案雖然有較為良好的效果，但是從實際應用的效果分析，還有著進一步改善提高的空間。

參考文獻（References）

[1] 王小林，劉敏，徐宏，等.一種移動互聯網序列化數據的傳輸優化方法[J].安徽工業大學學報（自然科學版），2017，34（01）：71-75.

[2] 夏秀峰，張劉暢，劉向宇.面向大規模圖數據的分布式可達性索引與查詢策略[J].計算機工程，2018，44（03）：65-72.

[3] 陳大偉，張清，劉敏.試論云計算環境下的分布式存儲技術[J].科技展望，2016，26（31）：16.

[4] 郭慶，朱一凡，謝瑩瑩，等.面向大規模網絡流量數據的實時匯聚查詢關鍵技術研究[J].小型微型計算機系統，2020，41（06）：1314-1320.

[5] FuTao Ni， Jian Zhang， Mohammad N.? Noori. Deep learning for data anomaly detection and data compression of a long‐span suspension bridge[J]. Computer Aided Civil and Infrastructure Engineering， 2020，35（7）：685-700.

[6] Rui-Peng Hu， Chun-Xiong Huang. Optimized compression technology for spatial data network transmission[J]. Journal of Discrete Mathematical Sciences and Cryptography， 2018，21（2）：557-562.

[7] 奚科芳.常見關系數據庫實現分頁[J].數字技術與應用，2020，38（01）：44-45.

[8] 王志娟，班婭萌，平金珍.基于AJAX技術和JAVAEE的分頁查詢優化[J].信息通信，2019（01）：118-119.

[9] 趙雅倩，李龍，郭躍超，等.基于OpenCL的Gzip數據壓縮算法[J].計算機應用，2018，38（S1）：112-115;130.