顧名思義，時間序列數(shù)據(jù)庫旨在存儲隨時間變化的數(shù)據(jù)。這可以是隨時間收集的任何類型的數(shù)據(jù)。它可能是從某些系統(tǒng)收集的指標(biāo)，實際上，所有趨勢系統(tǒng)都是時間序列數(shù)據(jù)的示例。

我們有不同類型的時間序列數(shù)據(jù)庫，應(yīng)該使用哪些數(shù)據(jù)庫？

在此博客中，我們將看到兩個主要選項TimescaleDB和InfluxDB之間的主要區(qū)別是什么。

InfluxDB

InfluxDB是由InfluxData創(chuàng)建的。它是用Go語言編寫的自定義，開源，NoSQL時間序列數(shù)據(jù)庫。數(shù)據(jù)存儲區(qū)提供了一種類似于SQL的語言來查詢數(shù)據(jù)，稱為InfluxQL，這使開發(fā)人員可以輕松地將其集成到其應(yīng)用程序中。它還具有一種稱為Flux的新的自定義查詢語言，該語言可以使某些任務(wù)更輕松，但是在采用自定義查詢語言時總會有學(xué)習(xí)上的彎路。

這是一個Flux查詢示例：

在此數(shù)據(jù)庫中，每個度量都有一個時間戳，以及一組關(guān)聯(lián)的標(biāo)簽和一組字段。該字段代表實際的測量讀數(shù)值，而標(biāo)簽代表描述測量的元數(shù)據(jù)。字段數(shù)據(jù)類型僅限于浮點數(shù)，整數(shù)，字符串和布爾值，并且如果不重寫數(shù)據(jù)就無法更改。標(biāo)簽值被索引。它們以字符串表示，無法更新。

InfluxDB入門非常容易，因為您不必?fù)?dān)心創(chuàng)建模式或索引。但是，它非常嚴(yán)格且受限制，無法創(chuàng)建其他索引，在連續(xù)字段上建立索引，事后更新元數(shù)據(jù)，強制執(zhí)行數(shù)據(jù)驗證等。

它不是無模式的。有一個從輸入數(shù)據(jù)自動創(chuàng)建的基礎(chǔ)架構(gòu)。

InfluxDB必須從頭開始實施多種容錯工具，例如復(fù)制，高可用性和備份/還原，并且要對其磁盤可靠性負(fù)責(zé)。我們僅限于使用這些工具，并且其中許多功能（例如HA）僅在企業(yè)版中可用。

InfluxDB備份工具可以執(zhí)行完整或增量備份，并且可以用于時間點恢復(fù)。

InfluxDB還提供了比PostgreSQL和TimescaleDB更好的磁盤壓縮。

時標(biāo)數(shù)據(jù)庫

TimescaleDB是一個開放源代碼的時間序列數(shù)據(jù)庫，已針對支持全面SQL的快速提取和復(fù)雜查詢進行了優(yōu)化。它基于PostgreSQL，并且為時間序列數(shù)據(jù)提供了最好的NoSQL和Relational世界。

這是一個TimescaleDB查詢示例：

作為PostgreSQL擴展，TimescaleDB是一個關(guān)系數(shù)據(jù)庫。這使新用戶的學(xué)習(xí)曲線更短，并可以繼承用于備份的工具pg_dump或pg_backup和高可用性工具，這在其他時間序列數(shù)據(jù)庫之前是一個優(yōu)勢。它還支持流復(fù)制作為主要的復(fù)制方法，可以在高可用性設(shè)置中使用它。在故障轉(zhuǎn)移和備份方面，您可以使用ClusterControl之類的外部系統(tǒng)來自動執(zhí)行此過程。

在TimescaleDB中，每個時間序列測量值都記錄在其自己的行中，其中時間字段后跟任意數(shù)量的其他字段，這些字段可以是浮點數(shù)，整數(shù)，字符串，布爾值，數(shù)組，JSON blob，地理空間尺寸，日期/時間/時間戳，貨幣，二進制數(shù)據(jù)等。

您可以在任何字段（標(biāo)準(zhǔn)索引）或多個字段（復(fù)合索引）上創(chuàng)建索引，也可以在函數(shù)之類的表達(dá)式上創(chuàng)建索引，甚至可以將索引限制為行的子集（部分索引）。這些字段中的任何一個都可以用作輔助表的外鍵，然后該表可以存儲其他元數(shù)據(jù)。

這樣，您需要選擇一個模式，并確定系統(tǒng)需要哪些索引。

性能

如果我們談?wù)撔阅埽敲纯梢圆榭春馨舻腡imescaleDB比較博客。在那里，您可以通過圖表和指標(biāo)對兩個數(shù)據(jù)庫之間的性能進行詳細(xì)比較。讓我們看看該博客中的一些最重要的信息。

插入物

• 對于基數(shù)非常低的工作負(fù)載（例如100個設(shè)備），InfluxDB的性能優(yōu)于TimescaleDB。

• 隨著基數(shù)的增加，InfluxDB插入性能下降的速度快于TimescaleDB。

• 對于中到高基數(shù)的工作負(fù)載（例如，100個設(shè)備發(fā)送10個指標(biāo)），TimescaleDB的性能要優(yōu)于InfluxDB。

讀取延遲

• 對于簡單查詢，結(jié)果相差很大：在某些情況下，一個數(shù)據(jù)庫明顯優(yōu)于另一個數(shù)據(jù)庫，而其他數(shù)據(jù)庫則取決于數(shù)據(jù)集的基數(shù)。此處的差異通常在一位數(shù)到兩位數(shù)的毫秒數(shù)范圍內(nèi)。

• 對于復(fù)雜的查詢，TimescaleDB的性能大大優(yōu)于InfluxDB，并支持范圍更廣的查詢類型。這里的差異通常在幾秒到幾十秒之間。

• 考慮到這一點，正確測試的最佳方法是使用您計劃執(zhí)行的查詢進行基準(zhǔn)測試。

穩(wěn)定性問題

• InfluxDB在基數(shù)高（100K +）時存在穩(wěn)定性和性能問題。

結(jié)論

如果您的數(shù)據(jù)適合InfluxDB數(shù)據(jù)模型，并且您不希望將來發(fā)生變化，那么您應(yīng)該考慮使用InfluxDB，因為該模型更容易上手，就像大多數(shù)使用面向列方法的數(shù)據(jù)庫一樣，提供比PostgreSQL和TimescaleDB更好的磁盤壓縮。

但是，關(guān)系模型比InfluxDB模型具有更多的通用性，并提供更多的功能，靈活性和控制力。隨著應(yīng)用程序的發(fā)展，這一點尤其重要。在計劃系統(tǒng)時，應(yīng)同時考慮當(dāng)前和將來的需求。

在此博客中，我們可以看到TimescaleDB和InfluxDB之間的簡短比較，并且可以說TimescaleDB作為PostgreSQL擴展，看起來很成熟并且功能豐富，因為它從PostgreSQL繼承了很多東西。但是您可以根據(jù)本博客前面提到的優(yōu)缺點來做出自己的決定，并確保對自己的工作負(fù)載進行基準(zhǔn)測試。在這個新的時間序列數(shù)據(jù)庫世界中祝您好運！