cache_timing_db基于 Redis 的簡單時序數(shù)據(jù)庫實現(xiàn)

cache_timing_db是基于Redis的一個時序數(shù)據(jù)庫實現(xiàn)，支持高效的查詢時間分布的數(shù)據(jù)，提供數(shù)據(jù)的加載器和查詢器，能夠?qū)崿F(xiàn)自動化的數(shù)據(jù)加載和高性能的查詢。

背景

在我負責的一個系統(tǒng)中，有一個數(shù)據(jù)的同步表，每天都會同步幾萬的數(shù)據(jù)，一定時間下來，表已經(jīng)累積了幾千萬的數(shù)據(jù)，這些數(shù)據(jù)實際上是十萬個站址的電量統(tǒng)計，平常沒用到覺得沒什么，后面來了一個實時性較強的需求，需要通過站址號、電表號、地址編碼以及時間來查詢一個范圍的數(shù)據(jù)，即使加了索引查詢效率依然沒有達到實時的要求，后來發(fā)現(xiàn)系統(tǒng)的Redis內(nèi)存申請的還算大，就打算用Redis來緩存這部分數(shù)據(jù)。主要考慮數(shù)據(jù)在Redis如何存儲、如何高效的加載進Redis以及如何查詢等問題，因此開發(fā)了cache_timing_db。

設計思路

數(shù)據(jù)特點 ：數(shù)據(jù)有個特點，就是一個站址號下有很多條數(shù)據(jù)，這些數(shù)據(jù)是按照天來分布的，因此可以考慮一個站址的數(shù)據(jù)就放到一個Redis的數(shù)據(jù)結(jié)構(gòu)里面。

存儲實現(xiàn) ：使用Redis的列表來實現(xiàn)，用戶通過配置一個起始的日期時間以及一個單位偏移時間就能實現(xiàn)列表不同的下標存儲不同時間的數(shù)據(jù)，查找時只需要知道起始時間和單位偏移就可以計算出要查找的數(shù)據(jù)的下標。當然有缺點，比如日期范圍內(nèi)有很多時間點沒有數(shù)據(jù)就會造成存儲的浪費，因為即使沒有數(shù)據(jù)也需要Redis開辟一個空節(jié)點，空節(jié)點也會占用一定的內(nèi)存，因此這種數(shù)據(jù)結(jié)構(gòu)設計不能存儲過長時間的數(shù)據(jù)。如下圖：這就是一個站址號對應的每天同步的數(shù)據(jù)，我把這樣的一個列表稱之為一個“桶”。

序列化方式 ：采用的是Protostuff作為序列化方式，相比JSON和JDK能夠更加節(jié)省內(nèi)存。

加載模塊實現(xiàn) ：由于采用定時任務加載的方式，因此使用我的另一個框架AutoJob，支持錯誤重試，日志記錄等。加載主要分為幾個步驟：

首先就是初始化桶，Redis的lset命令必須要求下標在列表的長度范圍內(nèi)，所以必須先給桶初始化n個節(jié)點，都不放數(shù)據(jù)，初始化桶需要保證桶原來就不存在，因為通過管道的方式初始化，所以如果桶本來存在會讓桶的長度變成幾倍設置初始化長度。為了保證高效性，這里使用的是布隆過濾器來進行過濾，如果布隆過濾器說桶存在則可能存在，如果說不存在則一定不存在，這也會導致一個問題：在使用管道存數(shù)據(jù)時可能有的桶沒有被創(chuàng)建，此時會出現(xiàn)異常，因此此時才去掃描Redis，查找不存在的桶然后創(chuàng)建，并且重新load這一批數(shù)據(jù)，這樣布隆過濾器可以過濾出大部分（預估配置合理的情況下）key。

其次就是保存數(shù)據(jù)，保存數(shù)據(jù)主要就是利用配置的起始時間和單位偏移來計算下標，然后放入列表。