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

?概述

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

易用

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

可擴展

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

可靠性

• 作為PostgreSQL的擴展。
• 受益于20多年的PostgreSQL研究的成功經(jīng)驗（包括流式復(fù)制，備份）
• 靈活的管理選項（與現(xiàn)有的PostgreSQL生態(tài)系統(tǒng)和工具兼容）

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

什么是時序數(shù)據(jù)

時序數(shù)據(jù)和其他數(shù)據(jù)有什么不同?

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

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

但事實上,在許多監(jiān)控應(yīng)用中，不同的數(shù)據(jù)通常被會被一起收集（例如，CPU，存儲器，網(wǎng)絡(luò)統(tǒng)計，電池壽命）。 并且，分別考慮每個指標并不總是有意義的。 所以可以考慮這種的“?更寬”的數(shù)據(jù)模型，保持同時收集的指標之間的關(guān)聯(lián)性。

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

這種類型的數(shù)據(jù)應(yīng)該應(yīng)用更為廣泛，無論是傳感器的溫度讀數(shù)，股票的價格，機器的狀態(tài)，甚至登錄到應(yīng)用程序的數(shù)量。

時間序列數(shù)據(jù)代表系統(tǒng)，過程或行為隨時間變化的數(shù)據(jù)。

時序數(shù)據(jù)的特點

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

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

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

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

時序數(shù)據(jù)無處不在

時間序列數(shù)據(jù)隨處可見，例如。

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

數(shù)據(jù)模型

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

在這里，我們將討論為什么選擇寬表模型，以及我們?nèi)绾瓮扑]使用物聯(lián)網(wǎng)（IoT）的時間序列數(shù)據(jù)。

設(shè)想一下，分布的1000個物聯(lián)網(wǎng)設(shè)備以不同的頻率收采集環(huán)境數(shù)據(jù)。 此數(shù)據(jù)可能包括：

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

采集來的數(shù)據(jù)類似下面的格式:

讓我們?yōu)檫@些數(shù)據(jù)建立模型.

窄表模型

多數(shù)時序數(shù)據(jù)利用以下方式為數(shù)據(jù)建模.

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

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

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

使用我們上面的例子，這種方法將產(chǎn)生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}

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

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

現(xiàn)在，如果您采集的設(shè)備狀態(tài)屬性都是相對獨立的，不屬于某種元數(shù)據(jù)結(jié)構(gòu),這種方法可能是有意義的。

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

• 當free_mem為0時系統(tǒng)的state是什么?
• cpu_1m_avg與ree_mem的變化是否有關(guān)系？
• ocation_id的平均溫度是多少？

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

寬表模型

相比之下，TimescaleDB使用了廣泛的模型，反映了數(shù)據(jù)的本質(zhì)結(jié)構(gòu)。

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

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

當然，這不是一種新的格式：它是通常在關(guān)系數(shù)據(jù)庫中找到的。這也是為什么我們發(fā)現(xiàn)這種格式更直觀。

JOINS的使用

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

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

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

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

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

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

架構(gòu)與概念

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

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

術(shù)語

Hypertables(超級表)

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

幾乎所有與TimescaleDB的用戶交互都是與超級表。創(chuàng)建表和索引，更改表，插入數(shù)據(jù)，選擇數(shù)據(jù)等可以（并且應(yīng)該）全部在hypertable上執(zhí)行。

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

單個TimescaleDB部署可以存儲多個超級表，每個具有不同的結(jié)構(gòu)。

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

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

Chunks(塊)

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

每個塊都使用標準數(shù)據(jù)庫表實現(xiàn)。（在PostgreSQL內(nèi)部組件中，該塊實際上是“父”超級表的“子表”。）

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

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

單節(jié)點與集群

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

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

單節(jié)點分區(qū)的優(yōu)點

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

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

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

和PostgreSQL比較

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

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

高采集率

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

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

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

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

PostSql vs timescale

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

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

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

此外，有用戶表示在千億級別的數(shù)據(jù)量上,依然能保持上述穩(wěn)定性.

超凡的查詢性能

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

例如，在具有時間索引，主機名和cpu使用情況信息的100M行表上，以下查詢對于每個數(shù)據(jù)庫將需要少于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中表現(xiàn)出卓越的性能。

例如，下面的查詢語句涉及33M行數(shù)據(jù),當整個表為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中,一些特別是時間排序的查詢會表現(xiàn)的更好.

例如，TimescaleDB引入了一個基于時間的“合并添加”優(yōu)化，以最大限度地減少執(zhí)行以下操作數(shù)量（時間已經(jīng)被排序）。對于我們的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;

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

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

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

面向時間的功能

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

面向時間的分析

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

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

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

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函數(shù)，通過第二列進行排序,完成一些強大的類型的查詢。例如，在財務(wù)報告中常見的一種技術(shù)是“雙模式”，分別有觀察的時間，觀察記錄相關(guān)的時間。在這樣的模型，更正插入一個新行（具有更近time_recorded場），不替換現(xiàn)有的數(shù)據(jù)。

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

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;

面向時間的數(shù)據(jù)管理

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

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

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

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

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

和nosql進行比較

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

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

當不使用TimescaleDB？

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

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