InfluxDB，TimescaleDB和QuestDB三種時序資料庫的比較

在過去的十年間，我們親歷了關係型、非關係型、線上分析處理(OLAP)型、以及線上事務處理(OLTP)型資料庫的市場之爭，也注意到了諸如：Snowflake、MongoDB、Cockroach Labs、以及Neo4j等新型資料庫的產生和發展。

而根據DB-Engines的一項針對資料庫管理系統調查的統計(如下圖所示)，時序型資料庫(time series database，TSDB)是自2020年以來，增長最快的資料庫類型之一。

為什麼要使用時序資料庫?

時序資料庫是針對攝取、處理和儲存帶有時間戳資料進行優化過的資料庫。此類資料可能包括來自伺服器和應用程式的參數指標、來自物聯網感測器的讀數、網站或應用程式上的使用者互動、以及金融市場上的各種交易活動。

此處的時序資料通常具有如下屬性特徵：

• 每個資料點都包含了用於索引、聚合、以及取樣的時間戳。此類資料往往是多維的、且相關的。

• 它們主要以高速寫入(或稱：攝取)的方式，來捕獲高頻的資料。

• 資料的彙總檢視(例如：降取樣、聚合檢視或趨勢線)可以提供比單個數據點更多的洞見。例如，考慮到網路的不穩定性、或感測器讀數可能出現的異常，我們需要為在一段時間內，針對超過預定閾值的某些平均值設定警報，而並非僅針對單個數據點。

• 通常需要獲取在一段時間內訪問某類資料(例如，獲取過去一週內的點選率資料)，以供深入分析。

雖然其他類型的資料庫，也可以在一定程度上處理時序資料，但是TSDB可以在設計上，針對上述資料特性，更有效地處理那些隨著時間的推移，而開展的各類資料攝取、壓縮、以及聚合活動。

如今隨著雲端計算、物聯網、以及機器學習對於時序資料需求的持續爆炸式增長，軟體架構師們應該如何選擇TSDB呢?本文將綜合比較市場上最為流行的三種TSDB--InfluxDB，TimescaleDB和QuestDB，以幫助您做出明智的選擇。

InfluxDB

於2013年被首次釋出的InfluxDB，是TSDB領域的領導者。如下圖所示，它甚至超越了之前的Graphite和OpenTSDB。與許多開源(OSS)資料庫類似，InfluxDB不但能夠為單個節點提供MIT許可，而且提供了InfluxDB Cloud付費計劃，以及為企業級使用者提供了叢集、以及生產環境就緒(production-ready)等功能。

圖片來源：DB-engines

如下圖所示，在2019年釋出InfluxDB 2.x之前，InfluxDB平臺是由TICK技術棧所組成，即：Telegraf(收集和報告參數指標的代理)、InfluxDB、Chronograf(從InfluxDB處查詢資料的介面)、以及Kapacitor(實時資料流的處理引擎)。InfluxDB 1.x主要通過社群和整合，收集、儲存和檢視來自伺服器和Web應用的時序資料指標。

圖片來源：Influxdata

InfluxDB 2.x從本質上簡化了整體架構。它將TICK棧捆綁到了單個二進位制檔案中，並且引入了一些新的功能，來執行收集(如：原生的Prometheus插件)、組織(如：各種組織和儲存桶)、視覺化(如：資料瀏覽器)資料、及其Flux語言。

在介紹InfluxDB的工作原理之前，讓我們先了解如下三個關鍵概念：

• 資料模型(標籤集模型)：除了時間戳欄位，其實每個資料元素還會包含各種標籤(如：可選的、已被索引的元資料欄位)、欄位(如：鍵和值)、以及指標(標籤、欄位和時間戳的容器)。下圖示例展示了由科學家Anderson和Mullen在Klamath和Portland兩地採集到的、蜜蜂和螞蟻的數量普查資料。此處的位置(location)和科學家(scientist)標籤，被當作蜜蜂和螞蟻普查範圍內的「欄位/值(field/value)」對。

有關蜜蜂和螞蟻普查資料的示例：

• 資料模式(TSM & TSI)：是一些儲存在時間結構合併樹(time-structured merge tree，TSM)和時序索引(time series index，TSI)檔案中的資料元素。其中，TSM可以被認為是具有預寫日誌(write-ahead log，WAL)和類似於SSTable只讀檔案的LSM樹。這些檔案通常是經過排序和壓縮的。而TSI則是可供InfluxDB記憶體對映的磁碟檔案索引。它可以讓作業系統以最少最近使用(Least Recently Used，LRU)記憶體的方式，來幫助處理具有高基數(high cardinality)的資料集(如，集合中的那些大型元素)。

• Flux指令碼語言：是由InfluxDB開發的一種，可用於協助查詢資料的特定域語言。同時，Flux也帶有一個可協助從SQL資料來源進行查詢的SQL包。

值得注意的是，InfluxDB在攝取資料之前，不會強制執行某種結構模式。相反，它的結構模式是根據輸入的資料被自動創建，以及從標籤和欄位中推斷出來的。這種類似NoSQL的體驗，對於InfluxDB來說有利也有弊。對於那些能夠自動適合此類標記集模型基數的資料集(如：各種物聯網資料、財務資料、以及大多數基礎設施和應用程式的參數指標)而言，InfluxDB非常容易上手。使用者也無需擔心設計模式或索引(如下圖所示)。同時，對於那些目標是創建物理資產數字模型的用例而言，它也是非常實用的。例如，在物聯網中，人們可能需要創建一個數字孿生，來表示一組感測器，並攝取各種有組織的資料。

圖片來源：Influxdata

另一方面，當資料集需要在連續的欄位上建立索引(畢竟InfluxDB不支援數字，而且標籤必須是字元串)或驗證資料時，這種「無模式」就是一種缺陷。此外，由於標籤會被索引，因此如果標籤會經常變化(如，元資料可能在初次攝取後，就發生了變化)的話，僅依賴InfluxDB來推斷模式，就可能會產生昂貴的開銷。

再者，由InfluxDB決定創建其自定義的功能性資料指令碼語言(如Flux)，會給整個生態系統增加一層複雜性。對此，InfluxDB的團隊特別強調了如下兩個從類SQL的InfluxQL轉換為Flux 的驅動場景：

• 時序資料符合基於流的功能處理模型。其中，資料流是從一個輸出轉換為下一個輸出。而由SQL支援的關係代數模型，則不能處理這種操作和函數的連結。

• 通過InfluxDB為時序資料(如，指數級的移動平均)的常見操作，提供一流的支援，而這並非SQL標準的一部分。

當然，使用者需要花時間去熟悉Flux的語法，特別是那些追求簡單的SQL查詢方式，以及不打算學習另一種新語言的使用者，尤為如此。好在InfluxDB已擁有大型的社群與整合，而且Flux能夠與內建的儀表板相結合。

圖片來源：Influxdata

總的來說，在面向基礎設施和應用監控的需求時，InfluxDB能夠與各種資料來源無縫地整合。如果時序資料能夠與標籤集模型非常吻合的話，那麼InfluxDB是一個不錯的選擇。可見，InfluxDB的優缺點可以被歸結為：

• 優點：無模式攝取、龐大的社群、與流行工具相整合。

• 缺點：具有高基數、自定義查詢/處理語言的資料集。

TimescaleDB

InfluxDB需要從頭開始構建新的資料庫和自定義語言，而TimescaleDB則建立在PostgreSQL之上，並添加了一個被稱為超級表(hypertables)的中間層。該層將資料分塊到多個底層資料表中，並將其抽象為一個可用於資料互動的單個大表。

與PostgreSQL的相容性是TimescaleDB的最大賣點。TimescaleDB能夠完全支援所有的SQL功能(如：連線、二級和部分索引)，以及諸如PostGIS之類流行的擴展。作為PostgreSQL的擴展，TimescaleDB不但提供諸如Azure Database for PostgreSQL與Aiven之類的雲託管選項，也提供了針對虛擬機器或容器的各種自管理選項。

圖片來源：Stack Overflow

TimescaleDB最初是針對物聯網平臺，使用InfluxDB來儲存它們的感測器資料。由於網路不穩定性，導致了物聯網時序資料經常會出現擁堵和失序，因此TimescaleDB在高基數方面具有如下三個特點：

• 超級表(Hypertables)：TimescaleDB基於時間列、以及其他「空間」值(如：裝置的UID、位置標識符、或股票代號)，來將其超級表劃分成塊。使用者可以通過配置這些塊，將最新的資料儲存到記憶體中，並按照時間列，將資料非同步壓縮和重新排序至磁碟(並非攝取時間)，以及在節點之間，以事務的方式進行復制和遷移。

• 持續聚合(Continuous Aggregation)：通常，物聯網資料在彙總時更為實用，因此我們無需在每個彙總查詢中去掃描大量的資料。由於支援資料的持續聚合，TimescaleDB能夠快速地計算出諸如：小時平均值、最小值和最大值等關鍵指標(如，計算出下午3點到4點之間的平均溫度，或是下午3點時刻的確切溫度)。這將有助於創建高效能的儀表板與分析結果。

• 資料保留(Data Retention)：在傳統關係型資料庫中，大量的刪除操作往往代價高昂。然而，由於TimescaleDB是以塊的形式儲存資料的，因此它提供了一種drop_chunks的功能，可以在同等開銷下，快速地刪除舊的資料。由於舊資料的相關性會隨著時間的推移而降低，因此TimescaleDB可以通過與長期儲存(如，OLAP或Blob儲存)一起使用，來移走舊的資料，節省磁碟空間，進而為新的資料上提供優異的效能。

就效能而言，時序基準套件(Time Series Benchmark Suite，TTSBS，)詳細比較了TimescaleDB 1.7.1和InfluxDB 1.8.0(兩者都是OSS版本)在插入和讀取延遲方面的效能指標。不過，由於如今兩者都已經擁有了2.x版本，因此該分析略顯過時。從下圖比較結果可知，TimescaleDB會隨著資料基數的增長(以3.5倍速)，提供卓越的效能。

InfluxDB與TimescaleDB的攝取速度比較

TimescaleDB團隊指出，InfluxDB的基於日誌結構合併樹系統(tree-based system，TSI)與TimescaleDB的B樹索引方法，是效能制勝的法寶。當然，我在此並未武斷地認為TimescaleDB在效能方面就一定優於InfluxDB。畢竟效能基準測試受到資料模型、硬體、以及配置等多方面的影響較大。該比較結果僅表明，TimescaleDB可能更適合資料基數較高的物聯網用例(例如，在1000萬臺裝置中，獲悉裝置X的平均功耗)。

總體而言，TimescaleDB非常適合那些尋求顯著效能提升，而不想通過大量重構來遷移現有SQL資料庫的團隊。儘管TimescaleDB相對較新(於2017年首次被髮布)，但是許多物聯網初創公司已在使用它作為中間資料儲存，以快速提取橫跨數月的聚合參數指標，並將舊的資料移至長期儲存處。如果您已經在Kubernetes叢集上運行著 PostgreSQL，那麼安裝TimescaleDB和遷移資料的任務都會相對比較容易。

總的說來，TimescaleDB的優缺點可以被歸結為：

• 優點：與PostgreSQL相容性，可以很好地擴展資料基數，並提供各種部署模型。

• 缺點：結構模式固定，而且在攝取之前增加了複雜性和資料的轉換工作。

QuestDB

對於那些既希望利用InfluxDB內聯協議的靈活性，又熟悉PostgreSQL的人來說，QuestDB(YC S20)作為一個較新的時序資料庫，可以滿足開發者的這兩個要求。它是一個用Java和C++編寫的開源TSDB，雖然被推出僅一年多，但是已排名到了前15。從原理上說，QuestDB是利用記憶體對映檔案，在資料提交到磁碟之前，實現快速讀寫的。

圖片來源：QuestDB

QuestDB通過使用Java和C++，來從頭開始構建資料庫，其主要特徵體現在：

• 效能：解決攝取過程中，特別是在處置高基數的資料集過程中的瓶頸。同時，它還通過順次儲存的時分資料(即，在記憶體中的混洗)，以及僅分析請求的列/分區，而並非以整張表的方式，來支援快速的資料檢索。此外，QuestDB還會運用SIMD指令，實現並行化操作。

• 相容性：QuestDB支援InfluxDB的內聯(inline)協議、PostgreSQL wire、REST API、以及CSV上傳的方式，來攝取資料。那些習慣了其他TSDB的使用者，可以輕鬆地移植他們的現有應用程式，而無需進行大量的重寫工作。

• 通過SQL進行查詢：雖然能夠支援多種攝取機制，但是QuestDB也會使用SQL作為查詢語言，因此使用者無需額外地學習Flux之類的特定域語言。

在效能方面，QuestDB最近釋出了一篇包含基準測試結果的博文，展示了其每秒140萬行的寫入速度。QuestDB團隊在cpu-only的用例中，使用了TSBS基準測試。其中m5.8xlarge在AWS上的例項中，使用了多達14個work(注意：該140萬行的數字，源於使用了AMD Ryzen5的處理器)。

對於具有高基數(超過1000萬)的資料集，QuestDB的效能優於其他TSDB。憑藉著Intel Xeon CPU，其峰值的攝取吞吐量為904k行/秒，並能夠在1000萬臺裝置上使用四個執行緒，且在m5.8xlarge例項上維持約640k行/秒的效能。而當QuestDB在AMD Ryzen 3970X上運行相同的基準測試時，它具有超過1百萬行/秒的攝取吞吐量。

各種TSDB在攝取吞吐量與裝置數量上的比較

同樣，上述基於資料模型和DB調整的效能基準測試也可能不夠客觀，不過它們在一定程度上體現了QuestDB的效能優勢。

QuestDB的另一個有趣的特性是，在攝取中支援InfluxDB內聯協議和PostgreSQL的wire。對於現有的InfluxDB使用者，您可以將Telegraf配置為指向QuestDB的地址和埠。同理，PostgreSQL使用者使用現有的客戶端庫、或JDBC，將資料寫入QuestDB。當然，無論採用何種攝取方法，我們都可以使用標準的SQL去查詢資料。值得注意的是，其API參考頁面上，顯著地列出了一些例外的情況。

作為該領域的新玩家，QuestDB最明顯的缺點是，缺乏生產環境就緒的功能(如，複製、備份與恢復等)。同時，它雖然能與諸如：PostgreSQL、Grafana、Kafka、Telegraf、以及Tableau等流行工具相整合，但是需要花時間偵錯與磨合，方可達到上述其他TSDB的水平。

總的說來，QuestDB的優缺點可以被歸結為：

• 優點：快速攝取(特別是對於具有高基數的資料集)，支援InfluxDB內聯協議和PostgreSQL wire，可以通過標準的SQL查詢資料。

• 缺點：在使用者社群、可用整合、以及對生產環境就緒等方面，都有待改進。

小結

隨著業界對於時序資料需求的不斷增長，專門處理此類資料的TSDB將會被大規模地採用，並引發激烈的競爭。除了上面介紹的三大開源TSDB之外，市場上還有AWS(AWS Timestream)和Azure(Azure Series Insights)等公共雲產品。

與傳統資料庫類似，選擇TSDB主要仍取決於您的業務需求、資料模型、以及資料用例。如果您的資料適合於具有豐富的、整合生態系統的標籤集模型，那麼請選擇InfluxDB。TimescaleDB則非常適合於現有的PostgreSQL使用者。而如果效能是您的首要考慮因素的話，請您考慮選用QuestDB。