場景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索引字段變更