基於大資料量的快取查詢實現方案
業務、應用系統最常用的就是基於資料的查詢,這不同於巨集觀意義上的系統各個層面優化(應用端、服務端、DB端等等),基於資料的查詢更多時候需要考慮資料的規模、使用者的習慣、資料的變化性等因素,但同時資料查詢的優化也貫穿著系統的各個層面。本文主要針對一個特定領域進行分析,以供各位參考!
基於資料的查詢往往首要考慮的是快取資料,那麼快取的前提:
1、資料不會實時變化
2、每個使用者最大範圍的可以共用資料集合
基於快取的實現方案,通常需要這樣的一個快取框架來完成,OK,接下來首先來應用溫老師的ADMEMS矩陣方法進行結構化的需求分析,來看看我們的關鍵性需求、功能以及約束影響:
功能 |
質量 |
約束 |
|
業務級需求 |
當前:管理遊戲類複雜產品的資料快取 未來:管理其他類產品的資料快取 |
新產品上線快,釋出頻繁 快取資料的關鍵性 |
支援DB直連和快取切換 與關聯業務系統快取同時生效 支援快取更新、重新整理(5分鐘時效) 支援快取故障恢復 支援其他類產品快取管理 |
使用者級需求 |
手機平臺 Web平臺 遊戲平臺 |
高可用 易用性 效能:快取查詢、吞吐 |
分散式的使用要求 不同平臺的差異因素 |
開發級需求 |
資料安全機制 可重用、可擴充套件 |
補充說明:
1、可擴充套件性
不同型別資料庫的以外掛方式接入快取體系(Oracle、SQL Server等等)
2、可用性
資料獲取重試機制、快取重新整理重試機制、快取通知重試機制
3、效能
以最小粒度為資料快取更新點
4、故障恢復
分散式伺服器、單臺WEB下線,上線,快取資料重新拉取
廢話不多說,針對以上的需求分析,現對該快取的預設計實現方案陳述如下:
另外,考慮到Cache應用到不同的系統層面,也應一併考慮到如下的優化:
1、應用端
如果是列表類,動態變化的查詢,可採用分頁查詢
另外根據業務需求,可將首頁或查詢命中率較高的頁資料進行快取
同時可配合非同步查詢的方式進行
2、資料庫
查詢優化,針對不同的查詢維度,進行分割槽並建立合適的索引,適當時候考慮資料遷移
另外建立資料同步機制,完成讀寫分離
其他,待補充!
其他參考: