[[414208]]

【51CTO.com快譯】在過(guò)去的十年間，我們親歷了關(guān)系型、非關(guān)系型、在線分析處理(OLAP)型、以及在線事務(wù)處理(OLTP)型數(shù)據(jù)庫(kù)的市場(chǎng)之爭(zhēng)，也注意到了諸如：Snowflake、MongoDB、Cockroach Labs、以及Neo4j等新型數(shù)據(jù)庫(kù)的產(chǎn)生和發(fā)展。而根據(jù)DB-Engines的一項(xiàng)針對(duì)數(shù)據(jù)庫(kù)管理系統(tǒng)調(diào)查的統(tǒng)計(jì)(如下圖所示)，時(shí)序型數(shù)據(jù)庫(kù)(time series database，TSDB)是自2020年以來(lái)，增長(zhǎng)最快的數(shù)據(jù)庫(kù)類型之一。

為什么要使用時(shí)序數(shù)據(jù)庫(kù)?

時(shí)序數(shù)據(jù)庫(kù)是針對(duì)攝取、處理和存儲(chǔ)帶有時(shí)間戳數(shù)據(jù)進(jìn)行優(yōu)化過(guò)的數(shù)據(jù)庫(kù)。此類數(shù)據(jù)可能包括來(lái)自服務(wù)器和應(yīng)用程序的參數(shù)指標(biāo)、來(lái)自物聯(lián)網(wǎng)傳感器的讀數(shù)、網(wǎng)站或應(yīng)用程序上的用戶交互、以及金融市場(chǎng)上的各種交易活動(dòng)。

此處的時(shí)序數(shù)據(jù)通常具有如下屬性特征：

• 每個(gè)數(shù)據(jù)點(diǎn)都包含了用于索引、聚合、以及采樣的時(shí)間戳。此類數(shù)據(jù)往往是多維的、且相關(guān)的。
• 它們主要以高速寫(xiě)入(或稱：攝取)的方式，來(lái)捕獲高頻的數(shù)據(jù)。
• 數(shù)據(jù)的匯總視圖(例如：降采樣、聚合視圖或趨勢(shì)線)可以提供比單個(gè)數(shù)據(jù)點(diǎn)更多的洞見(jiàn)。例如，考慮到網(wǎng)絡(luò)的不穩(wěn)定性、或傳感器讀數(shù)可能出現(xiàn)的異常，我們需要為在一段時(shí)間內(nèi)，針對(duì)超過(guò)預(yù)定閾值的某些平均值設(shè)置警報(bào)，而并非僅針對(duì)單個(gè)數(shù)據(jù)點(diǎn)。
• 通常需要獲取在一段時(shí)間內(nèi)訪問(wèn)某類數(shù)據(jù)(例如，獲取過(guò)去一周內(nèi)的點(diǎn)擊率數(shù)據(jù))，以供深入分析。

雖然其他類型的數(shù)據(jù)庫(kù)，也可以在一定程度上處理時(shí)序數(shù)據(jù)，但是TSDB可以在設(shè)計(jì)上，針對(duì)上述數(shù)據(jù)特性，更有效地處理那些隨著時(shí)間的推移，而開(kāi)展的各類數(shù)據(jù)攝取、壓縮、以及聚合活動(dòng)。

如今隨著云計(jì)算、物聯(lián)網(wǎng)、以及機(jī)器學(xué)習(xí)對(duì)于時(shí)序數(shù)據(jù)需求的持續(xù)爆炸式增長(zhǎng)，軟件架構(gòu)師們應(yīng)該如何選擇TSDB呢?本文將綜合比較市場(chǎng)上最為流行的三種TSDB--InfluxDB，TimescaleDB和QuestDB，以幫助您做出明智的選擇。

InfluxDB

于2013年被首次發(fā)布的InfluxDB，是TSDB領(lǐng)域的領(lǐng)導(dǎo)者。如下圖所示，它甚至超越了之前的Graphite和OpenTSDB。與許多開(kāi)源(OSS)數(shù)據(jù)庫(kù)類似，InfluxDB不但能夠?yàn)閱蝹€(gè)節(jié)點(diǎn)提供MIT許可，而且提供了InfluxDB Cloud付費(fèi)計(jì)劃，以及為企業(yè)級(jí)用戶提供了集群、以及生產(chǎn)環(huán)境就緒(production-ready)等功能。

圖片來(lái)源：DB-engines

如下圖所示，在2019年發(fā)布InfluxDB 2.x之前，InfluxDB平臺(tái)是由TICK技術(shù)棧所組成，即：Telegraf(收集和報(bào)告參數(shù)指標(biāo)的代理)、InfluxDB、Chronograf(從InfluxDB處查詢數(shù)據(jù)的接口)、以及Kapacitor(實(shí)時(shí)數(shù)據(jù)流的處理引擎)。InfluxDB 1.x主要通過(guò)社區(qū)和集成，收集、存儲(chǔ)和查看來(lái)自服務(wù)器和Web應(yīng)用的時(shí)序數(shù)據(jù)指標(biāo)。

圖片來(lái)源：Influxdata

InfluxDB 2.x從本質(zhì)上簡(jiǎn)化了整體架構(gòu)。它將TICK棧捆綁到了單個(gè)二進(jìn)制文件中，并且引入了一些新的功能，來(lái)執(zhí)行收集(如：原生的Prometheus插件)、組織(如：各種組織和存儲(chǔ)桶)、可視化(如：數(shù)據(jù)瀏覽器)數(shù)據(jù)、及其Flux語(yǔ)言。

在介紹InfluxDB的工作原理之前，讓我們先了解如下三個(gè)關(guān)鍵概念：

• 數(shù)據(jù)模型(標(biāo)簽集模型)：除了時(shí)間戳字段，其實(shí)每個(gè)數(shù)據(jù)元素還會(huì)包含各種標(biāo)簽(如：可選的、已被索引的元數(shù)據(jù)字段)、字段(如：鍵和值)、以及指標(biāo)(標(biāo)簽、字段和時(shí)間戳的容器)。下圖示例展示了由科學(xué)家Anderson和Mullen在Klamath和Portland兩地采集到的、蜜蜂和螞蟻的數(shù)量普查數(shù)據(jù)。此處的位置(location)和科學(xué)家(scientist)標(biāo)簽，被當(dāng)作蜜蜂和螞蟻普查范圍內(nèi)的“字段/值(field/value)”對(duì)。

有關(guān)蜜蜂和螞蟻普查數(shù)據(jù)的示例

• 數(shù)據(jù)模式(TSM & TSI)：是一些存儲(chǔ)在時(shí)間結(jié)構(gòu)合并樹(shù)(time-structured merge tree，TSM)和時(shí)序索引(time series index，TSI)文件中的數(shù)據(jù)元素。其中，TSM可以被認(rèn)為是具有預(yù)寫(xiě)日志(write-ahead log，WAL)和類似于SSTable只讀文件的LSM樹(shù)。這些文件通常是經(jīng)過(guò)排序和壓縮的。而TSI則是可供InfluxDB內(nèi)存映射的磁盤(pán)文件索引。它可以讓操作系統(tǒng)以最少最近使用(Least Recently Used，LRU)內(nèi)存的方式，來(lái)幫助處理具有高基數(shù)(high cardinality)的數(shù)據(jù)集(如，集合中的那些大型元素)。
• Flux腳本語(yǔ)言：是由InfluxDB開(kāi)發(fā)的一種，可用于協(xié)助查詢數(shù)據(jù)的特定域語(yǔ)言。同時(shí)，F(xiàn)lux也帶有一個(gè)可協(xié)助從SQL數(shù)據(jù)源進(jìn)行查詢的SQL包。

值得注意的是，InfluxDB在攝取數(shù)據(jù)之前，不會(huì)強(qiáng)制執(zhí)行某種結(jié)構(gòu)模式。相反，它的結(jié)構(gòu)模式是根據(jù)輸入的數(shù)據(jù)被自動(dòng)創(chuàng)建，以及從標(biāo)簽和字段中推斷出來(lái)的。這種類似NoSQL的體驗(yàn)，對(duì)于InfluxDB來(lái)說(shuō)有利也有弊。對(duì)于那些能夠自動(dòng)適合此類標(biāo)記集模型基數(shù)的數(shù)據(jù)集(如：各種物聯(lián)網(wǎng)數(shù)據(jù)、財(cái)務(wù)數(shù)據(jù)、以及大多數(shù)基礎(chǔ)設(shè)施和應(yīng)用程序的參數(shù)指標(biāo))而言，InfluxDB非常容易上手。用戶也無(wú)需擔(dān)心設(shè)計(jì)模式或索引(如下圖所示)。同時(shí)，對(duì)于那些目標(biāo)是創(chuàng)建物理資產(chǎn)數(shù)字模型的用例而言，它也是非常實(shí)用的。例如，在物聯(lián)網(wǎng)中，人們可能需要?jiǎng)?chuàng)建一個(gè)數(shù)字孿生，來(lái)表示一組傳感器，并攝取各種有組織的數(shù)據(jù)。

圖片來(lái)源：Influxdata

另一方面，當(dāng)數(shù)據(jù)集需要在連續(xù)的字段上建立索引(畢竟InfluxDB不支持?jǐn)?shù)字，而且標(biāo)簽必須是字符串)或驗(yàn)證數(shù)據(jù)時(shí)，這種“無(wú)模式”就是一種缺陷。此外，由于標(biāo)簽會(huì)被索引，因此如果標(biāo)簽會(huì)經(jīng)常變化(如，元數(shù)據(jù)可能在初次攝取后，就發(fā)生了變化)的話，僅依賴InfluxDB來(lái)推斷模式，就可能會(huì)產(chǎn)生昂貴的開(kāi)銷。

再者，由InfluxDB決定創(chuàng)建其自定義的功能性數(shù)據(jù)腳本語(yǔ)言(如Flux)，會(huì)給整個(gè)生態(tài)系統(tǒng)增加一層復(fù)雜性。對(duì)此，InfluxDB的團(tuán)隊(duì)特別強(qiáng)調(diào)了如下兩個(gè)從類SQL的InfluxQL轉(zhuǎn)換為Flux 的驅(qū)動(dòng)場(chǎng)景：

• 時(shí)序數(shù)據(jù)符合基于流的功能處理模型。其中，數(shù)據(jù)流是從一個(gè)輸出轉(zhuǎn)換為下一個(gè)輸出。而由SQL支持的關(guān)系代數(shù)模型，則不能處理這種操作和函數(shù)的鏈接。
• 通過(guò)InfluxDB為時(shí)序數(shù)據(jù)(如，指數(shù)級(jí)的移動(dòng)平均)的常見(jiàn)操作，提供一流的支持，而這并非SQL標(biāo)準(zhǔn)的一部分。

當(dāng)然，用戶需要花時(shí)間去熟悉Flux的語(yǔ)法，特別是那些追求簡(jiǎn)單的SQL查詢方式，以及不打算學(xué)習(xí)另一種新語(yǔ)言的用戶，尤為如此。好在InfluxDB已擁有大型的社區(qū)與集成，而且Flux能夠與內(nèi)置的儀表板相結(jié)合。

圖片來(lái)源：Influxdata

總的來(lái)說(shuō)，在面向基礎(chǔ)設(shè)施和應(yīng)用監(jiān)控的需求時(shí)，InfluxDB能夠與各種數(shù)據(jù)源無(wú)縫地集成。如果時(shí)序數(shù)據(jù)能夠與標(biāo)簽集模型非常吻合的話，那么InfluxDB是一個(gè)不錯(cuò)的選擇。可見(jiàn)，InfluxDB的優(yōu)缺點(diǎn)可以被歸結(jié)為：

• 優(yōu)點(diǎn)：無(wú)模式攝取、龐大的社區(qū)、與流行工具相集成。
• 缺點(diǎn)：具有高基數(shù)、自定義查詢/處理語(yǔ)言的數(shù)據(jù)集。

TimescaleDB

InfluxDB需要從頭開(kāi)始構(gòu)建新的數(shù)據(jù)庫(kù)和自定義語(yǔ)言，而TimescaleDB則建立在PostgreSQL之上，并添加了一個(gè)被稱為超級(jí)表(hypertables)的中間層。該層將數(shù)據(jù)分塊到多個(gè)底層數(shù)據(jù)表中，并將其抽象為一個(gè)可用于數(shù)據(jù)交互的單個(gè)大表。

與PostgreSQL的兼容性是TimescaleDB的最大賣點(diǎn)。TimescaleDB能夠完全支持所有的SQL功能(如：連接、二級(jí)和部分索引)，以及諸如PostGIS之類流行的擴(kuò)展。作為PostgreSQL的擴(kuò)展，TimescaleDB不但提供諸如Azure Database for PostgreSQL與Aiven之類的云托管選項(xiàng)，也提供了針對(duì)虛擬機(jī)或容器的各種自管理選項(xiàng)。

圖片來(lái)源：Stack Overflow

TimescaleDB最初是針對(duì)物聯(lián)網(wǎng)平臺(tái)，使用InfluxDB來(lái)存儲(chǔ)它們的傳感器數(shù)據(jù)。由于網(wǎng)絡(luò)不穩(wěn)定性，導(dǎo)致了物聯(lián)網(wǎng)時(shí)序數(shù)據(jù)經(jīng)常會(huì)出現(xiàn)擁堵和失序，因此TimescaleDB在高基數(shù)方面具有如下三個(gè)特點(diǎn)：

• 超級(jí)表(Hypertables)：TimescaleDB基于時(shí)間列、以及其他“空間”值(如：設(shè)備的UID、位置標(biāo)識(shí)符、或股票代號(hào))，來(lái)將其超級(jí)表劃分成塊。用戶可以通過(guò)配置這些塊，將最新的數(shù)據(jù)保存到內(nèi)存中，并按照時(shí)間列，將數(shù)據(jù)異步壓縮和重新排序至磁盤(pán)(并非攝取時(shí)間)，以及在節(jié)點(diǎn)之間，以事務(wù)的方式進(jìn)行復(fù)制和遷移。
• 持續(xù)聚合(Continuous Aggregation)：通常，物聯(lián)網(wǎng)數(shù)據(jù)在匯總時(shí)更為實(shí)用，因此我們無(wú)需在每個(gè)匯總查詢中去掃描大量的數(shù)據(jù)。由于支持?jǐn)?shù)據(jù)的持續(xù)聚合，TimescaleDB能夠快速地計(jì)算出諸如：小時(shí)平均值、最小值和最大值等關(guān)鍵指標(biāo)(如，計(jì)算出下午3點(diǎn)到4點(diǎn)之間的平均溫度，或是下午3點(diǎn)時(shí)刻的確切溫度)。這將有助于創(chuàng)建高性能的儀表板與分析結(jié)果。
• 數(shù)據(jù)保留(Data Retention)：在傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)中，大量的刪除操作往往代價(jià)高昂。然而，由于TimescaleDB是以塊的形式存儲(chǔ)數(shù)據(jù)的，因此它提供了一種drop_chunks的功能，可以在同等開(kāi)銷下，快速地刪除舊的數(shù)據(jù)。由于舊數(shù)據(jù)的相關(guān)性會(huì)隨著時(shí)間的推移而降低，因此TimescaleDB可以通過(guò)與長(zhǎng)期存儲(chǔ)(如，OLAP或Blob存儲(chǔ))一起使用，來(lái)移走舊的數(shù)據(jù)，節(jié)省磁盤(pán)空間，進(jìn)而為新的數(shù)據(jù)上提供優(yōu)異的性能。

就性能而言，時(shí)序基準(zhǔn)套件(Time Series Benchmark Suite，TTSBS，)詳細(xì)比較了TimescaleDB 1.7.1和InfluxDB 1.8.0(兩者都是OSS版本)在插入和讀取延遲方面的性能指標(biāo)。不過(guò)，由于如今兩者都已經(jīng)擁有了2.x版本，因此該分析略顯過(guò)時(shí)。從下圖比較結(jié)果可知，TimescaleDB會(huì)隨著數(shù)據(jù)基數(shù)的增長(zhǎng)(以3.5倍速)，提供卓越的性能。

InfluxDB與TimescaleDB的攝取速度比較

TimescaleDB團(tuán)隊(duì)指出，InfluxDB的基于日志結(jié)構(gòu)合并樹(shù)系統(tǒng)(tree-based system，TSI)與TimescaleDB的B樹(shù)索引方法，是性能制勝的法寶。當(dāng)然，我在此并未武斷地認(rèn)為T(mén)imescaleDB在性能方面就一定優(yōu)于InfluxDB。畢竟性能基準(zhǔn)測(cè)試受到數(shù)據(jù)模型、硬件、以及配置等多方面的影響較大。該比較結(jié)果僅表明，TimescaleDB可能更適合數(shù)據(jù)基數(shù)較高的物聯(lián)網(wǎng)用例(例如，在1000萬(wàn)臺(tái)設(shè)備中，獲悉設(shè)備X的平均功耗)。具體有關(guān)這兩個(gè)數(shù)據(jù)庫(kù)之間的深度比較，請(qǐng)參見(jiàn)由Timescale自行提供的《TimescaleDB與InfluxDB的比較》。

總體而言，TimescaleDB非常適合那些尋求顯著性能提升，而不想通過(guò)大量重構(gòu)來(lái)遷移現(xiàn)有SQL數(shù)據(jù)庫(kù)的團(tuán)隊(duì)。盡管TimescaleDB相對(duì)較新(于2017年首次被發(fā)布)，但是許多物聯(lián)網(wǎng)初創(chuàng)公司已在使用它作為中間數(shù)據(jù)存儲(chǔ)，以快速提取橫跨數(shù)月的聚合參數(shù)指標(biāo)，并將舊的數(shù)據(jù)移至長(zhǎng)期存儲(chǔ)處。如果您已經(jīng)在Kubernetes集群上運(yùn)行著 PostgreSQL，那么安裝TimescaleDB和遷移數(shù)據(jù)的任務(wù)都會(huì)相對(duì)比較容易。

總的說(shuō)來(lái)，TimescaleDB的優(yōu)缺點(diǎn)可以被歸結(jié)為：

• 優(yōu)點(diǎn)：與PostgreSQL兼容性，可以很好地?cái)U(kuò)展數(shù)據(jù)基數(shù)，并提供各種部署模型。
• 缺點(diǎn)：結(jié)構(gòu)模式固定，而且在攝取之前增加了復(fù)雜性和數(shù)據(jù)的轉(zhuǎn)換工作。

QuestDB

對(duì)于那些既希望利用InfluxDB內(nèi)聯(lián)協(xié)議的靈活性，又熟悉PostgreSQL的人來(lái)說(shuō)，QuestDB(YC S20)作為一個(gè)較新的時(shí)序數(shù)據(jù)庫(kù)，可以滿足開(kāi)發(fā)者的這兩個(gè)要求。它是一個(gè)用Java和C++編寫(xiě)的開(kāi)源TSDB，雖然被推出僅一年多，但是已排名到了前15。從原理上說(shuō)，QuestDB是利用內(nèi)存映射文件，在數(shù)據(jù)提交到磁盤(pán)之前，實(shí)現(xiàn)快速讀寫(xiě)的。

圖片來(lái)源：QuestDB

QuestDB通過(guò)使用Java和C++，來(lái)從頭開(kāi)始​​構(gòu)建數(shù)據(jù)庫(kù)，其主要特征體現(xiàn)在：

• 性能：解決攝取過(guò)程中，特別是在處置高基數(shù)的數(shù)據(jù)集過(guò)程中的瓶頸。同時(shí)，它還通過(guò)順次存儲(chǔ)的時(shí)分?jǐn)?shù)據(jù)(即，在內(nèi)存中的混洗)，以及僅分析請(qǐng)求的列/分區(qū)，而并非以整張表的方式，來(lái)支持快速的數(shù)據(jù)檢索。此外，QuestDB還會(huì)運(yùn)用SIMD指令，實(shí)現(xiàn)并行化操作。
• 兼容性：QuestDB支持InfluxDB的內(nèi)聯(lián)(inline)協(xié)議、PostgreSQL wire、REST API、以及CSV上傳的方式，來(lái)攝取數(shù)據(jù)。那些習(xí)慣了其他TSDB的用戶，可以輕松地移植他們的現(xiàn)有應(yīng)用程序，而無(wú)需進(jìn)行大量的重寫(xiě)工作。
• 通過(guò)SQL進(jìn)行查詢：雖然能夠支持多種攝取機(jī)制，但是QuestDB也會(huì)使用SQL作為查詢語(yǔ)言，因此用戶無(wú)需額外地學(xué)習(xí)Flux之類的特定域語(yǔ)言。

在性能方面，QuestDB最近發(fā)布了一篇包含基準(zhǔn)測(cè)試結(jié)果的博文，展示了其每秒140萬(wàn)行的寫(xiě)入速度。QuestDB團(tuán)隊(duì)在cpu-only的用例中，使用了TSBS基準(zhǔn)測(cè)試。其中m5.8xlarge在AWS上的實(shí)例中，使用了多達(dá)14個(gè)work(注意：該140萬(wàn)行的數(shù)字，源于使用了AMD Ryzen5的處理器)。

對(duì)于具有高基數(shù)(超過(guò)1000萬(wàn))的數(shù)據(jù)集，QuestDB的性能優(yōu)于其他TSDB。憑借著Intel Xeon CPU，其峰值的攝取吞吐量為904k行/秒，并能夠在1000萬(wàn)臺(tái)設(shè)備上使用四個(gè)線程，且在m5.8xlarge實(shí)例上維持約640k行/秒的性能。而當(dāng)QuestDB在AMD Ryzen 3970X上運(yùn)行相同的基準(zhǔn)測(cè)試時(shí)，它具有超過(guò)1百萬(wàn)行/秒的攝取吞吐量。

各種TSDB在攝取吞吐量與設(shè)備數(shù)量上的比較

同樣，上述基于數(shù)據(jù)模型和DB調(diào)整的性能基準(zhǔn)測(cè)試也可能不夠客觀，不過(guò)它們?cè)谝欢ǔ潭壬象w現(xiàn)了QuestDB的性能優(yōu)勢(shì)。

QuestDB的另一個(gè)有趣的特性是，在攝取中支持InfluxDB內(nèi)聯(lián)協(xié)議和PostgreSQL的wire。對(duì)于現(xiàn)有的InfluxDB用戶，您可以將Telegraf配置為指向QuestDB的地址和端口。同理，PostgreSQL用戶使用現(xiàn)有的客戶端庫(kù)、或JDBC，將數(shù)據(jù)寫(xiě)入QuestDB。當(dāng)然，無(wú)論采用何種攝取方法，我們都可以使用標(biāo)準(zhǔn)的SQL去查詢數(shù)據(jù)。值得注意的是，其API參考頁(yè)面上，顯著地列出了一些例外的情況。

作為該領(lǐng)域的新玩家，QuestDB最明顯的缺點(diǎn)是，缺乏生產(chǎn)環(huán)境就緒的功能(如，復(fù)制、備份與恢復(fù)等)。同時(shí)，它雖然能與諸如：PostgreSQL、Grafana、Kafka、Telegraf、以及Tableau等流行工具相集成，但是需要花時(shí)間調(diào)試與磨合，方可達(dá)到上述其他TSDB的水平。

總的說(shuō)來(lái)，QuestDB的優(yōu)缺點(diǎn)可以被歸結(jié)為：

• 優(yōu)點(diǎn)：快速攝取(特別是對(duì)于具有高基數(shù)的數(shù)據(jù)集)，支持InfluxDB內(nèi)聯(lián)協(xié)議和PostgreSQL wire，可以通過(guò)標(biāo)準(zhǔn)的SQL查詢數(shù)據(jù)。
• 缺點(diǎn)：在用戶社區(qū)、可用集成、以及對(duì)生產(chǎn)環(huán)境就緒等方面，都有待改進(jìn)。

小結(jié)

隨著業(yè)界對(duì)于時(shí)序數(shù)據(jù)需求的不斷增長(zhǎng)，專門(mén)處理此類數(shù)據(jù)的TSDB將會(huì)被大規(guī)模地采用，并引發(fā)激烈的競(jìng)爭(zhēng)。除了上面介紹的三大開(kāi)源TSDB之外，市場(chǎng)上還有AWS(AWS Timestream)和Azure(Azure Series Insights)等公共云產(chǎn)品。

與傳統(tǒng)數(shù)據(jù)庫(kù)類似，選擇TSDB主要仍取決于您的業(yè)務(wù)需求、數(shù)據(jù)模型、以及數(shù)據(jù)用例。如果您的數(shù)據(jù)適合于具有豐富的、集成生態(tài)系統(tǒng)的標(biāo)簽集模型，那么請(qǐng)選擇InfluxDB。TimescaleDB則非常適合于現(xiàn)有的PostgreSQL用戶。而如果性能是您的首要考慮因素的話，請(qǐng)您考慮選用QuestDB。

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

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】