【51CTO.com快譯】在過去的十年間，我們親歷了關系型、非關系型、在線分析處理(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的平均功耗)。具體有關這兩個數據庫之間的深度比較，請參見由Timescale自行提供的《TimescaleDB與InfluxDB的比較》。

總體而言，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。

原文標題：Comparing InfluxDB, TimescaleDB, and QuestDB Time Series Databases，作者: Yitaek Hwang

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】

原文鏈接：https://database.51cto.com/art/202107/675330.htm