時序資料已用於愈來愈多的應用中，包括物聯網、DevOps、金融、零售、物流、石油自然氣、製造業、汽車、太空、SaaS，乃至機器學習和人工智慧。雖然當前時序資料庫僅侷限於採集度量和監控，可是軟體開發人員已經逐漸明白，他們的確須要一款時序資料庫，真正設計用於執行多種工做負載。git 若是咱們考慮採用一款時序資料庫產品，這可能意味著咱們正面對大量時序資料的快速堆積。咱們須要一個地方對這些時序資料進行儲存和分析。人們此時可能已經認識到，業務的存活嚴重地依賴於所選取的資料庫。

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

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

如何選取時序資料庫

在評估工作負載所使用的時序資料庫時，需考慮多個因素：

• 資料模型；

• 查詢語言；

• 可靠性；

• 效能；

• 生態系統；

• 運維管理；

• 企業 / 社群的支援情況.

本文中，我們將對比兩款業界領先的時序資料庫，TimescaleDB（https://www.timescale.com） 和 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 解決方案做整體評估，並將繼續與社群分享。

原文連結:TimescaleDB比拼InfluxDB：如何選擇合適的時序資料庫?

本文來自部落格園，作者：古道輕風，轉載請註明原文連結：https://www.cnblogs.com/88223100/p/TimescaleDBvsInfluxDB.html