在實際的任何乙個系統中，查詢都是必不可少的乙個功能，而查詢設計的好壞又影響到系統的響應時間和效能這兩個要害指標，尤其是當資料量變得越來越大時，於是如何處理大資料量的查詢成了每個系統架構設計時都必須面對的問題。本文將從資料及資料查詢的特點分析出發，結合討論現有各種解決方案的優缺點及其適用範圍，來闡述j2ee平台下如何進行查詢框架的設計。
value list handler模式及其侷限性
在j2ee應用中，對於大資料量查詢的處理有許多好的成功經驗，比如value list handler設計模式就是其中非常經典的乙個，見圖1。該模式建立乙個valuelisthandler物件來控制查詢的執行以及結果集的快取，它通過dao(data access object)來執行查詢，並將資料庫返回的結果集（傳輸物件transfer object的集合）快取起來，接下來的客戶端查詢請求將直接從快取中獲得。它的特點主要體現在兩點：伺服器端快取資料，每次只返回客戶端本次操作所需的資料，通過這兩個措施來減少資料庫的訪問次數以及增加客戶端的響應速度，達到最優的查詢效果。當然，這裡面隱含乙個前提就是客戶端採用分頁的方式來瀏覽資料。關於該模式的具體介紹，請參考[core j2ee patterns]一書。
圖1：value list handler類圖
資料引用:
如何處理大資料量抽數長期無響應
在乙個專案上線過程中，由於一些模型資料量巨大，抽數十分緩慢，長期在黃燈狀態，monitor 的訊息是 missing messages.處理幾次類似問題後，總結了一點經驗 首先檢查系統的一些引數設定是否正確，和抽數相關的引數包括 1.sm59 2.s biw進行傳輸設定 idoc 頻率 多少個資料 ...
大資料量的處理
其實這個問題老是在面試的時候提到 1。建立專門的彙總表 這個表一般是每天晚上做統計處理 建立索引 索引的話，插入和修改會變慢，也是只做統計原因之一 用來查詢，如果量非常大，那麼分表，還是大，那麼分庫,就是資料倉儲概念了 2。關聯表查詢 多表聯合查詢 的大資料，首先就是1 把多個表做成乙個統計表，或者...
Algorithm 大資料量處理的題目
q 1.給你a,b兩個檔案，各存放50億條url，每條url占用64位元組，記憶體限制是4g，讓你找出a,b檔案共同的url。2.有10個檔案，每個檔案1g，每個檔案的每一行都存放的是使用者的query，每個檔案的query都可能重複。要你按照query的頻度排序 3.有乙個1g大小的乙個檔案，裡面...