時間序列數據庫概覽——基於文件(RRD)、K/V數據庫(influxDB)、關係型數據庫

通常人們談論時間序列數據庫的時候指代的就是這一類存儲。按照底層技術不一樣能夠劃分爲三類。mysql

另一類數據庫其表結構是:git

[timestamp] [d1] [d2] .. [dn] [v1] [v2] .. [vn]github

其優化的查詢方式不限於查詢原始數據,而是能夠組合查詢條件而且作聚合計算,好比:算法

SELECT d2, sum(v1) / sum(v2) FROM metric WHERE d1 =
 「A」 AND timestamp >= B AND timestamp < C GROUP BY d2

咱們但願時間序列數據庫不單單能夠提供原始數據的查詢,並且要支持對原始數據的聚合能力。這種聚合能夠是在入庫階段完成的,所謂物化視圖。也能夠是在查詢階段完成,所謂實時聚合。根據實際狀況,能夠在這兩種方式中進行取捨。sql

想要在在查詢階段作數據的聚合和轉換,須要可以支持如下三點。數據庫

  • 用索引檢索出行號:可以從上億條數據中快速過濾出幾百萬的數據。
  • 從主存儲按行號加載:可以快速加載這過濾出的幾百萬條數據到內存裏。
  • 分佈式計算:可以把這些數據按照GROUP BY 和 SELECT 的要求計算出最終的結果集。

要想盡量快的完成整個查詢過程,須要在三個環節上都有絕招。傳統上說,這三個步驟是三個不一樣的技術領域。apache

  • 檢索:這是搜索引擎最擅長的領域。表明產品是Lucene。其核心技術是基於高效率數據結構和算法的倒排索引。
  • 加載:這是分析型數據庫最擅長的領域。表明產品是C-storeMonetdb。其核心技術是按列組織的磁盤存儲結構。
  • 分佈式計算:這是大數據計算引擎最擅長的領域。表明產品是Hadoopspark。其核心技術是sharding 和 map/reduce等等。

前面提到的時間序列庫(好比opentsdb)有很多從功能上來講是沒有問題。它們都支持過濾,也支持過濾以後的聚合計算。在數據量小的時候勉強是可用的。可是若是要實時從十億條裏取百萬記錄出來,再作聚合運算,對於這樣的數據量可能就勉爲其難了。知足海量數據實時聚合要求的數據庫很少,比較常見的有這麼幾種:數據結構

 

摘自:http://www.infoq.com/cn/articles/database-timestamp-01數據結構和算法

相關文章
相關標籤/搜索