[發(fā)明專利]一種時間密集大數(shù)據(jù)量的B/S分區(qū)間分頁查詢方法

有效

• 申請?zhí)枺?/td>: 201210338858.X
• 申請日: 2012-09-13
• 公開（公告）號: CN102880685A
• 公開（公告）日: 2013-01-16
• 發(fā)明（設(shè)計）人: 李倩倩;呂江花;田徑;文喬;馬世龍
• 申請（專利權(quán)）人: 北京航空航天大學(xué)
• 主分類號: G06F17/30
• 分類號: G06F17/30
• 代理公司: 北京永創(chuàng)新實專利事務(wù)所 11121
• 代理人: 周長琪

技術(shù)領(lǐng)域

本發(fā)明屬于計算機數(shù)據(jù)分析領(lǐng)域，具體涉及一種時間密集大數(shù)據(jù)量的B/S分區(qū)間分頁查詢方法。

背景技術(shù)

很多領(lǐng)域如金融、電信及大型系統(tǒng)自動化測試等的業(yè)務(wù)數(shù)據(jù)都存儲于數(shù)據(jù)庫中，隨著企業(yè)信息化的發(fā)展，這些數(shù)據(jù)具有如下特點：

數(shù)據(jù)量大：數(shù)據(jù)條目通常可達(dá)到百萬甚至千萬級，占用存儲空間達(dá)到TB級別；

數(shù)據(jù)的時間相關(guān)性：在數(shù)據(jù)庫中，業(yè)務(wù)數(shù)據(jù)以時間為主鍵；在邏輯上，數(shù)據(jù)具有時間相關(guān)性，即對數(shù)據(jù)進行查詢分析時以時間為檢索條件，強調(diào)一段時間內(nèi)每個時間點上的數(shù)據(jù)情況；

數(shù)據(jù)的時間密度大：相鄰的兩條數(shù)據(jù)之間的時間間隔很小，通常在1s鐘以內(nèi)。

對已存儲的數(shù)據(jù)進行分析時必然要涉及到大量數(shù)據(jù)的查詢顯示，數(shù)據(jù)的分頁查詢是不可避免會遇到的問題。目前數(shù)據(jù)查詢大多基于B/S（Browser/Server，瀏覽器端與服務(wù)器端）結(jié)構(gòu)，B/S結(jié)構(gòu)是指服務(wù)器端由web服務(wù)器發(fā)放，客戶端由瀏覽器接收的架構(gòu)，常用的分頁策略有三類：

第一類是一次將所有的查詢結(jié)果全部返回到客戶端，翻頁時在客戶端控制需要顯示的條數(shù)。這類方法只查詢一次數(shù)據(jù)庫，對于結(jié)果集很小的情況比較適用，當(dāng)結(jié)果集很大時對網(wǎng)絡(luò)帶寬要求極高，因為一次查詢要將所有結(jié)果返回到瀏覽器端，可能會需要幾分鐘才能返回結(jié)果甚至超時，結(jié)果集大時，這類方法對客戶端內(nèi)存的消耗也是不可接受的；

第二類是將查詢結(jié)果全部緩存在服務(wù)器端，只需進行一次查詢，就可以將所有的檢索結(jié)果都保存下來，翻頁時只需從緩存在服務(wù)器端的結(jié)果集中取出相應(yīng)的條數(shù)。這類方法的優(yōu)點是查詢數(shù)據(jù)庫次數(shù)少，但是結(jié)果集很大或并發(fā)情況下，緩存結(jié)果將不斷膨脹，對服務(wù)器端的存儲空間占用很大，可能導(dǎo)致存儲空間不夠?qū)е路?wù)器宕機；

第三類是每次只返回當(dāng)前頁面需要顯示的條數(shù)，翻頁時再次發(fā)送查詢條件重新進行檢索。這類方法可使用三種分頁模型：第一種是上下頁分頁模型，就是頁面上只提供“上一頁”、“下一頁”兩個翻頁功能，用戶只能逐一翻頁，這種分頁模型的缺陷是對于用戶而言跳頁很不方便；第二種是應(yīng)用最廣泛的窗口型分頁模型，其基本模式就是根據(jù)當(dāng)前頁碼把附近的幾頁都作為鏈接放在頁面上，這種方式在獲取一頁數(shù)據(jù)的時候通常需要先獲取所有符合條件的數(shù)據(jù)，然后再取出相應(yīng)頁的數(shù)據(jù)從數(shù)據(jù)庫返回，對大數(shù)據(jù)量時時間開銷較大；第三種是隨意型分頁模型，一般是提供一個文本框讓用戶輸入頁碼，然后直接跳轉(zhuǎn)到該頁，這種方式對用戶而言是最為靈活的，但這種模型單獨使用的實際意義并不是很大，一般是在前兩種分頁模型中加入任意頁跳轉(zhuǎn)功能。

由于數(shù)據(jù)的時間密度大，以1s一條為例，一天的數(shù)據(jù)量有24*60*60=86400條，而很多查詢分析需查詢多天的數(shù)據(jù)以分析其變化趨勢，以10天為例，查詢結(jié)果將達(dá)到864000條，假設(shè)一條數(shù)據(jù)占用1k的存儲空間，一次查詢需占用864M的存儲空間。因此第一類和第二類方法都存在了很大的問題，一方面一次檢索1萬級甚至百萬級數(shù)據(jù)需要的查詢時間過長，這樣的響應(yīng)速度是不可接受的，另一方面，每個用戶多次查詢時，第一類方法對客戶端內(nèi)存的消耗程度是不可接受的，第二類方法對服務(wù)器端存儲空間提出了很大的挑戰(zhàn)，需要大量的存儲空間。第三類方法在每次翻頁時都需發(fā)送查詢條件重新進行查詢，由于數(shù)據(jù)的時間相關(guān)性，查詢時希望的顯示順序為按時間順序遞增或遞減，而從數(shù)據(jù)庫中SELECT出來的順序依賴于DBMS（數(shù)據(jù)庫管理系統(tǒng)）對數(shù)據(jù)的物理存儲，與數(shù)據(jù)插入順序無關(guān)，且數(shù)據(jù)插入順序也不完全與時間順序一致，因此SELECT無法保證結(jié)果集按照時間排序，唯一的方式是使用顯示的排序如Order?By子句，這類方法必須先檢索出所有符合條件的記錄并將其排序，當(dāng)結(jié)果集數(shù)據(jù)很大時，排序的時間將無法忍受。

發(fā)明內(nèi)容

本發(fā)明要解決的問題是：針對存儲于數(shù)據(jù)庫中的海量時間序列數(shù)據(jù)，查詢結(jié)果中，每個時間點對應(yīng)一條結(jié)果數(shù)據(jù)，對于指定的較長的時間區(qū)間需查詢多個數(shù)據(jù)庫表，傳統(tǒng)的基于B/S架構(gòu)的查詢方法無法在合理的響應(yīng)時間內(nèi)返回查詢結(jié)果。本發(fā)明提出了一種時間密集大數(shù)據(jù)量的B/S分區(qū)間分頁查詢方法。

一種時間密集大數(shù)據(jù)量的B/S分區(qū)間分頁查詢方法，由用戶通過瀏覽器端輸入初始查詢條件，在請求某一頁或某一區(qū)間時，服務(wù)器端根據(jù)以下步驟獲取請求結(jié)果數(shù)據(jù)：