最近看到這個開源時序數據庫,基于postgrSQL,github已經2600多顆星,適合傳感器采集?數據的存儲以及分析,項目上應該能用得到,以下是官網的介紹,翻譯一下.
?官網地址

?概述

TimescaleDB是一款針對快速獲取和復雜查詢而優化的開源時間序列數據庫。 它使用“標準的SQL”語句，并且像傳統的關系數據庫那樣容易使用，像nosql那樣可擴展.
與這兩種替代品（??關系數據庫與NoSQL）相比,TimescaleDB為時間序列數據集合了兩種數據庫的優點：

易用

• PostgreSQL原生支持的所有SQL,包含完整SQL接口（包括輔助索引，非時間聚合，子查詢，JOIN，窗口函數）
• 任何使用PostgreSQL的客戶端或工具，可以直接應用到該數據庫，不需要更改。
• 時間為導向的特性，API功能和相應的優化。
• 可靠的數據存儲。

可擴展

• 透明時間/空間分區，用于放大（單個節點）和擴展（即將出現）
• 高數據寫入速率（包括批量提交，內存中索引，事務支持，數據備份支持)
• 單個節點上的大小合適的塊（二維數據分區），以確保即使在大數據量時即可快速讀取。
• 塊之間和服務器之間的并行操作

可靠性

• 作為PostgreSQL的擴展。
• 受益于20多年的PostgreSQL研究的成功經驗（包括流式復制，備份）
• 靈活的管理選項（與現有的PostgreSQL生態系統和工具兼容）

本節的其余部分描述了TimescaleDB架構的設計和動機,包括為什么時間序列數據不同，以及在構建TimescaleDB時如何利用其特性.

什么是時序數據

時序數據和其他數據有什么不同?

許多應用程序或數據庫實際上采取了一種窄視圖,并將時間序列數據與特定形式的服務器?數據等同：

Name:    CPU
Tags:    Host=MyServer, Region=West
Data:
2017-01-01 01:02:00    70
2017-01-01 01:03:00    71
2017-01-01 01:04:00    72
2017-01-01 01:05:01    68

但事實上,在許多監控應用中，不同的數據通常被會被一起收集（例如，CPU，存儲器，網絡統計，電池壽命）。 并且，分別考慮每個指標并不總是有意義的。 所以可以考慮這種的“?更寬”的數據模型，保持同時收集的指標之間的關聯性。

Metrics: CPU, free_mem, net_rssi, battery
Tags:    Host=MyServer, Region=West
Data:
2017-01-01 01:02:00    70    500    -40    80
2017-01-01 01:03:00    71    400    -42    80
2017-01-01 01:04:00    72    367    -41    80
2017-01-01 01:05:01    68    750    -54    79

這種類型的數據應該應用更為廣泛，無論是傳感器的溫度讀數，股票的價格，機器的狀態，甚至登錄到應用程序的數量。

時間序列數據代表系統，過程或行為隨時間變化的數據。

時序數據的特點

如果仔細觀察它是如何生產和獲取的，那么TimescaleDB等時間序列數據庫通常具有以下特點： ?

• 時間中心:?數據記錄總有時間戳
• ?只增加:數據只增不減
• 最新數據:新數據通常是最最新時間，我們更少地更新或補充關于歷史時間的缺失數據。

數據的頻率或規律性不太重要， 它可以每毫秒或一小時收集。 它也可以以規則或不規則的間隔收集（例如，當某些事件發生時，而不是在預定義的時間）。

But haven't databases long had time fields? 與其他數據（如標準關系“業務”）數據相比，時間序列數據（和支持它們的數據庫）的關鍵區別在于數據的更改是插入，而不是覆蓋。

時序數據無處不在

時間序列數據隨處可見，例如。

• 監控計算機系統?：虛擬機，服務器，容器的度量（CPU，內存，網絡和磁盤IOPS），服務和應用指標（請求率，請求延遲）。
• 金融交易系統：經典證券，較新的加密貨幣，付款，交易事件。
• 物聯網：工業機器和設備上的傳感器數據，可穿戴設備，車輛，物理容器，托盤，智能家居消費者設備等。
• 事件應用程序：用戶/客戶交互數據，如點擊流，瀏覽量，登錄，注冊等。
• 商業智能：跟蹤關鍵指標和業務的整體健康狀況。
• 環境監測：溫度，濕度，壓力，pH，花粉計數，氣流，一氧化碳（CO），二氧化氮（NO2），顆粒物（PM10）。

數據模型

TimescaleDB利用“寬表”數據模型，這在關系數據庫的世界中是相當普遍的。 這使得Timescale與其他通常使用“窄表”模型的其他時間序列數據庫(例如實時數據庫)有些不同。

在這里，我們將討論為什么選擇寬表模型，以及我們如何推薦使用物聯網（IoT）的時間序列數據。

設想一下，分布的1000個物聯網設備以不同的頻率收采集環境數據。 此數據可能包括：

• 標識符：device_id，時間戳
• 元數據：location_id，dev_type，firmware_version，customer_id
• 設備指標：cpu_1m_avg，free_mem，used_mem，net_rssi，net_loss，電池
• 傳感器指標：溫度，濕度，壓力，CO，NO2，PM10

采集來的數據類似下面的格式:

讓我們為這些數據建立模型.

窄表模型

多數時序數據利用以下方式為數據建模.

窄表模型
大多數時間序列數據庫將以以下方式表示此數據：

• 代表每個屬性作為一個單獨一列數據（例如，cpu_1m_avg和free_mem作為兩個不同的東西）
• 以“時間”，“值”對的方式進行存儲
• 將元數據值表示為與該tag/value集合相關聯的“標簽集”

在該模型中，每個值/標簽組合作為單獨一個“時間序列”。

使用我們上面的例子，這種方法將產生9個不同的“時間序列”，每個時間序列由一組唯一的標簽定義。

1. {name:  cpu_1m_avg,  device_id: abc123,  location_id: 335,  dev_type: field}
2. {name:  cpu_1m_avg,  device_id: def456,  location_id: 335,  dev_type: roof}
3. {name:  cpu_1m_avg,  device_id: ghi789,  location_id:  77,  dev_type: roof}
4. {name:    free_mem,  device_id: abc123,  location_id: 335,  dev_type: field}
5. {name:    free_mem,  device_id: def456,  location_id: 335,  dev_type: roof}
6. {name:    free_mem,  device_id: ghi789,  location_id:  77,  dev_type: roof}
7. {name: temperature,  device_id: abc123,  location_id: 335,  dev_type: field}
8. {name: temperature,  device_id: def456,  location_id: 335,  dev_type: roof}
9. {name: temperature,  device_id: ghi789,  location_id:  77,  dev_type: roof}

這種時間序列的數量等于每個屬性種類的乘積，即（＃名稱）x（＃設備ID）x（＃位置ids）x（設備類型））。

這些“時間序列”中的每一個都有自己的一組時間/值序列。

現在，如果您采集的設備狀態屬性都是相對獨立的，不屬于某種元數據結構,這種方法可能是有意義的。

但總的來說，我們認為這種情況是不多見的。它丟失了數據之間的關聯性，例如你可能遇到以下問題：

• 當free_mem為0時系統的state是什么?
• cpu_1m_avg與ree_mem的變化是否有關系？
• ocation_id的平均溫度是多少？

我們認為窄模型不是很好。我們是真的收集了9種不同的數據呢，還是僅收集了一一種由多種指標組合而成的數據？

寬表模型

相比之下，TimescaleDB使用了廣泛的模型，反映了數據的本質結構。

我們的寬桌面模型實際上看起來與初始數據流完全相同：

這里，每一行都是一個新的讀數,指定時間的一組元數據。這使我們能夠保留數據中的關系，并提出比以前更有趣或更具探索性的問題。

當然，這不是一種新的格式：它是通常在關系數據庫中找到的。這也是為什么我們發現這種格式更直觀。

JOINS的使用

TimescaleDB的數據模型與關系數據庫有著相似之處：它支持JOINs。具體來說，可以在輔助表中存儲額外的元數據，然后在查詢時使用該數據。

在我們的例子，我們可以有一個單獨的位置表，映射location_id到該位置的其他元數據。例如：

然后，可以join兩個表一起查詢，例如：zipcode為10017位置上設備平均free_mem是多少.

沒有join，就需要對它們的數據進行非規范化，并將每個測量行存儲所有元數據。這會造成數據膨脹，使數據管理更加困難。

通過連接，可以獨立存儲元數據，輕松地更新映射。

舉例來說，如果我們要更新我們location_id為77的region（例如，從“馬薩諸塞州”向“波士頓”），我們就不需要重新修改歷史數據.

架構與概念

TimescaleDB是作為PostgreSQL上的一個擴展，它可以深入到Postgres的查詢計劃器，數據模型和執行引擎中。這允許TimescaleDB的展示就像一個普通表，但實際上只是包含實際數據的許多單獨表的抽象或虛擬視圖。

這種單表視圖，我們稱做超表(hypertable)，由許多的塊(chunks)構成。塊是通過在一個或兩個維度上劃分超級表的數據創建的：通過時間或“partition key”（如設備ID，位置，用戶ID等）創建。我們認為它是跨“time and space”的分區。

術語

Hypertables(超級表)

數據交互的重點是超表(Hypertables)，跨越空間和時間間隔的單個連續表的抽象，使得可以通過普通的SQL查詢它。

幾乎所有與TimescaleDB的用戶交互都是與超級表。創建表和索引，更改表，插入數據，選擇數據等可以（并且應該）全部在hypertable上執行。

超級表由具有列名稱和類型的標準模式定義，至少有一列指定時間值，另一列用于分區鍵(partitioning key)。

單個TimescaleDB部署可以存儲多個超級表，每個具有不同的結構。

在創建一個TimescaleDB需要Hypertable的兩個簡單的SQL命令:CREATE TABLE，其次是SELECT create_hypertable().

超級表會自動創建時間和主鍵(primal key)的索引,也可以創建其他類型的索引.

Chunks(塊)

在內部，TimescaleDB自動將Hypertable分割成塊，每個塊對應于一個特定的時間間隔和一個分區鍵。這些分區是不重合的，這有助于查詢器進行查詢.

每個塊都使用標準數據庫表實現。（在PostgreSQL內部組件中，該塊實際上是“父”超級表的“子表”。）

合適的塊大小，確保表索引的所有B樹可以在插入期間駐留在內存中。這樣可以避免在修改這些樹中的任意位置時出現thrashing。

此外，通過避免過大的塊，我們可以根據自動保留策略刪除的數據時避免昂貴的“抽真空”操作。運行時可以通過簡單地刪除塊（內部表）來執行此類操作，而不是刪除單個行。

單節點與集群

TimescaleDB可以單節點和集群執行分區操作。雖然傳統上分區僅用于跨多臺機器的擴展，但是即使在單臺機器上，也可以進行擴展提高寫入速率（并且改進的并行化查詢）。

TimescaleDB目前的開源版本僅支持單節點部署。但是，TimescaleDB的單節點版本已經在商品機器上超過100億行高壓測試，而插入性能沒有損失。

單節點分區的優點

在單個計算機上擴展數據庫性能的常見問題是內存和磁盤之間的成本/性能折衷。最終，我們的內存放不下我們所有的數據，需要將數據和索引寫入磁盤。

一旦數據足夠大，我們無法將所有索引的頁面（例如，B-tree）都放在內存中，那么更新樹的隨機部分需要和磁盤進行交換。而PostgreSQL等數據庫為每個表索引保留一個B樹，以便有效地找到該索引中的值。因此，您在索引更多列時會出現問題。

但是由于TimescaleDB創建的每個塊本身都作為單獨的數據庫表存儲，所以它們的所有索引只能構建在這些小得多的表之間，而不是單個表，表示整個數據集。因此，如果我們正確地調整這些塊，我們可以將最新的表（及其B樹）完全配置在內存中，并避免這種交換磁盤問題，同時保持對多個索引的支持。

和PostgreSQL比較

TimescaleDB具有三種主要優點，適用于存儲時間序列數據相對PostgreSQL或其他傳統RDBMS來說:較高數據采集率，優越的查詢性能和時間特性的功能。

而由于TimescaleDB允許您使用全范圍的PostgreSQL的功能和工具-例如JOINS語句，通過PostGIS的地理信息查詢，pg_dump和pg_resotre語句，使用的postgrepsql的連接器,沒理由不使用用在PostgreSQL數據庫中存儲時間序列數據的TimescaleDB。

高采集率

與PostgreSQL相比，TimescaleDB的采集時序數據速度要高得多，更穩定。正如我們所描述的架構的討論，PostgreSQL的性能開始凸顯,當索引過大而不適合在內存中時.

特別地，每當插入新行時，數據庫需要更新每個表的列索引（例如，B樹），這將涉及磁盤的頁交換。利用更大的內存來只能延緩上述情況的發生，每秒10K-100K +行的吞吐量可能會下降到每秒數百行。

在單機情況下,TimescaleDB通過對時空分區的充分利用來解決上述問題。而且對新數據寫入的表都集中在的保留在內存中的表，因此更新任何輔助索引也是快速的。

下圖顯示了這種方法的明顯優勢。下圖中數據達到10億行（在單臺計算機上）,模擬了一個常見的監視情況，數據庫客戶端插入包含時間的中等大小的一批數據，包含設備的標簽集和多個屬性（10個）。該實驗是在具有網絡連接SSD存儲的標準Azure VM（DS4 v2，8內核）上執行的。

PostSql vs timescale

我們觀察到，PostgreSQL和TimescaleDB在行數20M時,吞吐量基本一致（分別為106K和114K）開始，每秒超過1M個屬性。然而，當數據打到50M行，PostgreSQL的性能開始急劇下降。在最后100M行的平均值只有5K行/秒，而TimescaleDB保留其111K行/秒的吞吐量。

總之，加載10億行數據耗費的時間,timescale基本是postsql的1/15,在大數據的情況下,timescale的吞吐量是postsql的20倍.

上圖顯示了,即使使用單磁盤，它也能保持其超過10B行的持續性能。

此外，有用戶表示在千億級別的數據量上,依然能保持上述穩定性.

超凡的查詢性能

在單磁盤機上，PostgreSQL和TimescaleDB的簡單查詢執行索引查找或表掃描的效率相似。

例如，在具有時間索引，主機名和cpu使用情況信息的100M行表上，以下查詢對于每個數據庫將需要少于5ms：

SELECT date_trunc('minute', time) AS minute, max(user_usage) FROM cpu WHERE hostname = 'host_1234' AND time >= '2017-01-01 00:00' AND time < '2017-01-01 01:00' GROUP BY minute ORDER BY minute;

涉及對索引進行基本掃描的類似查詢性能基本一樣：

SELECT * FROM cpu
  WHERE usage_user > 90.0
    AND time >= '2017-01-01' AND time < '2017-01-02';

涉及時間的GROUP BY查詢(在時間導向的分析中很常見) ,會在TimescaleDB中表現出卓越的性能。

例如，下面的查詢語句涉及33M行數據,當整個表為100M行時,timescale能夠快5倍,當為1billion行時,快2倍。

SELECT date_trunc('hour', time) as hour,
    hostname, avg(usage_user)
  FROM cpu
  WHERE time >= '2017-01-01' AND time < '2017-01-02'
  GROUP BY hour, hostname
  ORDER BY hour;

此外，在timescale中,一些特別是時間排序的查詢會表現的更好.

例如，TimescaleDB引入了一個基于時間的“合并添加”優化，以最大限度地減少執行以下操作數量（時間已經被排序）。對于我們的100M行的表，timescale比postgresql快296倍（82MS與32566ms）。

SELECT date_trunc('minute', time) AS minute, max(usage_user)
  FROM cpu
  WHERE time < '2017-01-01'
  GROUP BY minute
  ORDER BY minute DESC
  LIMIT 5;

我們將盡快發布PostgreSQL和TimescaleDB之間更完整的基準比較，以及能夠重復我們的基準測試的軟件。

從我們的查詢基準高層結果是，我們試圖嘗試了所有的查詢,TimescaleDB達到或者相似或更好（或大大優于）的性能,相比PostgreSQL的。

與PostgreSQL相比，TimescaleDB的代價是稍微復雜的前期規劃（因為單個hypertable可以由許多塊組成）。這可以轉換為幾毫秒的計劃時間，這對于非常低延遲的查詢（<10ms）可能會造成不成比例的影響。

面向時間的功能

TimescaleDB還包括一些在傳統關系數據庫中沒有的面向時間的功能。這些包括特殊查詢優化（如上面的合并增加），為面向時間的查詢提供了一些巨大的性能改進，以及其他面向時間的功能（其中一些列在下面）。

面向時間的分析

TimescaleDB包括新的面向時間的分析，包括以下一些功能：

• Time bucketing?:強大的data_func 函數,它允許任意的時間間隔（例如，5分鐘，6小時等），以及靈活的分組和偏移，而不是僅僅秒，分，小時等.
• ?Last? and ?first? aggregates: ：這些功能讓你得到一個基于其他列排序的數據。例如，last(temperature, time)將一組（例如，一小時）內返回基于時間最新的溫度值。

這些類型的功能非常適合的面向時間查詢。以下財務查詢，例如打印每個資產的開倉，收盤，高價和低價。

SELECT time_bucket('3 hours', time) AS period
    asset_code,
    first(price, time) AS opening, last(price, time) AS closing,
    max(price) AS high, min(price) AS low
  FROM prices
  WHERE time > NOW() - interval '7 days'
  GROUP BY period, asset_code
  ORDER BY period DESC, asset_code;

last函數，通過第二列進行排序,完成一些強大的類型的查詢。例如，在財務報告中常見的一種技術是“雙模式”，分別有觀察的時間，觀察記錄相關的時間。在這樣的模型，更正插入一個新行（具有更近time_recorded場），不替換現有的數據。

以下查詢返回每個資產的每日價格，按最新記錄價格排序。

SELECT time_bucket('1 day', time) AS day,
    asset_code,
    last(price, time_recorded)
  FROM prices
  WHERE time > '2017-01-01'
  GROUP BY day, asset_code
  ORDER BY day DESC, asset_code;

面向時間的數據管理

TimescaleDB還提供了一些在PostgreSQL中不具備的數據管理功能。例如，當處理時間序列數據時，數據通常很快地建立起來。所以，你可能要寫一個數據持久策略“只存一周的數據”.

事實上，這與持續聚合相結合是很常見的，因此您可以保留兩個超級表：一個具有原始數據，另一個具有已經被累積成小時或小時聚合的數據。然后，您可能需要在兩個（超）表上定義不同的保留策略，從而保存聚合數據的時間更長。

TimescaleDB允許舊數據的在塊級別的刪除，而不是在該行級別，通過它的drop_chunks()功能。

SELECT drop_chunks(interval '7 days', 'conditions');

這將從超級表“條件”中刪除所有塊（文件），只能包含比此持續時間更早的數據，而不是刪除塊中的任何單獨數據行。這樣可以避免底層數據庫文件的碎片化，反過來又避免了在非常大的表格中可能會非常昂貴的抽真空的需要。

和nosql進行比較

與一般的NoSQL數據庫（例如MongoDB，Cassandra）或更專門的面向時間（例如InfluxDB，KairosDB）相比，TimescaleDB提供了定性和定量的區別：

• 普通SQL：TimescaleDB為您提供了標準的SQL查詢時間序列數據。大多數（全部）NoSQL數據庫需要學習新的查詢語言或使用最多的“SQL-ish”（這仍然打破了與現有工具的兼容性）。
• 操作簡潔性：隨著TimescaleDB，您只需要管理一個數據庫，你的關系和時間序列數據。否則，用戶經常需要將數據分為兩個數據庫：“正常”關系數據庫和第二個時間序列數據庫。
• JOIN的可以在關系數據和時間序列數據進行。
• 查詢性能是多樣化組查詢的速度更快。NoSQL數據庫上更復雜的查詢通常很慢或全表掃描，而一些數據庫甚至不能支持許多自然查詢。
• 管理如PostgreSQL和繼承其用于多種多樣的數據類型和索引（B樹，哈希，范圍，布林，依據，GIN）的支持。
• 地理空間數據的原生支持：存儲在TimescaleDB可以利用的PostGIS的幾何數據類型，索引和查詢數據。
• 第三方工具：TimescaleDB支持任何講SQL，包括像的Tableau BI工具。

當不使用TimescaleDB？

那么再一次，如果下列任何一個是真的，你可能不適合用TimescaleDB：

• 簡單的讀需求：如果你只是想快速鍵值查找或單列匯總，內存或面向列數據庫可能更合適。前者顯然不會擴展到相同的數據量，然而，后者的性能顯著低于更復雜的查詢。
• 非常稀疏的或非結構化數據：雖然TimescaleDB利用的PostgreSQL支持JSON / JSONB格式和相當有效地處理稀疏性（位圖NULL值），無模式的體系結構在某些情況下更合適。
• 要求較高的數據壓縮率：測試表明timescale在ZFS上有4倍左右的壓縮率，經過壓縮優化的列存儲數據庫可能更適合于較高的壓縮率。
• 偶發或離線分析：如果緩慢的響應時間是可以接受的（僅限于少數預先計算的指標或快速的響應時間），并且沒有數據的高并發訪問，可避免使用數據庫，而只是將數據存儲在分布式文件系統中。