TimescaleDB比拼InfluxDB：如何選擇合適的時序數據庫？

時間 2019-11-13

標籤 timescaledb 比拼 influxdb 如何選擇合適時序數據庫欄目 SQL 简体版

原文原文鏈接

https://www.itcodemonkey.com/article/9339.htmlhtml

時序數據已用於愈來愈多的應用中，包括物聯網、DevOps、金融、零售、物流、石油自然氣、製造業、汽車、太空、SaaS，乃至機器學習和人工智能。雖然當前時序數據庫僅侷限於採集度量和監控，可是軟件開發人員已經逐漸明白，他們的確須要一款時序數據庫，真正設計用於運行多種工做負載。git

若是咱們考慮採用一款時序數據庫產品，這可能意味着咱們正面對大量時序數據的快速堆積。咱們須要一個地方對這些時序數據進行存儲和分析。人們此時可能已經認識到，業務的存活嚴重地依賴於所選取的數據庫。github

如何選取時序數據庫算法

在評估工做負載所使用的時序數據庫時，需考慮多個因素：sql

數據模型；數據庫
查詢語言；後端
可靠性；設計模式
性能；數組
生態系統；安全
運維管理；
企業 / 社區的支持狀況.

本文中，咱們將對比兩款業界領先的時序數據庫，TimescaleDB（https://www.timescale.com/?utm_source=timescale-blog&utm_medium=referral&utm_campaign=influx-benchmark-post&utm_content=firstlink）和 InfluxDB（https://www.influxdata.com/），意在爲軟件開發人員正確選取所需的時序數據庫提供參考。

數據庫對比測試一般聚焦於性能基準測試。性能只是總體測試的一部分，若是數據庫的數據模型或查詢語言不匹配，或者由於數據庫缺少可靠性，致使數據庫不能用於生產環境中，那麼不管基準測試的結果多麼好，都毫無心義。考慮到這一點，在深刻開展性能基準測試以前，咱們着手從數據模型、查詢語言和可靠性這三個定量維度對比 TimescaleDB 和 InfluxDB。而後，咱們對整個數據庫生態系統範圍、運維管理以及企業 / 社區支持狀況作出對比。

固然，咱們自己就是 TimescaleDB 的開發人員。讀者可能會認爲咱們的比較會有偏頗。從分析自己看，咱們力圖保持客觀。事實上，咱們也報告了 InfluxDB 優於 TimescaleDB 的一些場景。

此外，此次比較並不是徹底理論上的。咱們的企業最初是一家物聯網平臺。在該平臺上，咱們最初選用 InfluxDB 存儲傳感器數據。可是考慮到本文下面將列出的一些差別之處，咱們發現 InfuxDB 並不能知足咱們的需求。基於此，咱們構建了首個知足需求的時序數據庫 TimescaleDB，並發現了對該數據庫具備需求的其它一些客戶，所以咱們決定將數據庫開源。當前在不到一年半的時間中，TimescaleDB 已經被下載數十萬次，並在全球範圍內的生產環境中使用（更多信息，參見咱們介紹 TimescaleDB 的起源一文 https://blog.timescale.com/when-boring-is-awesome-building-a-scalable-time-series-database-on-postgresql-2900ea453ee2）。

最後，本文意在幫助讀者面對須要使用時序數據庫的狀況時作出最後的判斷。

爲何沒有考慮「可擴展性」因素？

若是讀者仔細查看上面列出的考慮因素清單，就會發現其中缺乏「可擴展性」和「集羣」因素。咱們發現，開發人員在請求任何二者之一時，其實他們真正須要的是性能度量、高可用性和存儲能力的某種組合。咱們認爲，單獨給出上述三方面因素將更具意義，而不是以某個一應俱全的數據一言蔽之。所以在本文中咱們也正是這麼作的。

數據模型

數據庫天性頑固。數據的建模和存儲方式將會影響對數據庫的使用。

在數據模型方面，TimescaleDB 和 InfluxDB 存在兩種徹底不一樣的觀點。TimescaleDB 是一種關係型數據，而 InfluxDB 更多的則是一種定製的、NoSQL 的非關係型數據庫。這意味着 TimescaleDB 是基於關係數據庫模型的，而關係模型在 PostgreSQL、MySQL、SQL Server、Oracle 等數據庫中獲得了廣泛的應用。另外一方面，InfluxDB 提出了本身的數據模型。在本文的對比中，咱們將該數據模型稱爲「Tagset 數據模型」。

關係數據模型

關係數據模型至今已使用了數十年。TimescaleDB 使用關係模型，每一個時序測量值記錄爲單獨一行數據，其中記錄時間的字段後跟隨任意數量的其它字段，字段類型能夠是 float、int、string、boolean、數組和 JSON BLOB 等，甚至是更復雜的數據類型。用戶可在任一字段上建立索引（標準索引），也可對多個字段建立索引（即複合索引），甚至能夠對函數等表達式建立索引，並可限定對部分行建立索引（即部分索引）。任何建了索引的字段均可做爲指向另外一個表的外鍵，進而用於存儲更多的元數據。

下面給出一個例子：

該方法的優勢在於很是靈活。用戶能夠選擇：

根據每次讀取中的數據量和元數據規模，考慮使用寬表仍是窄表。
使用多個索引加速查詢，仍是減小索引的數量以下降磁盤的使用。
在測量數據行中使用非規範化元數據，或是使用獨立的表存儲規範化的元數據。兩種方式均支持在任意時間作更新，雖而後一種方式更易於實現更新。
使用對輸入格式作驗證的嚴格模式，仍是使用無模式的 JSON BLOB 以加快迭代速度。
檢查那些驗證輸入的約束。例如，檢查惟一性、非空值的約束。

該方法的缺點在於，用戶一般須要一開始就肯定模式，並明確地給出是否須要實現索引。

注意：在過去數十年間，關係模型由於其不可擴展性而飽受批評。可是正如咱們曾指出的，此批評並不正確。事實上，關係型數據庫對時序數據的擴展性很好。

Tagset 數據模型

使用 InfluxDB 的 Tagset 數據模型，每一個測量數據中具備一個時間戳，以及一組相關的標籤（稱爲「Tagset」）和一組字段（稱爲「Fieldset」）。Fieldset 表示了實際的測量讀取值，而 Tagset 表示了描述測量數據的元數據。字段數據類型侷限於 float、int、String 和 Boolean，在不重寫數據的狀況下是不能更改的。Tagset 值是作了索引的，而 Fieldset 值並未作索引。Tageset 值老是以字符串表示，不能更新。

下面給出一個例子：

該方法的優勢在於，若是用戶的數據自然適合 Tagset 數據模型，那麼實現起來很是容易，由於用戶不須要操心如何創建模式和索引的問題。另外一方面，該方法的缺點在於不支持建立額外的索引、不能對連續型字段（例如，數值）建立索引、元數據更新滯後、強制數據驗證等。這些不足之處致使該方法的適應性受限。特別是，該模型雖然看上去是「無模式」的，但事實上它會根據輸入數據自動建立底層模式，這種底層模式可能會與所需模式存在差別。

數據模型小結

若是用戶的數據徹底適合 Tagset 數據模型，而且在將來不會發生更改，那麼能夠考慮使用 InfluxDB，它易於上手使用。另外一方面，關係模型更加多樣化，並提供了更多的功能、更加靈活和具備更好的操控性。對於不斷改進的應用，關係模型尤爲適用。在規劃一個系統時，應該考慮當前需求和將來的需求。

查詢語言

在數據庫查詢語言方面，一般存在兩個極端：徹底支持 SQL 和徹底定製語言（也稱爲「NoSQL」）。

更多細節，可參閱咱們近期發佈的 SQL 和 Flux 的對比文章（https://blog.timescale.com/sql-vs-flux-influxdb-query-language-time-series-database-290977a01a8a）。

TimescaleDB 自一開始就堅決地支持 SQL 查詢，以後進一步擴展 SQL 實現簡化的時序分析功能。這使得 TimescaleDB 對用戶學習曲線平滑，並可傳承整個 SQL 生態系統的第三方工具、鏈接器和可視化工具。由此，TimescaleDB 相比其它任什麼時候序數據庫都提供了更爲豐富的功能。

InfluxDB 則不一樣，它採起了介於 SQL 和 NoSQL 之間的作法，使用了一種稱爲「InfluxQL」的類 SQL 查詢語言。近期，它進一步作了定製，提供了新的 Flux 查詢語言。所以，InfluxDB 建立了一種新的查詢語言。據其建立者宣稱，Flux 解決了他們碰到的 SQL 中存在的一些問題（具體細節，參閱 Flux 發行說明（https://www.influxdata.com/blog/why-were-building-flux-a-new-data-scripting-and-query-language/）、Hacker News 討論帖（https://news.ycombinator.com/item?id=17567554），以及咱們的 SQL 和 Flux 的對比文章）。

下面咱們從高層語言上對比兩種語言的語法。以計算指數移動平均爲例：

TimescaleDB（SQL）

SELECT time,
exponential_moving_average(value, 0.5) OVER (ORDER BY time)
FROM metrics
WHERE measurement = 'foo' and time > now() - '1 hour';

InfluxDB（Flux）

from(db:"metrics")
|> range(start:-1h)
|> filter(fn: (r) => r._measurement == "foo")
|> exponentialMovingAverage(size:-10s)

更多細節，可參閱咱們近期發佈的 SQL 和 Flux 的對比文章（https://blog.timescale.com/sql-vs-flux-influxdb-query-language-time-series-database-290977a01a8a）。

總而言之，咱們認爲在不少狀況下，SQL 都是時序數據庫的正確查詢語言（https://blog.timescale.com/why-sql-beating-nosql-what-this-means-for-future-of-data-time-series-database-348b777b847a）。

雖然 Flux 簡化了一些任務，但使用一種定製查詢語言時存在着一些明顯的權衡考慮。事實上，一種新的查詢語言不可避免地會引入大量開銷，並下降可讀性。這會迫使新用戶的學習曲線變陡峭，並缺乏適用的工具。

在不少狀況下，定製查詢語言並不適用。對於企業而言，使用一種新的查詢語言須要從新構建系統，並從頭培訓企業去編寫和閱讀。這在實際中並不可行，尤爲是企業已經在數據庫上使用着一些兼容 SQL 的工具，例如使用 Tableau 作可視化。

這正是數據架構中查詢語言迴歸 SQL 的緣由所在。

可靠性

數據庫的另外一個基本規則是，它不該丟失或損壞數據。從這個維度看，TimescaleDB 和 InfluxDB 所採用的方法存在着明顯的差別，進而對可靠性有着不一樣的影響。

InfluxDB 從一開始曾試圖使用 Go 完整地重寫整個數據庫。事實上在 0.9 版發佈後，InfluxDB 更加堅決了這一決策方向，進而徹底重寫了後端存儲引擎（Influx 的早期版本意圖發展爲可插拔使用 LevelDB，RocksDB 等後端）。該決策的確提供了一些切實的優勢。例如，開發人員能夠構建特定於問題域的壓縮算法，以更適合特定用例。InfluxDB 就使用了 Facebook 的 Gorilla 編碼。

然而，這些設計決策對可靠性形成了很嚴重的影響。首先，InfluxDB 必須本身實現全套的容錯機制，包括複製，高可用性和備份 / 恢復等。其次，InfluxDB 必須負責其磁盤可靠性。例如，確保其全部數據結構都是持久的，可以抵禦出現故障時的數據損壞問題（甚至抵禦在故障恢復期間出現故障）。

另外一方面，TimescaleDB 的架構決策使得其能夠利用過去 25 年多艱苦、細緻的工程成果。整個 PostgreSQL 社區已經構建了堅如磐石的數據庫，可真正支持關鍵任務應用。

事實上，這是 TimescaleDB 聯合創始人曾發帖「變無趣爲有趣」（https://blog.timescale.com/when-boring-is-awesome-building-a-scalable-time-series-database-on-postgresql-2900ea453ee2）所闡述的一個核心理念。無狀態微服務可能會崩潰並重啓，或是易於向上和向下擴展。事實上，這正是整個「面向可恢復的計算」（recovery-oriented computing）的理念，也是新的「無服務器」設計模式背後的理念。一個數據庫須要實際去保存數據，而且不該因處於某種被破壞的狀態而在凌晨 3 點叫醒用戶。

回頭對比這兩種可靠性

首先，程序可能崩潰，服務器可能會碰上硬件或電源故障，磁盤可能出現故障或遭受損壞。咱們能夠緩解這些風險，例如採用強大的軟件工程實踐、不間斷的電源、磁盤 RAID 等。可是風險是不可能完全消除的，這正是系統運行的真實狀況。爲此，數據庫已構建了一系列機制以進一步下降此類風險，包括：流複製爲副本、完整的快照備份和恢復、流備份、強大的數據導出工具等。

TimescaleDB 在設計上考慮了利用 Postgres 生態系統提供的全套工具，它們通過了嚴格的測試，而且都可用於開源系統中。其中包括：流複製實現高可用性和只讀副本、pg_dump 和 pg_recovery 實現完整的數據庫快照、pg_basebackup 和日誌傳送 / 流傳輸實現增量備份和任意時間點恢復，WAL-E 實現連續存檔到雲存儲，以及強大的 COPY FROM 和 COPY TO 工具實現快速導入 / 導出各類格式的數據。

另外一方面，InfluxDB 則必須從零開始構建全部這些工具。事實上，時至今日 InfluxDB 依然沒有提供全部這些功能。雖然它一開始在其開源版本中提供了複製和高可用性，但隨後將此從開源版本中抽取出來，置於企業版產品中。它的備份工具可以執行完整快照和基於時間點的恢復，最近才增長了對手動增量備份的一些支持（也就是說，基於數據庫時間範圍執行增量備份的方法風險更大，由於時間戳數據可能會無序到達，所以從某一時間段開始的增量備份可能並未反映出晚到的數據）。InfluxDB 在易於安全輸出大量數據上的能力也很是有限。咱們聽過許多用戶（包括一些曾有此經歷的 Timescale 工程師）必須編寫自定義腳本才能安全地導出數據。若是請求超過數萬個數據點，就會致使數據庫出現內存不足錯誤和崩潰。

其次，數據庫須要提供基於磁盤的強大可靠性和持久性。一旦數據庫提交寫入存儲，那麼數據就會安全地保存到磁盤上。實際上，對於數據量很是大的數據，同一觀點也適用於索引結構，不然索引可能須要數小時乃至很多天才能恢復。鑑於此，文件系統從使人痛苦的 fsck 恢復轉向日誌機制，這是有十分充分的理由的。

在 TimescaleDB 中，咱們決定不從最底層更改 PostgreSQL 的存儲，也不干涉其預寫日誌的正常功能（WAL 確保了一旦寫入被接受，就會被寫入到磁盤日誌，以確保安全性和持久性，甚至在數據寫入到最終位置而且全部索引均安全更新以前）。這些數據結構對確保一致性和原子性相當重要，它們能夠防止數據丟失或損壞，並確保可安全恢復。這正是數據庫社區（和 PostgreSQL）的努力結果。想象一下，若是數據庫正處於崩潰中恢復的過程當中，再次發生了崩潰（隨後嘗試恢復），那麼這時會發生什麼？

而 InfluxDB 必須從零開始設計和實現全部這些功能。這在數據庫領域中是一個衆所周知的難題，一般須要幾年甚至幾十年時間才能獲得正確的解決方案。一些度量存儲儘管會偶爾丟失數據，但這徹底是能夠接受的。咱們已經看到在一些不能接受度量存儲丟失數據的環境中使用了 TimescaleDB。事實上，在咱們全部的用戶和部署中只有一份數據被破壞的報告，而調查結果代表這是由用戶所使用的商業 SAN 存儲致使的錯誤，而非 TimescaleDB 自己，而且用戶繼而從備份中成功恢復。而 InfluxDB 論壇則充斥着大量抱怨，例如「數據庫在重啓後丟失」，「高吞吐率期間發生數據丟失」，「InfluxDB 數據庫發生數據丟失」，「因磁盤損壞發生崩潰後，數據庫無響應」，「恢復多個數據庫後，發生數據混亂」，不勝枚舉。

這些挑戰和問題並不是 InfluxDB 所獨有的，每一個可靠的有狀態服務開發人員都必須努力去解決這些問題。每一個數據庫都會經歷不時丟失數據的時期，的確很是難以讓系統的各個邊緣均正確運行。最終，全部這些邊緣狀況都會對運營商形成困擾。但 PostgreSQL 已在 20 世紀 90 年代經歷過這一時期，而 InfluxDB 則仍然須要去解決這些問題。

所以，這些架構決策使得 TimescaleDB 可以站在衆所周知的「巨人肩膀」上，於是提供了遠超當前水平的可靠性。實際上，就在咱們於 2017 年 4 月首次發佈 TimescaleDB 的一個月後，它就被部署用於歐洲和拉丁美洲的 47 家發電廠的儀表盤顯示，直接面對操做人員。所以，雖然 InfluxDB（2013 年發佈）先於 TimescaleDB（2017 年發佈）數年發佈，但咱們相信它仍然須要多年的專一工程才能遇上，尤爲是考慮到它是從零開始構建的。

性能

下面，咱們經過對兩個數據庫作一系列插入和讀取操做，以定量分析的方式提供確切的數值對比。

注意：咱們近期以開源時序數據基準測試集（TSBS，Time Series Benchmark Suite）的方式，發佈了下面基準測試中全部使用的全部代碼和數據（參見 Github 聲明 https://github.com/timescale/tsbs）。

咱們對每一個數據庫作了以下步驟的操做：

使用 TimescaleDB 版本 0.10.1(https://github.com/timescale/timescaledb/releases/tag/0.10.1) 和 InfluxDB 版本 1.5.2(https://github.com/influxdata/influxdb/releases/tag/v1.5.2)；
一臺遠程客戶端機器，一臺數據庫服務器，位於同一雲數據中心；
Azure 實例：標準（Standard）DS4 v2，其中 8 個 vCPU，28 GB 的內存；
4 個 1 TB 磁盤，配置爲 raid0，使用 EXT4 文件系統；
兩個數據庫都可使用了所有的可用內存；
數據集：100 至 4000 個模擬設備中 1 到 10 個 CPU 在 3 天中每 10 秒生成的的度量數據。約 1 億個讀取時間點，約 10 億個度量值；
對於插入操做，均使用 1 萬批處理規模；
對於 TimescaleDB，設置塊（Chunk）大小爲 12 小時，合計 6 個塊（具體細節參閱此處）。
對於 InfluxDB，咱們啓用了時序索引（TSI，Time Series Index）。
插入性能

對於插入操做，結果十分清楚：對於數據規模很小的工做負載，InfluxDB 性能超出 TimescaleDB 兩倍。可是，隨着數據規模的增長，因爲 InfluxDB 使用了時間結構歸併樹（相似於日誌結構歸併樹，在數據規模增長時性能降低），其性能迅速降低。這固然是合理的，由於數據規模問題正是 InfluxDB 的痛點。與之相對比，TimescaleDB 在數據規模增加時性能降低平緩，很快在插入性能上超過了 InfluxDB。

這就是說，用戶須要仔細考慮對數據插入的需求。若是插入性能嚴重低於基準測試狀況（例如，達到每秒 2000 行），那麼插入性能並不是應用的瓶頸所在，這種比較毫無心義。

注意：所用的度量數據是按每秒一行數據測量的（對於 InfluxDB，定義爲一組在同一時間記錄的度量）。若是用戶須要每行採集多種度量，那麼每秒的度量總數會更高。例如，在咱們的「4000 臺設備的 10 種度量」測試中，能夠直接使用「每秒行數」10 種度量的方式計算，獲得 TimescaleDB 每秒 144 萬度量值，InfluxDB 每秒 56 萬度量值。

插入性能小結

對於插入操做，在數據量不大的工做負載上（例如，100 臺設備發送一種度量），InfluxDB 的性能優於 TimescaleDB。
隨着數據類的增長，InfluxDB 的插入性能要比 TimescaleDB 降低迅速。
對於必定數據規模乃至更大數據規模的工做負載（例如，100 臺設備發送 10 種度量），TimescaleDB 的性能要優於 InfluxDB。
用戶應瞭解自身的需求。這些侷限可能並不是應用的瓶頸所在。

讀取延遲狀況

對於讀取（即查詢）延遲，測試結果略微複雜。這是由於不一樣於測試主要與數據規模有關（可能也包括批處理規模），查詢的種類繁多，尤爲是對於 SQL 這樣強大的查詢語言。鑑於此，咱們發現測試讀取延遲的最好方法是採用用戶所要使用的實際查詢。

這就是說，咱們使用大範圍的查詢以實現通用查詢模式的最小化。下面給出的測試結果，是使用在插入測試中使用的同一工做賦值獲得的。圖表中的延遲單位均爲微秒，多出的一行顯示了 TimescaleDB 對比 InfluxDB 的相對性能（橙色顯示 TimescaleDB 更快，而藍色顯示 InfluxDB 更快）。

基本上卷（SIMPLE ROLLUP）操做

對於按時間的基本上卷（即 GROUPBY）聚合度量，在聚合一臺主機 12 小時內的一個度量時，或是多臺主機的多個度量時，TimescaleDB 一般在小規模或中等規模數據量上要優於 InfluxDB，可是在大規模數據中狀況則相反。惟一特例在於聚合單臺主機一小時內的多個度量時，不管度量數量如何，TimescaleDB 的性能要優於 InfluxDB。當聚合多臺主機的單個度量時，InfluxDB 的性能要優於 TimescaleDB。二者間的差距隨度量數增加而下降。

雙重上卷（DOUBLE ROLLUP）操做

對於按時間或其它維度（例如，GROUPBY time 或 deviceID）的雙重上卷聚合度量，當聚合一個度量時，InfluxDB 的性能要優於 TimescaleDB。可是當聚合多個度量時，TimescaleDB 要優於 InfluxDB。

閾值

在基於閾值選取數據行時，TimescaleDB 性能優於 InfluxDB。一個例外狀況是單臺設備提供多種度量數據。

複雜查詢

對於比上卷和閾值更復雜的一些複雜查詢，結果十分明顯：TimescaleDB 性能超出 InfluxDB（一些極端狀況下會超出數千倍）。性能上的絕對差別十分明顯：即使對於一些單度量上卷，InfluxDB 會快數微秒甚至是幾十微秒，可是這種性能上的差別是查詢者所沒法感知的。

一樣對於這些更爲複雜的查詢，TimescaleDB 可提供實時響應（例如，10 到 100 秒甚至是微秒級），而 InfluxDB 可明顯感覺到延遲（數十秒）。值得注意的是，InfluxDB 並不支持所有的複雜查詢，包括多鏈接、窗函數、地理空間查詢等，所以咱們也沒有對這些查詢進行測試。

讀取性能小結

對於簡單查詢，性能有必定的差別。對於部分查詢，一款數據庫的性能要明顯地優於另一款。而其它查詢的性能則取決於數據集中的度量數。可是性能差別的微秒值不超過一位或兩位數。
對於複雜查詢，TimescaleDB 的性能遠優於 InfluxDB，而且支持更普遍的查詢類型。這一性能差別可達在數秒乃至數十秒。
鑑於此，最好的作法是使用用戶計劃執行的查詢作基準測試。

基準測試中的穩定性考慮

須要注意的是，在對 InfluxDB 作基準測試時，即使啓用了 TSI，隨着數據規模的增大，數據庫出現了一些運行問題。特別是當咱們採用更大規模的數據集（超過 10 萬個 Tag）測試時，InfluxDB 在插入和查詢上都出現了問題（TimescaleDB 則未出現問題）。

在數據量不大的狀況下，咱們實現了批量插入 1 萬 Tag 數據到 InfluxDB。可是當數據集增加到 100 萬 Tag 時，數據庫出現超時和出錯問題。咱們不得不將批處理規模降至 1 千到 5 千，並使用客戶端代碼去處理更大數據量對後臺所形成的壓力。咱們必須強制客戶端代碼在請求寫入批處理出錯時休眠等待 20 秒。而使用 TimescaleDB，咱們能夠對大規模數據作大量批處理寫入而不會出現問題。

在使用 InfluxDB 時，從 10 萬規模開始，在一些讀取查詢上出現了問題。InfluxDB 的 HTTP 鏈接會報「End of File」錯誤。爲此咱們檢查了 InfluxDB 服務器，發現 InfluxDB 在執行查詢時消耗了全部可用內存，於是隨後報「Out of Memory」錯誤並崩潰。鑑於 PostgreSQL 支持經過「shared_buffers"和"work_mem」等參數限制內存使用狀況，所以內存一般對於 TimescaleDB 而言並不是問題，即使是面對大規模數據時。

穩定性小結

對於大規模數據（超過 10 萬 Tag），即使啓用了 TSI，InfluxDB 依然存在穩定性和性能上的問題。

生態系統

數據庫自己的功能有限，人們一般會尋求第三方生態系統去實現額外的功能。生態系統的規模和範圍，對一款產品具備很大的影響。

TimescaleDB 採用 SQL 這一策略使得結果截然不同。只要是使用 SQL 的工具，均可以用於 TimescaleDB。與此不一樣，InfluxDB 選定使用非 SQL 的策略使其陷入孤立，並限制了開發人員對其的使用。

具備更寬泛的生態系統，也會簡化產品的部署。例如，若是用戶已經在使用 Tableau 可視化數據，或是使用 Apache Spark 作數據處理，Timescale 徹底可使用兼容的鏈接器實現插入到現有架構中。

下表是對第一方軟件（例如，InfluxData TICK 堆棧組件）和鏈接任一數據庫的第三方工具的不徹底列表。該表顯示了兩款數據庫在生態系統上存在的相對差別。

對於表中列出的開源項目，爲顯示項目的受歡迎程度，咱們在表中以括號中數值形式給出了項目的 GitHub 加星數量。例如，「Apache Kafka (9k+)」。咱們看到，InfluxDB 的一些非官方項目或者是很早推出的（加星不多），或者是不活躍項目（多個月或數年沒有更新）。

查看完整列表

https://docs.google.com/spreadsheets/d/1v4rLgph1LemuJBfh4rZxYTuektWvVF7XQphHi87oSxA/edit#gid=0

運維管理

即使一款數據庫能知足上述全部要求，它仍須要運行起來。這樣，必須有人去作運維。

從咱們的經驗看，運維管理需求一般可歸結爲高可用性、資源（內存、磁盤、CPU）使用狀況和通用工具這三個方面。

高可用性

不管數據庫多麼可靠，節點總會因爲硬件故障、磁盤故障以及其它一些不可恢復的問題而宕機。這時，應確保具備用於故障切換的備用數據庫，以避免發生數據丟失。

TimescaleDB 使用 PostgreSQL 的流備份技術支持高可用。從某種意義上講，開源的 InfluxDB 也經過 InfluxDB-relay 實現高可用，可是該項目看上去已經止步不前（最近更新是在 2016 年 11 月）。當前 InfluxDB 僅在企業版中提供高可用。

資源使用狀況內存使用

對於內存使用，數據規模依然起決定性影響。在下面給出的圖中，咱們使用了測試插入性能的同一工做負載。

當數據規模不大時（100 臺設備發送一種度量），InfluxDB 所需的內存要小於 TimescaleDB。

注意：兩款數據庫在插入一樣規模的數據上使用了不一樣的時間。所以上圖中繪製的線並未同時終止。

可是，隨着數據量的增加（10 萬臺設備發生 10 種度量），InfluxDB 佔用的內存遠超過 TimescaleDB（波動也更劇烈）：

尤爲是正如咱們所說起的，沒有任何方法可限制 InfluxDB TSI 的內存佔用。所以對於更大規模的數據，InfluxDB 會在插入時耗盡內存，這將致使數據庫崩潰並重啓。

磁盤使用

與使用面向列存儲方式的大部分數據庫同樣，InfluxDB 相比起 PostgreSQL 和 TimescaleDB 提供了顯著更優的磁盤壓縮。

對於在基準測試中使用的數據集，下面列出了兩款數據庫對不一樣規模數據的磁盤使用狀況：

100 臺設備 1 種度量 30 天： InfluxDB（12MB） vs. TimescaleDB（700MB） = 59 倍
100 臺設備 10 種度量 30 天： InfluxDB（113MB） vs. TimescaleDB（1400MB） = 12 倍
4000 臺設備 10 種度量 3 天： InfluxDB（769MB） vs. TimescaleDB（5900MB） = 8 倍

注意：磁盤規模的基準測試中使用了 ZFS 文件系統。測試數值中並未包括 WAL 大小，該大小是用戶可配置的。

若是用戶工做負載中的首要需求是磁盤佔用最小化，那麼兩款數據庫的差異很大，應該選用 InfluxDB。

可是正如咱們在前面看到的，根據工做負載不一樣，InfluxDB 可能須要佔用更多的內存。考慮到內存一般比磁盤貴成百上千倍，對於一些工做負載，須要考慮高磁盤佔用和低內存使用的權衡。

TimescaleDB 還支持用戶彈性地擴展一個超表（Hypertable）所關聯的磁盤數量，無需任何數據遷移。該功能可解決高磁盤佔用問題，尤爲是在 SAN 和雲環境中。有一位用戶使用該方法，將單個 TimescaleDB 節點擴展到了 10TB 級。

InfluxDB 磁盤壓縮的另外一個代價是它須要開發人員從頭開始重寫後臺存儲引擎，這對數據庫的可靠性是一個挑戰。

CPU 使用

根據 DNSFilter 所作的對比實驗 (https://blog.dnsfilter.com/3-billion-time-series-data-points-dnsfilter-replaced-influxdb-with-timescaledb-d9f827702f8b) ，TimescaleDB 在資源使用上優於 InfluxDB 達 10 倍（雖然 TimescaleDB 的請求量要高 30%）。

圖片來源：DNSFilter Comparison（2018年3月）

通用工具

在運維 TimescaleDB 時，可使用 PostgreSQL 生態系統中全部經實戰檢驗的工具。例如，使用 pg_dump 和 pg_restore 作備份和恢復，使用 Patroni 實現高可用和故障轉移，使用 Pgpool 實現集羣讀取的負載均衡。因爲 TimescaleDB 的操做相似於 PostgreSQL，用戶的學習曲線很低。TimescaleDB 能夠按 PostgreSQL 的方式「徹底工做」。

在運維 InfluxDB 時，用戶侷限於使用 Influx 團隊構建的工具，包括備份、恢復、內部監控等。

企業 / 社區支持

最後，在選用由某家企業主要開發的開源技術時，用戶也默認地選取了企業提供服務的能力。

鑑於此，咱們比較 Timescale 和 InfluxData 兩家企業在企業規模、成熟度、融資等方面存在的差別。它們分別是 TimescaleDB 和 InfluxDB 的支持企業。

今年一月，Timescale 宣佈融資 1600 萬美圓（組合了 A 輪和種子融資）。同時在今年二月，InfluxData 宣佈完成 3500 萬美圓的 C 輪融資，融資總額達 5990 萬美圓。

這些融資狀況是與每家企業各自的歷史發展密切相關的。TimescaleDB 正式發佈於 2017 年 4 月 4 日（本帖發佈的 1 年 4 個月前）。InfluxDB 的最先發布可回溯至 2013 年 9 月（本貼發佈近五年前）。

不一樣的融資規模和發展歷史，也致使了兩家企業在技術和產品策略上的巨大差別。

InfluxDdata 須要大量融資，構建大規模團隊去實現全部內部需求，並交付可用於生產的數據庫產品。與此不一樣，TimescaleDB 是基於 PostgreSQL 開發的，其工程團隊只需在數據庫基本構建模塊上花費不多精力。所以，儘管 TimescaleDB 的工程團隊規模更小，可是它能夠更多地聚焦於一些與時序工做負載直接相關的高級特性，並提供用戶支持。

TimescaleDB 用更少時間交付比 InfluxDB 更成熟（可能從一些度量上看更爲可靠）的生產級別產品。從這一點上，咱們可進一步感受到差別。

此外，有時數據庫支持並不是來自於企業，而是來自於社區。InfluxData 是從零開始構建社區的，而 Timescale 能夠從 PostgreSQL 社區繼承資源，並用於構建自身的社區。

PostgreSQL 具備很是大的社區。在 StackOverflow 文章中，「PostgreSQL」文章數（截至本貼發表時爲 88245）要比「InfluxDB」文章數（1141）多 77 倍。因爲 TimescaleDB 的運維很是相似於 PostgreSQL，因此不少 PostgreSQL 問題是與 PostgreSQL 密切相關的。即使是一位 TimescaleDB（PostgreSQL）的新用戶，在上手時也會有大量可參考資源。若是用戶已是 PostgreSQL 專家，固然也會熟悉 TimescaleDB 的使用。

目前對用戶來講，Timescale 和 InfluxData 這兩家公司均運做良好。

總結

選擇了一種會限制企業將來發展的技術，這是咱們在業務中可能犯的最壞錯誤，更不用說技術在當前就不適用。這就是爲何咱們要鼓勵讀者在發現數據庫基礎架構崩潰以前，應退後一步並分析所使用的技術棧。

咱們在本文中對 TimescaleDB 和 InfluxDB 作了詳細的比較。咱們並未宣稱本身是 InfluxDB 專家，所以咱們歡迎你們對這裏所作的比較提出建議。總而言之，咱們的目標是儘量透明地瞭解數據模型、方法和分析，並歡迎提供反饋。咱們也鼓勵讀者對本文提供的信息提出疑慮，幫助咱們在將來更好地開展基準測試。

咱們知道，TimescaleDB 並不是惟一的時序解決方案，在一些狀況下它也並不是最適用的。在認可一些替代解決方案可能更可取以前，咱們會努力改進本身的產品。但咱們一直有興趣對 TimescaleDB 解決方案作總體評估，並將繼續與社區分享。