在過去的十年間，我們親歷了關系型、非關系型、在線分析處理(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)等功能。
如下圖所示，在2019年發布InfluxDB 2.x之前，InfluxDB平台是由TICK技術棧所組成，即：Telegraf(收集和報告參數指標的代理)、InfluxDB、Chronograf(從InfluxDB處查詢數據的接口)、以及Kapacitor(實時數據流的處理引擎)。InfluxDB 1.x主要通過社區和集成，收集、存儲和查看來自服務器和Web應用的時序數據指標。
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非常容易上手。用戶也無需擔心設計模式或索引(如下圖所示)。同時，對於那些目標是創建物理資產數字模型的用例而言，它也是非常實用的。例如，在物聯網中，人們可能需要創建一個數字孿生，來表示一組傳感器，並攝取各種有組織的數據。
另一方面，當數據集需要在連續的字段上建立索引(畢竟InfluxDB不支持數字，而且標簽必須是字符串)或驗證數據時，這種“無模式”就是一種缺陷。此外，由於標簽會被索引，因此如果標簽會經常變化(如，元數據可能在初次攝取后，就發生了變化)的話，僅依賴InfluxDB來推斷模式，就可能會產生昂貴的開銷。
再者，由InfluxDB決定創建其自定義的功能性數據腳本語言(如Flux)，會給整個生態系統增加一層復雜性。對此，InfluxDB的團隊特別強調了如下兩個從類SQL的InfluxQL轉換為Flux 的驅動場景：
- 時序數據符合基於流的功能處理模型。其中，數據流是從一個輸出轉換為下一個輸出。而由SQL支持的關系代數模型，則不能處理這種操作和函數的鏈接。
- 通過InfluxDB為時序數據(如，指數級的移動平均)的常見操作，提供一流的支持，而這並非SQL標准的一部分。
當然，用戶需要花時間去熟悉Flux的語法，特別是那些追求簡單的SQL查詢方式，以及不打算學習另一種新語言的用戶，尤為如此。好在InfluxDB已擁有大型的社區與集成，而且Flux能夠與內置的儀表板相結合。
總的來說，在面向基礎設施和應用監控的需求時，InfluxDB能夠與各種數據源無縫地集成。如果時序數據能夠與標簽集模型非常吻合的話，那么InfluxDB是一個不錯的選擇。可見，InfluxDB的優缺點可以被歸結為：
- 優點：無模式攝取、龐大的社區、與流行工具相集成。
- 缺點：具有高基數、自定義查詢/處理語言的數據集。
TimescaleDB
InfluxDB需要從頭開始構建新的數據庫和自定義語言，而TimescaleDB則建立在PostgreSQL之上，並添加了一個被稱為超級表(hypertables)的中間層。該層將數據分塊到多個底層數據表中，並將其抽象為一個可用於數據交互的單個大表。
與PostgreSQL的兼容性是TimescaleDB的最大賣點。TimescaleDB能夠完全支持所有的SQL功能(如：連接、二級和部分索引)，以及諸如PostGIS之類流行的擴展。作為PostgreSQL的擴展，TimescaleDB不但提供諸如Azure Database for PostgreSQL與Aiven之類的雲托管選項，也提供了針對虛擬機或容器的各種自管理選項。
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倍速)，提供卓越的性能。
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通過使用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百萬行/秒的攝取吞吐量。
同樣，上述基於數據模型和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。