場景20億分鐘K線數據的更新及查找
1，瞭解數據使用狀況
這些k線數據用於回測，而對於分鐘k線回測：
- 大部分回測週期在近幾個月或近幾年
- 熱門股票幾多滬深300、上證50等
- 分鐘回測須要必定的實時性既在開盤時間進行回測，須要最近的數據
- 數據增量每日幾百MB
※初始熱數據的劃分須要對業務進行深刻了解
※後續熱數據的精確劃分仍是要查看歷史查詢的記錄
統計來源：程序中添加的數據操做log；數據庫審計；數據庫中間件
2，根據數據使用頻率進行拆分
我將數據劃分2個層級：
1，熱數據：熱門股票的近1個月的數據
2，使用頻率較低的K線數據
※根據熱度使2種不一樣的存儲方式（時間段劃分）：
- 熱度數據-redis；
- 頻率低及冷數據-bcolz文件（頻率低的單獨創建文件）
每日夜間進行更新：將過期的部分熱數據從redis中寫入數據庫
每週進行更新：將數據庫過期的數據存入bcolz文件中（bcolz有很是不錯的壓縮率和速度）
3，數據庫架構演變
1，針對於量化回測，主要的瓶頸在於讀數據（每日讀的數據遠遠大於寫的數據）
2，對於系統往後增加的使用量，咱們將劃分的數據分配獨立的服務器
※redis集羣，數據庫集羣，文件服務器
以上都是用中間件進行訪問控制
3，數據庫的讀瓶頸的演變
-
- 數據庫瓶頸：一張表存海量數據（解決辦法：分表）
- 服務器瓶頸：查詢需求大於磁盤的io性能或負載能力（解決辦法：分庫）
※綜上所述咱們將數據庫中的熱門股票平均劃分到N個庫中，並再進行分表
※分表規則：例如輪動策略就是某些股票會在一個策略中同時出現，所以能夠放入一張表中
4，讀寫數據量都大的數據表方案
- 在大型的應用中必然存在每日更新頻繁和查詢頻繁的數據表
- mysql的解決方案：
方法：進行分庫分表，加讀寫分離
好處：可根據自身的數據使用狀況來定義中間件來控制資源訪問，從而實現資源的最大化利用
缺點：此方案創建於開發者對現有業務和數據使用很是瞭解的狀況下，另外若是往後業務發生變化，變動成本較大(表結構，數據遷移，中間件變動)
-
- ES+mongo解決方案：
方法：使用mongo自帶的分片功能，且只創建主鍵索引_id優化寫性能；經過ES查詢獲得_id後再查詢數據
好處：對於往後業務的拓展變動成本低(非結構化數據)；ES對海量數據查詢效率高
缺點：額外的存儲，ES索引字段變動