是的，你沒(méi)看錯(cuò)：高性能時(shí)序數(shù)據(jù)庫(kù) + 強(qiáng)大可視化分析平臺(tái) = 數(shù)據(jù)分析的全新打開(kāi)方式。下面我們就帶你快速了解一下這次集成能帶來(lái)什么、適合誰(shuí)、以及如何快速上手。

TDengine + Tableau 能帶來(lái)啥？

如果只用一句話(huà)總結(jié)，那就是讓你的時(shí)序數(shù)據(jù)不僅跑得快，還看得清。

具體來(lái)說(shuō)，TDengine + Tableau 的組合可以從以下四個(gè)方面為你帶來(lái)顯著便利：

• 實(shí)時(shí)性強(qiáng)：TDengine 原生支持高吞吐寫(xiě)入與毫秒級(jí)查詢(xún)，Tableau 則能將這些實(shí)時(shí)數(shù)據(jù)一目了然地呈現(xiàn)在儀表盤(pán)上。
• 操作簡(jiǎn)單：通過(guò) JDBC 驅(qū)動(dòng)連接，Tableau 可以像操作常規(guī)數(shù)據(jù)庫(kù)一樣，訪(fǎng)問(wèn) TDengine 中的數(shù)據(jù)，無(wú)需額外開(kāi)發(fā)。
• 可視化能力拉滿(mǎn)：不管是電力監(jiān)控、設(shè)備運(yùn)維、還是工廠(chǎng)生產(chǎn)數(shù)據(jù)，Tableau 都能幫你用豐富的圖表形式呈現(xiàn)出來(lái)。
• 數(shù)據(jù)價(jià)值最大化：讓原本冰冷的傳感器數(shù)據(jù)，真正變成業(yè)務(wù)洞察的“第一現(xiàn)場(chǎng)”。

哪些人適合用 TDengine + Tableau？

通過(guò) JDBC 接口，TDengine 可以直接對(duì)接 Tableau，實(shí)現(xiàn)時(shí)序數(shù)據(jù)的可視化分析。無(wú)論是工業(yè)現(xiàn)場(chǎng)的實(shí)時(shí)采集數(shù)據(jù)，還是企業(yè)內(nèi)部復(fù)雜的運(yùn)維指標(biāo)，都能快速接入并以圖表形式呈現(xiàn)，幫助你更直觀地識(shí)別趨勢(shì)、發(fā)現(xiàn)異常、做出決策。非常適合以下場(chǎng)景與人群：

• 工業(yè) IoT 從業(yè)者：想把 OPC、MQTT 等采集來(lái)的時(shí)序數(shù)據(jù)，通過(guò)可視化更直觀地呈現(xiàn)。
• 運(yùn)維/工程技術(shù)人員：需要通過(guò)圖表查看歷史趨勢(shì)、告警分布、設(shè)備運(yùn)行狀況等。
• 數(shù)據(jù)分析師 & BI 團(tuán)隊(duì)：希望把 TDengine 中的時(shí)序數(shù)據(jù)納入 BI 報(bào)表體系，與其他業(yè)務(wù)數(shù)據(jù)融合分析。
• 企業(yè) IT 團(tuán)隊(duì)：正在構(gòu)建統(tǒng)一的可視化平臺(tái)，希望打通底層工業(yè)數(shù)據(jù)源。

總之，如果你正在使用 TDengine，又想更直觀地展示數(shù)據(jù)趨勢(shì)與業(yè)務(wù)變化，那 Tableau 是個(gè)不錯(cuò)的搭檔。

3 步搞定集成，解鎖可視化分析！

集成其實(shí)非常簡(jiǎn)單，完整教程已經(jīng)發(fā)布在官網(wǎng)文檔：https://docs.taosdata.com/third-party/bi/tableau/

這里我們快速劃重點(diǎn)：

①?第一步：準(zhǔn)備環(huán)境

確認(rèn)你已經(jīng)安裝好 Tableau Desktop 和 TDengine，并獲取了 TDengine 的 JDBC 驅(qū)動(dòng)（下載地址見(jiàn)文檔）。

②?第二步：連接數(shù)據(jù)庫(kù)

在 Tableau 中選擇 JDBC 連接，填寫(xiě) TDengine 的 JDBC URL，例如：

jdbc:TAOS://localhost:6030/test?user=root&password=taosdata

③?第三步：開(kāi)始可視化！

連接成功后，就可以像連接 MySQL 一樣自由拖拽字段，創(chuàng)建圖表了。你可以設(shè)置時(shí)間維度、聚合方式，輕松構(gòu)建適合你的分析視圖。

結(jié)語(yǔ)

過(guò)去，我們談 TDengine，總是講寫(xiě)入有多快、存儲(chǔ)多省、查詢(xún)多穩(wěn)?，F(xiàn)在，是時(shí)候看看這些數(shù)據(jù)如何“活”起來(lái)了。Tableau 的加入不僅讓 TDengine 的數(shù)據(jù)變得更直觀、更具說(shuō)服力，也為你開(kāi)啟了一個(gè)更廣闊的分析空間。下一步？快打開(kāi) Tableau，接入你的 TDengine 數(shù)據(jù)，做一個(gè)你自己都驚艷的儀表盤(pán)吧！

TSBS 是一個(gè)時(shí)序數(shù)據(jù)處理（數(shù)據(jù)庫(kù)）系統(tǒng)的性能基準(zhǔn)測(cè)試平臺(tái)，提供了 IoT、DevOps 兩個(gè)典型應(yīng)用場(chǎng)景，它由 Timescale 開(kāi)源并負(fù)責(zé)維護(hù)。作為一個(gè)性能基準(zhǔn)測(cè)試平臺(tái)，TSBS 具有便捷、易用、擴(kuò)展靈活等特點(diǎn)，涵蓋了時(shí)序數(shù)據(jù)的生成、寫(xiě)入（加載）、多種類(lèi)別的典型查詢(xún)等功能，并能夠自動(dòng)匯總最終結(jié)果。由于其開(kāi)放開(kāi)源的特點(diǎn)，得到了眾多數(shù)據(jù)庫(kù)廠(chǎng)商的支持，作為專(zhuān)業(yè)的產(chǎn)品性能基準(zhǔn)測(cè)試平臺(tái)被若干數(shù)據(jù)庫(kù)廠(chǎng)商廣泛使用。

以下的性能基準(zhǔn)報(bào)告均使用了 TSBS 作為基礎(chǔ) Benchmark 平臺(tái)，我們從時(shí)間跨度和發(fā)布廠(chǎng)商的知名度同時(shí)來(lái)看，就能發(fā)現(xiàn)，基礎(chǔ)測(cè)試平臺(tái) TSBS 已經(jīng)具備了很高的認(rèn)可度：

2018 年 11 月
VictoriaMetrics 的創(chuàng)始人 Aliaksandr Valialkin 發(fā)布 《High-cardinality TSDB benchmarks: VictoriaMetrics vs TimescaleDB vs InfluxDB》，將 VictoriaMetrics 與 TimescaleDB、InfluxDB 進(jìn)行性能對(duì)比。

2018 年 11 月
文章《ClickHouse Crushing Time Series》中對(duì)比了 TimescaleDB, InfluxDB, ClickHouse 在時(shí)序數(shù)據(jù)場(chǎng)景下的性能。

2020 年 3 月
Cloudera 在網(wǎng)站博客中發(fā)布《Benchmarking Time Series workloads on Apache Kudu using TSBS》，在 DevOps場(chǎng)景 中對(duì)比了 Apache Kudu, InfluxDB, VictoriaMetrics, ClickHouse 等整體性能表現(xiàn)。

2020 年 3 月
Redis 發(fā)布了基于 TSBS 的性能報(bào)告《RedisTimeSeries Version 1.2 Benchmarks》。

2020 年 8 月
Timescale 在其官方博客發(fā)布了性能對(duì)比報(bào)告《TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data》。

2021 年 8 月
QuestDB 發(fā)布了 QuestDB 與 TimescaleDB 的性能對(duì)比報(bào)告——《QuestDB vs. TimescaleDB》。

DevOps 場(chǎng)景是一個(gè)典型的時(shí)序數(shù)據(jù)應(yīng)用場(chǎng)景，TSBS DevOps 場(chǎng)景提供了 CPU 狀態(tài)的模擬數(shù)據(jù)，針對(duì)每個(gè)設(shè)備（CPU）記錄其 10 個(gè)測(cè)量值（metric），1 個(gè)時(shí)間戳（納秒分辨率），10 個(gè)標(biāo)簽值（tag）。生成的數(shù)據(jù)每 10 秒間隔一條記錄，具體的內(nèi)容和示例數(shù)據(jù)如下：

TSBS 測(cè)試可以簡(jiǎn)單劃分為兩個(gè)主要部分——數(shù)據(jù)寫(xiě)入和數(shù)據(jù)查詢(xún)。在本次整個(gè)基準(zhǔn)性能評(píng)估中，共涉及以下五個(gè)場(chǎng)景，每個(gè)場(chǎng)景的具體數(shù)據(jù)規(guī)模和特點(diǎn)見(jiàn)下表：

通過(guò)上表可以看到，五個(gè)場(chǎng)景的區(qū)別主要在于數(shù)據(jù)集所包含的設(shè)備記錄數(shù)量、設(shè)備數(shù)的不同，數(shù)據(jù)時(shí)間間隔均維持在 10 sec。整體來(lái)看，五個(gè)場(chǎng)景的數(shù)據(jù)規(guī)模都不算大，數(shù)據(jù)規(guī)模最大的是場(chǎng)景五，數(shù)據(jù)達(dá)到了 1.8 億，數(shù)據(jù)規(guī)模最小的是場(chǎng)景一，只有 2678 萬(wàn)條記錄。在場(chǎng)景四和場(chǎng)景五中，由于設(shè)備數(shù)量相對(duì)較多，所以數(shù)據(jù)集僅覆蓋了 3 分鐘的時(shí)間跨度。

為了保證測(cè)試結(jié)果的公正可靠及可復(fù)制性，我們選用了公共 IaaS 平臺(tái)來(lái)搭建 Benchmark 基礎(chǔ)硬件環(huán)境，采用了大多數(shù)性能對(duì)比報(bào)告中使用的場(chǎng)景——亞馬遜 EC2 服務(wù)環(huán)境下 r4.8xlarge 類(lèi)型的實(shí)例作為基礎(chǔ)運(yùn)行平臺(tái)，區(qū)域?yàn)楸泵赖貐^(qū)，包括 1 臺(tái)服務(wù)器、1 臺(tái)客戶(hù)端。客戶(hù)端與服務(wù)器硬件配置完全相同，兩者使用 10 Gbps 網(wǎng)絡(luò)連接。配置簡(jiǎn)表如下：

本次測(cè)試的對(duì)比軟件為 InfluxDB 1.8.10 及 Timescale 2.6.0，在這里要著重說(shuō)明一下，由于 InfluxDB 最新的 2.0 版本并沒(méi)有納入 TSBS 的主干分支，因此在這次測(cè)試中我們暫且使用了 TSBS 主干分支所支持的 InfluxDB 最新版本，即 1.8.10。

整個(gè) TSBS 測(cè)試流程相對(duì)比較簡(jiǎn)單，在進(jìn)行寫(xiě)入性能對(duì)比時(shí)，配置完成參數(shù)后直接運(yùn)行 TSBS 框架腳本，等待結(jié)果輸出即可。對(duì)于查詢(xún)處理，我們選擇了批量自動(dòng)化去運(yùn)行，對(duì)每個(gè)查詢(xún)語(yǔ)句運(yùn)行 5000 次，統(tǒng)計(jì)查詢(xún)延遲的算數(shù)平均作為最后的查詢(xún)延遲結(jié)果。此外我們還全程監(jiān)控并記錄了整個(gè)過(guò)程中服務(wù)器與客戶(hù)端節(jié)點(diǎn)的系統(tǒng)資源開(kāi)銷(xiāo)與負(fù)載情況。

下面可以簡(jiǎn)單為大家介紹下本次測(cè)試結(jié)果。如下表所示，在全部五個(gè)場(chǎng)景中，TDengine 寫(xiě)入性能均優(yōu)于 InfluxDB 和 TimescaleDB，寫(xiě)入過(guò)程中資源占用最低。對(duì)比 InfluxDB，TDengine 寫(xiě)入最優(yōu)的場(chǎng)景是在 1000 萬(wàn)設(shè)備下，達(dá)到了 InfluxDB 的?10.6 倍；對(duì)比 TimescaleDB ，TDengine 寫(xiě)入最優(yōu)的場(chǎng)景是在 4000 個(gè)設(shè)備下，達(dá)到了 TimeScaleDB 的?6.7 倍。

在查詢(xún)測(cè)試上，我們將其分為 5 大類(lèi)、15 小類(lèi)進(jìn)行查詢(xún)對(duì)比，從下圖結(jié)果匯總中可以看到，在全部 15 個(gè)查詢(xún)類(lèi)型中，TDengine 的性能均優(yōu)于 InfluxDB 和 TimescaleDB，并且它的所有查詢(xún)延遲均比 InfluxDB 和 TimescaleDB 更低。亮點(diǎn)數(shù)據(jù)之一體現(xiàn)在 Double Rollups 查詢(xún)類(lèi)型對(duì)比中，TDengine 最大達(dá)到 InfluxDB 的?34 倍，TimescaleDB 的?24 倍。

以上就是 TDengine 基于 TSBS 測(cè)試報(bào)告的測(cè)試背景介紹，如果你對(duì)測(cè)試結(jié)果感興趣，歡迎查閱整體報(bào)告。

經(jīng)常有人問(wèn)我，為什么 2017 年在市場(chǎng)上已經(jīng)有這么多時(shí)序數(shù)據(jù)庫(kù)的背景之下，你還敢去開(kāi)發(fā)一款新的時(shí)序數(shù)據(jù)庫(kù)？為什么你的團(tuán)隊(duì)都 80 多人了，五年過(guò)去，還在埋頭研發(fā) TDengine 這一款產(chǎn)品？周末寫(xiě)篇博文，與大家分享一下我的想法。

時(shí)序數(shù)據(jù)庫(kù)（Time Series Database）并不是一個(gè)新興的概念。追溯其歷史，1999 年問(wèn)世的 RRDtool 應(yīng)該是最早的專(zhuān)用時(shí)序數(shù)據(jù)庫(kù)了。在著名的數(shù)據(jù)庫(kù)排行網(wǎng)站 DB-engines 上面，時(shí)序數(shù)據(jù)庫(kù)的逐步流行起始于 2015 年，而在過(guò)去的兩年，時(shí)序數(shù)據(jù)庫(kù)成為流行度最高的數(shù)據(jù)庫(kù)。

2016 年底，我看到萬(wàn)物互聯(lián)的時(shí)代已經(jīng)到來(lái)，高效處理各種傳感器、設(shè)備產(chǎn)生的時(shí)序數(shù)據(jù)將成為一重要的技術(shù)領(lǐng)域，因此就著手開(kāi)發(fā) TDengine 這個(gè)新的時(shí)序數(shù)據(jù)庫(kù)系統(tǒng)，2017 年 6 月正式組建團(tuán)隊(duì)。

TDengine 面市以來(lái)，從 1.0 到 2.0，從核心功能開(kāi)源到集群功能開(kāi)源，得到了大量商業(yè)客戶(hù)和社區(qū)用戶(hù)的高度認(rèn)可，全球安裝的 TDengine 運(yùn)行實(shí)例數(shù)已經(jīng)超過(guò) 13 萬(wàn)，每天克隆源代碼的人次都超過(guò) 1000，在全球開(kāi)發(fā)者社區(qū)產(chǎn)生了一定的影響力。

剛開(kāi)始創(chuàng)業(yè)的時(shí)候，我就進(jìn)行了深入的思考：新的時(shí)序數(shù)據(jù)庫(kù)還有生存空間嗎？換句話(huà)說(shuō)，現(xiàn)有的這些數(shù)據(jù)庫(kù)對(duì)應(yīng)用而言是不是已經(jīng)足夠好了？它們能滿(mǎn)足業(yè)務(wù)需求嗎？現(xiàn)在我也經(jīng)常思考，時(shí)序數(shù)據(jù)庫(kù)值得你死磕嗎？今天我從技術(shù)的角度來(lái)分析一下這個(gè)問(wèn)題，與大家分享。

1、可擴(kuò)展性 / Scalability

由于 IT 基礎(chǔ)設(shè)施的爆炸性增長(zhǎng)和物聯(lián)網(wǎng)（IoT）的出現(xiàn)，數(shù)據(jù)的規(guī)模正在迅速增長(zhǎng)。一個(gè)現(xiàn)代的數(shù)據(jù)中心可能需要收集多達(dá) 1 億個(gè)指標(biāo)——從網(wǎng)絡(luò)設(shè)備和服務(wù)器到虛擬機(jī)、容器和微服務(wù)的一切都在不斷地發(fā)送時(shí)間序列數(shù)據(jù)。再比如，分布式電網(wǎng)中的每個(gè)智能電表每分鐘至少產(chǎn)生一個(gè)數(shù)據(jù)點(diǎn)，而中國(guó)的智能電表，至少有十億個(gè)。任何一臺(tái)計(jì)算機(jī)都不可能處理這么多的數(shù)據(jù)，所以任何旨在處理時(shí)間序列數(shù)據(jù)的系統(tǒng)必須是可擴(kuò)展的。 

然而，許多市場(chǎng)領(lǐng)先的時(shí)序數(shù)據(jù)庫(kù)并沒(méi)有提供可擴(kuò)展的解決方案。就拿 Prometheus 來(lái)說(shuō)，它可以算是用于 Kubernetes 環(huán)境的時(shí)序數(shù)據(jù)庫(kù)的一個(gè)事實(shí)標(biāo)準(zhǔn)，但它并沒(méi)有提供分布式的設(shè)計(jì)，而必須依靠 Cortex、Thanos 或其他第三方工具來(lái)實(shí)現(xiàn)可擴(kuò)展性。InfluxDB 有集群功能，但是只向企業(yè)客戶(hù)提供，沒(méi)有選擇開(kāi)源。

為了解決這個(gè)問(wèn)題，很多開(kāi)發(fā)者的選擇是，在應(yīng)用程序和時(shí)序數(shù)據(jù)庫(kù)服務(wù)器（如 InfluxDB 或 Prometheus）之間部署一個(gè)代理服務(wù)器，來(lái)建立自己的可擴(kuò)展的解決方案。然后根據(jù)時(shí)序 ID 的哈希值，將收集到的時(shí)序數(shù)據(jù)在多個(gè)時(shí)序數(shù)據(jù)庫(kù)服務(wù)器之間分配。從數(shù)據(jù)寫(xiě)入角度看，這確實(shí)解決了可擴(kuò)展性的問(wèn)題。但對(duì)于查詢(xún)，代理服務(wù)器必須合并來(lái)自每個(gè)底層節(jié)點(diǎn)的查詢(xún)結(jié)果，而這是一個(gè)很大的技術(shù)挑戰(zhàn)。對(duì)于一些查詢(xún)，比如計(jì)算標(biāo)準(zhǔn)差，還不能只是合并結(jié)果，而是必須從每個(gè)節(jié)點(diǎn)檢索原始數(shù)據(jù)。這意味著需要重寫(xiě)整個(gè)查詢(xún)引擎，需要的工作量相當(dāng)之大。 

進(jìn)一步，仔細(xì)研究一下 InfluxDB 和 TimeScaleDB 的設(shè)計(jì)，就會(huì)發(fā)現(xiàn)，它們的可擴(kuò)展性實(shí)際上是相當(dāng)有限的。它們將元數(shù)據(jù)存儲(chǔ)在一個(gè)中心位置，每個(gè)時(shí)間序列總是會(huì)關(guān)聯(lián)一組標(biāo)簽或標(biāo)識(shí)。這意味著，如果你有 10 億個(gè)時(shí)間序列，系統(tǒng)就需要存儲(chǔ) 10 億組標(biāo)簽?？闯鰡?wèn)題了嗎？當(dāng)你要聚合多個(gè)時(shí)間序列時(shí)，系統(tǒng)需要首先確定哪些時(shí)間序列符合標(biāo)簽過(guò)濾條件，而在一個(gè)很大的數(shù)據(jù)集中，這會(huì)導(dǎo)致很大的延遲。這就是所謂的時(shí)間序列數(shù)據(jù)庫(kù)的 High-cardinality 問(wèn)題。

那么應(yīng)該如何解決這個(gè)問(wèn)題呢？答案就是元數(shù)據(jù)處理的分布式設(shè)計(jì)。元數(shù)據(jù)不能存儲(chǔ)在一個(gè)中心位置，否則它很快就會(huì)成為一個(gè)瓶頸。一個(gè)簡(jiǎn)單的解決方案是，使用分布式關(guān)系數(shù)據(jù)庫(kù)來(lái)處理元數(shù)據(jù)，但是這會(huì)增加系統(tǒng)的復(fù)雜度，使得系統(tǒng)更難維護(hù)，成本也更高了。

TDengine 1.x 的設(shè)計(jì)就是將所有元數(shù)據(jù)存儲(chǔ)在管理節(jié)點(diǎn)（mnode）上，所以它也有 High-cardinality 的問(wèn)題。在 TDengine 2.x 中，我們做了一些改進(jìn)，就是將標(biāo)簽值存儲(chǔ)在每個(gè)虛擬節(jié)點(diǎn)（vnode）而不是中央管理節(jié)點(diǎn)上, 聚合查詢(xún)速度有保證，但系統(tǒng)啟動(dòng)時(shí)間在時(shí)間線(xiàn)超過(guò)千萬(wàn)后不可忍受，沒(méi)有完全解決這個(gè)業(yè)內(nèi)的難題。 

2、復(fù)雜性 / Complex

數(shù)據(jù)庫(kù)是存儲(chǔ)和分析數(shù)據(jù)的工具，但時(shí)序數(shù)據(jù)處理需要的可不僅僅是存儲(chǔ)和分析。在一個(gè)典型的時(shí)序數(shù)據(jù)處理平臺(tái)中，時(shí)序數(shù)據(jù)庫(kù)總是要與支持流處理、緩存、數(shù)據(jù)訂閱以及其他功能的工具集成，因此整個(gè)數(shù)據(jù)處理系統(tǒng)是有一定的復(fù)雜度的。

流式處理 / Stream Processing

時(shí)序數(shù)據(jù)就是一個(gè)流。為了更快地執(zhí)行操作或者發(fā)現(xiàn)錯(cuò)誤，我們需要在數(shù)據(jù)點(diǎn)到達(dá)系統(tǒng)時(shí)就進(jìn)行分析和處理，所以流處理天然適合時(shí)序數(shù)據(jù)。流處理可以是時(shí)間驅(qū)動(dòng)的，即在設(shè)定的時(shí)間間隔內(nèi)產(chǎn)生新的結(jié)果（在時(shí)序數(shù)據(jù)庫(kù)中一般稱(chēng)為連續(xù)查詢(xún)），也可以是事件驅(qū)動(dòng)的，即只要有新的數(shù)據(jù)點(diǎn)到達(dá)就產(chǎn)生新的結(jié)果。

InfluxDB、Prometheus、TimescaleDB 和 TDengine 都支持連續(xù)查詢(xún)。這對(duì)于監(jiān)控儀表盤(pán)是非常有用的，因?yàn)樗械膱D表都可以定期更新。但連續(xù)查詢(xún)并不能滿(mǎn)足所有的數(shù)據(jù)處理要求，就像 ETL，復(fù)雜事件處理，所以時(shí)序數(shù)據(jù)庫(kù)需要支持事件驅(qū)動(dòng)的流處理。

遺憾的是，目前市面上還沒(méi)有哪款時(shí)序數(shù)據(jù)庫(kù)支持。一般的方式是，將時(shí)序數(shù)據(jù)庫(kù)與 Spark、Flink 或其他流處理工具集成，而這些工具并不是為時(shí)序數(shù)據(jù)處理設(shè)計(jì)的。這些工具很難處理時(shí)間序列數(shù)據(jù)集中的數(shù)百萬(wàn)甚至數(shù)十億的流，即使它們能夠勝任，也要以大量的計(jì)算資源為代價(jià)。 

緩存 / Caching

對(duì)于很多時(shí)序數(shù)據(jù)應(yīng)用，像應(yīng)用性能監(jiān)控，某個(gè)特定時(shí)間的數(shù)據(jù)值并不重要，這些應(yīng)用只關(guān)注趨勢(shì)。然而，物聯(lián)網(wǎng)場(chǎng)景是個(gè)例外，應(yīng)該特別注意。比如，一個(gè)車(chē)隊(duì)管理系統(tǒng)總是要知道每輛卡車(chē)的當(dāng)前位置。對(duì)于一個(gè)智能工廠(chǎng)，系統(tǒng)總是需要知道每個(gè)閥門(mén)的當(dāng)前狀態(tài)和每個(gè)電表的當(dāng)前讀數(shù)。

大多數(shù)時(shí)序數(shù)據(jù)庫(kù)，包括 InfluxDB、TimescaleDB 和 Prometheus，本身都不能保證以最小的延遲返回時(shí)間序列中最新的數(shù)據(jù)點(diǎn)。為了使每個(gè)時(shí)間序列的當(dāng)前值能夠盡可能快地返回，沒(méi)有高延遲，很多開(kāi)發(fā)者選擇將這些數(shù)據(jù)平臺(tái)與 Redis 集成。當(dāng)新的數(shù)據(jù)點(diǎn)到達(dá)系統(tǒng)時(shí)，它們必須被同時(shí)寫(xiě)入 Redis 以及數(shù)據(jù)庫(kù)中。這種解決方案確實(shí)有效，但增加了系統(tǒng)的復(fù)雜性和運(yùn)維成本。

TDengine 從其第一個(gè)版本開(kāi)始就支持緩存了。在 TDengine 的很多用戶(hù)案例中，Redis 可以完全從系統(tǒng)中移除，從而使整個(gè)數(shù)據(jù)平臺(tái)的運(yùn)行更加簡(jiǎn)單，成本更低。

數(shù)據(jù)訂閱 / Data Subscription

消息隊(duì)列在很多系統(tǒng)架構(gòu)中有著重要的作用。傳入的數(shù)據(jù)點(diǎn)首先被寫(xiě)入消息隊(duì)列，然后被系統(tǒng)中的其他組件消費(fèi)，包括數(shù)據(jù)庫(kù)。消息隊(duì)列中的數(shù)據(jù)通常會(huì)被保留一段指定的時(shí)間（比如 Kafka 中的 7 天）。這與時(shí)序數(shù)據(jù)庫(kù)中的保留策略是一樣的。某個(gè)角度上來(lái)看，存儲(chǔ)的設(shè)計(jì)上，消息隊(duì)列與時(shí)序數(shù)據(jù)庫(kù)沒(méi)有本質(zhì)的區(qū)別。

大多數(shù)時(shí)序數(shù)據(jù)庫(kù)寫(xiě)入數(shù)據(jù)的效率非常高，一秒鐘可以達(dá)到數(shù)百萬(wàn)個(gè)數(shù)據(jù)點(diǎn)。這意味著，如果時(shí)序數(shù)據(jù)庫(kù)能夠提供數(shù)據(jù)訂閱功能，它們可以完全取代消息隊(duì)列，這就再次簡(jiǎn)化了系統(tǒng)的設(shè)計(jì)，進(jìn)而降低了成本。

目前市場(chǎng)上僅僅 TDengine 提供數(shù)據(jù)訂閱的功能，但現(xiàn)有版本訂閱的性能不夠，在大部分場(chǎng)景下，無(wú)法將 Kafka 這類(lèi)軟件從系統(tǒng)中剔除。

結(jié)論：沒(méi)有事件驅(qū)動(dòng)的流處理、緩存和數(shù)據(jù)訂閱這些功能，盡管時(shí)序數(shù)據(jù)庫(kù)仍然可以工作，但開(kāi)發(fā)人員不得不將其與其他工具集成，來(lái)實(shí)現(xiàn)所需的功能。這使得系統(tǒng)設(shè)計(jì)會(huì)相當(dāng)復(fù)雜，需要更多資源，也更難維護(hù)。如果時(shí)序數(shù)據(jù)庫(kù)內(nèi)置了這些功能，整個(gè)系統(tǒng)架構(gòu)就可以極大簡(jiǎn)化，運(yùn)維成本也會(huì)大大降低。

3、云原生 / Cloud Native

云計(jì)算越來(lái)越流行，云計(jì)算最美妙最吸引人的地方在于它的彈性——存儲(chǔ)資源和計(jì)算資源沒(méi)有上限，而我們只需要為實(shí)際使用的資源付費(fèi)。這也是所有應(yīng)用程序，包括時(shí)序數(shù)據(jù)庫(kù)，都在向云上轉(zhuǎn)移的一個(gè)主要原因。

遺憾的是，大多數(shù)數(shù)據(jù)庫(kù)只是“云就緒”（cloud-ready），而非云原生（cloud-native）。當(dāng)你購(gòu)買(mǎi)某些數(shù)據(jù)庫(kù)供應(yīng)商提供的云服務(wù)時(shí)，比如 TimescaleDB，你需要告訴系統(tǒng)你想要多少虛擬服務(wù)器（包括 CPU 和內(nèi)存配置），以及多少存儲(chǔ)。即使你沒(méi)有運(yùn)行任何查詢(xún)，你仍然不得不為計(jì)算資源付費(fèi)，如果你的數(shù)據(jù)規(guī)模增長(zhǎng)了，你還需要決定是否購(gòu)買(mǎi)更多資源。這種云解決方案，其實(shí)只是數(shù)據(jù)庫(kù)服務(wù)提供商在轉(zhuǎn)售云平臺(tái)。

要充分利用云平臺(tái)提供的優(yōu)勢(shì)，時(shí)序數(shù)據(jù)庫(kù)必須是云原生的。為了實(shí)現(xiàn)這一點(diǎn)，時(shí)序數(shù)據(jù)庫(kù)需要重新設(shè)計(jì)。這時(shí)候要重點(diǎn)考慮如下幾點(diǎn)。

1. 計(jì)算和存儲(chǔ)分離：在容器化環(huán)境中，特定的容器可能在任何時(shí)候啟動(dòng)或關(guān)閉，但存儲(chǔ)的數(shù)據(jù)是持久化的。傳統(tǒng)的數(shù)據(jù)庫(kù)設(shè)計(jì)無(wú)法應(yīng)對(duì)這種情況，因?yàn)閿?shù)據(jù)都存儲(chǔ)在本地。此外，為了運(yùn)行復(fù)雜的查詢(xún)或執(zhí)行批處理，需要?jiǎng)討B(tài)地增加更多計(jì)算節(jié)點(diǎn)，以加快處理速度。 
2. 可伸縮性：系統(tǒng)必須能夠根據(jù)負(fù)載和延遲要求，實(shí)現(xiàn)存儲(chǔ)和計(jì)算資源的水平擴(kuò)展或水平伸縮。對(duì)于計(jì)算資源來(lái)說(shuō)，系統(tǒng)不難做出決定。但是存儲(chǔ)資源就不一樣了。要實(shí)現(xiàn)分布式數(shù)據(jù)庫(kù)的伸縮，當(dāng)數(shù)據(jù)實(shí)時(shí)寫(xiě)入，或者查詢(xún)正在執(zhí)行的時(shí)候，數(shù)據(jù)庫(kù)的分片可能需要進(jìn)行合并或分割。設(shè)計(jì)一個(gè)能夠完成這一任務(wù)的系統(tǒng)并不容易。
3. 自動(dòng)化、可觀測(cè)性：時(shí)序數(shù)據(jù)庫(kù)的狀態(tài)必須能與系統(tǒng)的其他組成部分一起被監(jiān)控，所以一個(gè)好的時(shí)序數(shù)據(jù)庫(kù)需要提供全面的可觀測(cè)性。同時(shí)系統(tǒng)必須提供便于在 K8S 下自動(dòng)化管理的接口，否則運(yùn)營(yíng)管理將變得復(fù)雜。

現(xiàn)在這個(gè)時(shí)候，任何新開(kāi)發(fā)的時(shí)序數(shù)據(jù)庫(kù)都必須是云原生的。雖然 TDengine 的設(shè)計(jì)從第一天起就是一個(gè)具有水平擴(kuò)展、高可用、高可靠的的分布式架構(gòu)，但目前的 2.x 還不能算為云原生數(shù)據(jù)庫(kù)，因?yàn)樗恢С执嫠惴蛛x，而且在云平臺(tái)的部署和管理還較為欠缺。

4、方便易用 / Ease of use

盡管方便易用這個(gè)詞有點(diǎn)主觀，但是我們可以嘗試在這里列出幾點(diǎn)，從不同方面說(shuō)說(shuō)一個(gè)對(duì)開(kāi)發(fā)者更友好的時(shí)序數(shù)據(jù)庫(kù)應(yīng)該做到哪些。

1. 查詢(xún)語(yǔ)言：因?yàn)?SQL 仍然是最流行的數(shù)據(jù)庫(kù)查詢(xún)語(yǔ)言，能支持 SQL，對(duì)開(kāi)發(fā)者而言就沒(méi)什么使用門(mén)檻了。另一方面，專(zhuān)用的查詢(xún)語(yǔ)言需要開(kāi)發(fā)者花費(fèi)自己寶貴的時(shí)間來(lái)學(xué)習(xí)，還會(huì)增加向其他數(shù)據(jù)庫(kù)遷移的成本。InfluxDB，OpenTSDB，Prometheus，RRDTool 等都不支持 SQL，但 TDengine 與 TimeScaleDB 支持 SQL。
2. 交互式控制臺(tái)：對(duì)開(kāi)發(fā)者而言，使用一個(gè)交互式的控制臺(tái)來(lái)管理運(yùn)行的數(shù)據(jù)庫(kù)或執(zhí)行即席查詢(xún)是最方便的。對(duì)于部署在云上的時(shí)序數(shù)據(jù)庫(kù)也是如此。
3. 示例代碼：開(kāi)發(fā)者往往不會(huì)花時(shí)間把整個(gè)文檔通讀一遍，而是直接學(xué)習(xí)如何使用某個(gè)特定的特性或 API。新的數(shù)據(jù)庫(kù)必須用主流的編程語(yǔ)言提供示例代碼，開(kāi)發(fā)者只需要把這些代碼復(fù)制粘貼到自己的應(yīng)用中，如果需要的話(huà)再根據(jù)自己的具體情況稍加修改即可。
4. 數(shù)據(jù)遷移工具：數(shù)據(jù)庫(kù)管理系統(tǒng)需要提供一到多個(gè)方便高效的數(shù)據(jù)導(dǎo)入導(dǎo)出工具。源頭和目標(biāo)可能是一個(gè)文件、另一個(gè)數(shù)據(jù)庫(kù)或者是遠(yuǎn)程數(shù)據(jù)中心中的一個(gè)副本。要遷移的數(shù)據(jù)可能是整個(gè)數(shù)據(jù)庫(kù)，一組表，或者是一個(gè)指定時(shí)間段中的數(shù)據(jù)點(diǎn)。

技術(shù)的挑戰(zhàn)

上面我總結(jié)了目前市場(chǎng)上時(shí)序數(shù)據(jù)庫(kù)（Time Series Database）幾大亟待解決的問(wèn)題，包括 Scalability，Complex，Cloud Native 與 Ease of Use。這些問(wèn)題，從技術(shù)上來(lái)看，都是硬骨頭，否則早被廠(chǎng)商解決了。有問(wèn)題，那就有機(jī)會(huì)。2016 年底，我就是由于研究后，發(fā)現(xiàn) InfluxDB，TimeScaleDB，Prometheus，OpenTSDB 等有各種不足，才開(kāi)始決定進(jìn)入這個(gè)行業(yè)的。5 年多過(guò)去，我?guī)ьI(lǐng) TDengine 團(tuán)隊(duì)力圖去解決這些問(wèn)題，版本從最開(kāi)始的 1.0，到 1.6，到 2.0、2.6，團(tuán)隊(duì)從 5 個(gè)人發(fā)展到了 80 多人，專(zhuān)職研發(fā)都已經(jīng)超過(guò) 50 人。TDengine 與很多時(shí)序數(shù)據(jù)庫(kù)相比，是一不錯(cuò)的產(chǎn)品，但遺憾的是，上述的問(wèn)題還只是部分的解決。

作為一個(gè)堅(jiān)信技術(shù)能改變世界的創(chuàng)始人，不解決這些問(wèn)題難以入眠，難以證明自己以及整個(gè)團(tuán)隊(duì)的技術(shù)實(shí)力。因此在 2021 年 6 月，我決定正式啟動(dòng) TDengine 3.0 的研發(fā)，投入了公司最大的資源，讓所有研發(fā)同學(xué)專(zhuān)心新版本的研發(fā)，以解決上述技術(shù)難題為目標(biāo)。TDengine 3.0 不僅要瞄準(zhǔn)未來(lái)，成為一個(gè)云原生時(shí)序數(shù)據(jù)庫(kù)，它還需要能支持 100 億條時(shí)間線(xiàn)，100 個(gè)節(jié)點(diǎn)，讓其具備極強(qiáng)的水平擴(kuò)展和伸縮能力，徹底解決業(yè)內(nèi)的“High Cardinality”問(wèn)題。內(nèi)置的流式計(jì)算、數(shù)據(jù)訂閱、緩存等功能在時(shí)序數(shù)據(jù)場(chǎng)景下，要能完勝 Spark，Kafka，Redis 等通用場(chǎng)景下的工具。最終的目標(biāo)就是降低時(shí)序數(shù)據(jù)處理系統(tǒng)的總擁有成本，幫助用戶(hù)挖掘出數(shù)據(jù)的價(jià)值，讓最終用戶(hù)成功；而且讓開(kāi)發(fā)者用的順手、用的放心，讓開(kāi)發(fā)者成功。

一年多過(guò)去，TDengine 的研發(fā)同學(xué)沒(méi)日沒(méi)夜的設(shè)計(jì)、編碼和測(cè)試，TDengine 3.0 終于可以揭開(kāi)面紗。我們決定在 8 月 13 日召開(kāi) TDengine 開(kāi)發(fā)者大會(huì)，為大家詳細(xì)揭秘 TDengine 3.0 的核心設(shè)計(jì)，并將 3.0 正式發(fā)布，在 GitHub 上公開(kāi)其核心源代碼。我們還邀請(qǐng)了業(yè)內(nèi)的很多技術(shù)專(zhuān)家、投資人，以及我們的用戶(hù)，共同奉上一整天的精彩分享。

8 月 13 日，我在 TDengine 開(kāi)發(fā)者大會(huì)上等你。

陶建輝

2022 年 7 月 24 日于北京望京

假設(shè)每個(gè)智能電表采集電流、電壓、相位三個(gè)量，有多個(gè)智能電表，每個(gè)電表有位置 location 和分組 group ID 的靜態(tài)屬性。其采集的數(shù)據(jù)類(lèi)似如下的表格：

每一條記錄都有設(shè)備 ID，時(shí)間戳，采集的物理量以及每個(gè)設(shè)備相關(guān)的靜態(tài)標(biāo)簽。每個(gè)設(shè)備是受外界的觸發(fā)，或按照設(shè)定的周期采集數(shù)據(jù)。采集的數(shù)據(jù)點(diǎn)是時(shí)序的，是一個(gè)數(shù)據(jù)流。

TDengine 最經(jīng)典的處理方式就是「一個(gè)數(shù)據(jù)采集點(diǎn)一張表」，那針對(duì)表中的 Device ID ，就可以有相應(yīng)的單獨(dú)的表。
這樣建表的好處就很多，例如由于不同采集設(shè)備產(chǎn)生數(shù)據(jù)的過(guò)程完全獨(dú)立，每個(gè)設(shè)備的數(shù)據(jù)源是唯一的，一張表也就只有一個(gè)寫(xiě)入者，這樣就可采用無(wú)鎖方式來(lái)寫(xiě)，寫(xiě)入速度就能大幅提升。再有就是一個(gè)數(shù)據(jù)采集點(diǎn)的數(shù)據(jù)是以塊為單位連續(xù)存儲(chǔ)的。如果讀取一個(gè)時(shí)間段的數(shù)據(jù)，它能大幅減少隨機(jī)讀取操作，成數(shù)量級(jí)的提升讀取和查詢(xún)速度。

當(dāng)然，隨著設(shè)備的增加，一個(gè)數(shù)據(jù)采集點(diǎn)一張表就會(huì)導(dǎo)致表的數(shù)量巨增，為了解決采集點(diǎn)的聚合操作，便引入了「超級(jí)表」這個(gè)概念。超級(jí)表是指某一特定類(lèi)型的數(shù)據(jù)采集點(diǎn)的集合。同一類(lèi)型的數(shù)據(jù)采集點(diǎn)，其表的結(jié)構(gòu)是完全一樣的，但每個(gè)表（數(shù)據(jù)采集點(diǎn)）的靜態(tài)屬性（標(biāo)簽）是不一樣的。針對(duì)超級(jí)表的查詢(xún)，TDengine 將把所有子表中的數(shù)據(jù)視為一個(gè)整體數(shù)據(jù)集進(jìn)行處理，會(huì)先把滿(mǎn)足標(biāo)簽過(guò)濾條件的表從超級(jí)表中找出來(lái)，然后再掃描這些表的時(shí)間序列數(shù)據(jù)，進(jìn)行聚合操作，這樣需要掃描的數(shù)據(jù)集會(huì)大幅減少，從而顯著提高查詢(xún)的性能。本質(zhì)上，TDengine 通過(guò)對(duì)超級(jí)表查詢(xún)的支持，實(shí)現(xiàn)了多個(gè)同類(lèi)數(shù)據(jù)采集點(diǎn)的高效聚合。

至于提到的高并發(fā)問(wèn)題，TDengine 作為一款 Time Series Database，支持以集群方式部署，以提升系統(tǒng)的處理能力和高可用性。TDengine 集群支持任意數(shù)據(jù)的多副本從而提升高可用性，并自動(dòng)實(shí)現(xiàn)負(fù)載均衡。同時(shí) TDengine 集群具有很好的橫向擴(kuò)展能力以處理更多的數(shù)據(jù)采集點(diǎn)和更大的數(shù)據(jù)量，并且分布式的結(jié)構(gòu)更保證了TSDB的高可用性。

元數(shù)據(jù)信息

TSDB 中存儲(chǔ)的元數(shù)據(jù)包含屬于其所在的 VNODE 中表的類(lèi)型，schema 的定義等。對(duì)于超級(jí)表和超級(jí)表下的子表而言，又包含了 tag 的 schema 定義以及子表的 tag 值等。對(duì)于元數(shù)據(jù)信息而言，TSDB 就相當(dāng)于一個(gè)全內(nèi)存的 KV 型數(shù)據(jù)庫(kù)，屬于該 VNODE 的表對(duì)象全部在內(nèi)存中，方便快速查詢(xún)表的信息。除此之外，TSDB 還對(duì)其中的子表，按照 tag 的第一列取值做了全內(nèi)存的索引，大大加快了對(duì)于標(biāo)簽的過(guò)濾查詢(xún)。TSDB 中的元數(shù)據(jù)的最新?tīng)顟B(tài)在落盤(pán)時(shí)，會(huì)以追加（append-only）的形式，寫(xiě)入到 meta 文件中。meta 文件只進(jìn)行追加操作，即便是元數(shù)據(jù)的刪除，也會(huì)以一條記錄的形式寫(xiě)入到文件末尾。TSDB 也提供了對(duì)于元數(shù)據(jù)的修改操作，如表 schema 的修改，tag schema 的修改以及 tag 值的修改等。

時(shí)間序列數(shù)據(jù)

每個(gè) TSDB 在創(chuàng)建時(shí)，都會(huì)事先分配一定量的內(nèi)存緩沖區(qū)，且內(nèi)存緩沖區(qū)的大小可配可修改。表采集的時(shí)序數(shù)據(jù)，在寫(xiě)入 TSDB 時(shí)，首先以追加的方式寫(xiě)入到分配的內(nèi)存緩沖區(qū)中，同時(shí)建立基于時(shí)間戳的內(nèi)存索引，方便快速查詢(xún)。當(dāng)內(nèi)存緩沖區(qū)的數(shù)據(jù)積累到一定的程度時(shí)（達(dá)到內(nèi)存緩沖區(qū)總大小的1/3），則會(huì)觸發(fā)落盤(pán)操作，將緩沖區(qū)中的數(shù)據(jù)持久化到硬盤(pán)文件上。時(shí)間序列數(shù)據(jù)在內(nèi)存緩沖區(qū)中是以行（row）的形式存儲(chǔ)的。

而時(shí)間序列數(shù)據(jù)在寫(xiě)入到 TSDB 的數(shù)據(jù)文件時(shí)，是以列（column）的形式存儲(chǔ)的。TSDB 中的數(shù)據(jù)文件包含多個(gè)數(shù)據(jù)文件組，每個(gè)數(shù)據(jù)文件組中又包含 .head、.data 和.last 三個(gè)文件，如（v2f1801.head、v2f1801.data、v2f1801.last）數(shù)據(jù)文件組。TSDB 中的數(shù)據(jù)文件組是按照時(shí)間跨度進(jìn)行分片的，默認(rèn)是 10 天一個(gè)文件組，且可通過(guò)配置文件及建庫(kù)選項(xiàng)進(jìn)行配置。分片的數(shù)據(jù)文件組又按照編號(hào)遞增排列，方便快速定位某一時(shí)間段的時(shí)序數(shù)據(jù)，高效定位數(shù)據(jù)文件組。時(shí)間序列數(shù)據(jù)在 TSDB 的數(shù)據(jù)文件中是以塊的形式進(jìn)行列式存儲(chǔ)的，每個(gè)塊中只包含一張表的數(shù)據(jù)，且數(shù)據(jù)在一個(gè)塊中是按照時(shí)間順序遞增排列的。在一個(gè)數(shù)據(jù)文件組中，.head文件負(fù)責(zé)存儲(chǔ)數(shù)據(jù)塊的索引及統(tǒng)計(jì)信息，如每個(gè)塊的位置，壓縮算法，時(shí)間戳范圍等。存儲(chǔ)在.head文件中一張表的索引信息是按照數(shù)據(jù)塊中存儲(chǔ)的數(shù)據(jù)的時(shí)間遞增排列的，方便進(jìn)行折半查找等工作。.head和.last文件是存儲(chǔ)真實(shí)數(shù)據(jù)塊的文件，若數(shù)據(jù)塊中的數(shù)據(jù)累計(jì)到一定程度，則會(huì)寫(xiě)入.data文件中，否則，會(huì)寫(xiě)入.last文件中，等待下次落盤(pán)時(shí)合并數(shù)據(jù)寫(xiě)入.data文件中，從而大大減少文件中塊的個(gè)數(shù)，避免數(shù)據(jù)的過(guò)度碎片化。

從字面上來(lái)理解，時(shí)間序列數(shù)據(jù)就是具有時(shí)間排序的數(shù)據(jù)。百度百科的定義是：“時(shí)間序列數(shù)據(jù)是同一統(tǒng)一指標(biāo)按時(shí)間順序記錄的數(shù)據(jù)列?！比绻靡恍┥钪谐Ｒ?jiàn)的數(shù)據(jù)來(lái)舉例，你可能就會(huì)覺(jué)得時(shí)間序列數(shù)據(jù)并不是多么晦澀難懂了，比如我們現(xiàn)在家家戶(hù)戶(hù)都在用的智能電表。每家的每一塊電表都在不同的時(shí)間記錄著家中電量的消耗，電表上總在跳動(dòng)的指示燈就代表著時(shí)間序列數(shù)據(jù)的跳動(dòng)。那每一棟樓、每個(gè)小區(qū)甚至大到每一座城市，數(shù)以萬(wàn)計(jì)的智能電表在相同的時(shí)間間隔下產(chǎn)生的數(shù)據(jù)，我們就可以用 Time Series Database 來(lái)記錄。

上圖是一系列的電表數(shù)據(jù)統(tǒng)計(jì)，從中我們可以看出時(shí)間序列數(shù)據(jù)有幾個(gè)明顯的特征。首先每組數(shù)據(jù)都帶有時(shí)間戳，其次數(shù)據(jù)都是結(jié)構(gòu)化的，以數(shù)字性為主，再?gòu)碾姳頂?shù)據(jù)的處理與分析需求出發(fā)，我們可以總結(jié)出時(shí)間序列數(shù)據(jù)的幾大特點(diǎn)：

1、所有采集的數(shù)據(jù)都是時(shí)序數(shù)據(jù)

2、數(shù)據(jù)都是結(jié)構(gòu)化的

3、一個(gè)采集點(diǎn)的數(shù)據(jù)源是唯一的

4、數(shù)據(jù)很少有更新或刪除操作

5、數(shù)據(jù)一定是指定時(shí)間段和指定區(qū)域查找的

6、實(shí)時(shí)數(shù)據(jù)庫(kù)數(shù)據(jù)量巨大，一天的數(shù)據(jù)量就超過(guò)100億條

再以監(jiān)控?cái)?shù)據(jù)為例，上圖是對(duì)某項(xiàng)目監(jiān)控?cái)?shù)據(jù)進(jìn)行的統(tǒng)計(jì)分析，做過(guò)運(yùn)維的小伙伴一定非常熟悉，橫軸是時(shí)間，縱軸是采集量，可以看出：

1、有些時(shí)間序列數(shù)據(jù)在很長(zhǎng)一段時(shí)間內(nèi)都是固定的值，但是某些時(shí)間點(diǎn)也會(huì)產(chǎn)生異常跳變，異常檢測(cè)在時(shí)間序列數(shù)據(jù)的處理過(guò)程中，也是非常重要的一環(huán)，本文不過(guò)多展開(kāi)；

2、有些時(shí)間序列數(shù)據(jù)在一段時(shí)間內(nèi)是一個(gè)變化趨勢(shì)；

3、有些時(shí)間序列數(shù)據(jù)在一定數(shù)值范圍內(nèi)會(huì)進(jìn)行波動(dòng)，有些波動(dòng)頻率高，有些波動(dòng)頻率低；在對(duì)應(yīng)上我們剛才說(shuō)的時(shí)間序列數(shù)據(jù)的特點(diǎn)，就非常容易理解了。

通過(guò)上述文字，大家了解了時(shí)間序列數(shù)據(jù)的特點(diǎn)，那生活中有什么場(chǎng)景是可以用 Time Series Database 來(lái)處理的呢？TDengine 時(shí)序數(shù)據(jù)庫(kù)(TSDB)在產(chǎn)品不斷研發(fā)創(chuàng)新的過(guò)程中，也有幸結(jié)識(shí)了一些不同業(yè)務(wù)場(chǎng)景上需要使用 Time Series Database 的合作伙伴。簡(jiǎn)單的舉個(gè)例子，出行方面有理想汽車(chē)、蔚來(lái)汽車(chē)、領(lǐng)跑汽車(chē)等都在車(chē)聯(lián)網(wǎng)數(shù)據(jù)、加電基站監(jiān)測(cè)等方面運(yùn)用了 TDengine，快遞運(yùn)輸行業(yè)中有順豐科技、貨拉拉等也將 TDengine 運(yùn)用在了業(yè)務(wù)監(jiān)測(cè)或數(shù)據(jù)監(jiān)測(cè)上。但關(guān)于 Time Series Database 的應(yīng)用可遠(yuǎn)不止這些，更多的經(jīng)典案例歡迎大家移步 TDengine 官網(wǎng)-博客-用戶(hù)案例中查閱，也歡迎大家和我們一起探討。

在物聯(lián)網(wǎng)等技術(shù)的快速發(fā)展下，大規(guī)模設(shè)備所產(chǎn)生的時(shí)間序列數(shù)據(jù)爆發(fā)式增長(zhǎng)，企業(yè)在調(diào)研時(shí)序數(shù)據(jù)庫(kù)時(shí)，尤其看重?cái)?shù)據(jù)庫(kù)性能的強(qiáng)弱。聚焦“智慧環(huán)保”物聯(lián)網(wǎng)應(yīng)用研發(fā)的中科惠軟，此前就面臨著海量時(shí)間序列數(shù)據(jù)的查詢(xún)分析難題，希望能調(diào)研到一款合適的時(shí)序數(shù)據(jù)庫(kù)，助力產(chǎn)品發(fā)現(xiàn)深層次的環(huán)境問(wèn)題，從而幫助污染源企業(yè)節(jié)能減排，增加效益。

由于 InfluxDB集群 版本需要收費(fèi)，最終他們選擇了單實(shí)例進(jìn)行對(duì)比測(cè)試，開(kāi)始準(zhǔn)備兩臺(tái)配置參數(shù)一致的測(cè)試服務(wù)器進(jìn)行多方面的應(yīng)用場(chǎng)景、穩(wěn)定性以及性能測(cè)試。

以上中科惠軟所做的性能測(cè)試結(jié)果（僅供參考），InfluxDB 在寫(xiě)入、查詢(xún)等方面的性能均遜于同類(lèi)型產(chǎn)品 TDengine，且在中科惠軟的測(cè)試中還發(fā)現(xiàn)，InfluxDB 需要借助 Kafka、MQTT 等消息隊(duì)列中間件實(shí)現(xiàn)批量寫(xiě)入，從而提升數(shù)據(jù)的寫(xiě)入性能。綜合智能環(huán)保項(xiàng)目多方面應(yīng)用場(chǎng)景測(cè)試，以及后期智慧環(huán)保領(lǐng)域系統(tǒng)國(guó)產(chǎn)化需要，中科惠軟最終選型了 TDengine 來(lái)解決海量時(shí)間序列數(shù)據(jù)處理難題。

我們?cè)谧隹蛻?hù)調(diào)研時(shí)還發(fā)現(xiàn)，很多用戶(hù)在選型時(shí)，棄選 InfluxDB 的原因之一是其開(kāi)源版本只支持一個(gè)節(jié)點(diǎn)，即 InfluxDB集群功能未開(kāi)放，還存在前后版本兼容性問(wèn)題，非國(guó)產(chǎn)化產(chǎn)品。以吉科軟公司為例，他們最初在車(chē)輛監(jiān)管項(xiàng)目中使用的就是 InfluxDB+Redis 的組合，但二期項(xiàng)目需要重新升級(jí)改版，不得不考慮業(yè)務(wù)規(guī)模的快速增加以及 InfluxDB集群功能不開(kāi)放導(dǎo)致的單節(jié)點(diǎn)問(wèn)題。

事實(shí)上，為了積累關(guān)注度以及使用人群，InfluxDB集群在最初也是開(kāi)源狀態(tài)，后面在積累到一定的知名度后，InfluxDB集群又實(shí)行了閉源，從開(kāi)源精神出發(fā)，這在一定程度上也是傷害了一眾投入關(guān)注和精力的開(kāi)發(fā)者。但從公司業(yè)務(wù)角度而言，InfluxDB集群功能閉源也無(wú)可厚非，滿(mǎn)足了企業(yè)發(fā)展商業(yè)化的需求。

但不得不說(shuō)，InfluxDB集群從免費(fèi)獲取到收費(fèi)獲取，成為了其尋求商業(yè)化變現(xiàn)的最有效途徑，也讓其失去了一部分的擁躉。而且對(duì)于一眾中國(guó)企業(yè)來(lái)說(shuō)，盡管花費(fèi)了高昂的價(jià)格購(gòu)買(mǎi)了 InfluxDB集群版本，但其產(chǎn)品性能是否真的能夠支撐自身業(yè)務(wù)的發(fā)展還是一個(gè)謎題，且作為一款外來(lái)的時(shí)序數(shù)據(jù)庫(kù)產(chǎn)品，InfluxDB 的本地化服務(wù)也十分有限。

綜上所述，InfluxDB集群不開(kāi)放且服務(wù)費(fèi)用高昂，本地化服務(wù)質(zhì)量低以及產(chǎn)品性能不配位幾大原因，也算是導(dǎo)致 InfluxDB 在中國(guó)企業(yè)中的應(yīng)用逐年降低的“元兇”。

TDengine 的設(shè)計(jì)是基于單個(gè)硬件、軟件系統(tǒng)不可靠，基于任何單臺(tái)計(jì)算機(jī)都無(wú)法提供足夠計(jì)算能力和存儲(chǔ)能力處理海量數(shù)據(jù)的假設(shè)進(jìn)行設(shè)計(jì)的。因此 TDengine 從研發(fā)的第一天起，就按照分布式高可靠架構(gòu)進(jìn)行設(shè)計(jì)，是支持水平擴(kuò)展的，這樣任何單臺(tái)或多臺(tái)服務(wù)器發(fā)生硬件故障或軟件錯(cuò)誤都不影響系統(tǒng)的可用性和可靠性。并且和 InfluxDB 不同的是，TDengine 選擇將集群功能開(kāi)源。本文重點(diǎn)講解 TDengine 集群的主要邏輯單元的設(shè)計(jì)。

TDengine 分布式架構(gòu)的邏輯結(jié)構(gòu)圖如下：

一個(gè)完整的 TDengine 系統(tǒng)是運(yùn)行在一到多個(gè)物理節(jié)點(diǎn)上的，邏輯上，它包含數(shù)據(jù)節(jié)點(diǎn)(dnode)、TDengine 應(yīng)用驅(qū)動(dòng)(taosc)以及應(yīng)用(app)。系統(tǒng)中存在一到多個(gè)數(shù)據(jù)節(jié)點(diǎn)，這些數(shù)據(jù)節(jié)點(diǎn)組成一個(gè)集群(cluster)。應(yīng)用通過(guò) taosc 的 API 與 TDengine 集群進(jìn)行互動(dòng)。下面對(duì)每個(gè)邏輯單元進(jìn)行簡(jiǎn)要介紹。

物理節(jié)點(diǎn)(pnode)： pnode 是一獨(dú)立運(yùn)行、擁有自己的計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)能力的計(jì)算機(jī)，可以是安裝有OS的物理機(jī)、虛擬機(jī)或 Docker 容器。物理節(jié)點(diǎn)由其配置的 FQDN (Fully Qualified Domain Name)來(lái)標(biāo)識(shí)。TDengine 完全依賴(lài) FQDN 來(lái)進(jìn)行網(wǎng)絡(luò)通訊，如果不了解 FQDN，請(qǐng)看博文《一篇文章說(shuō)清楚 TDengine 的 FQDN》。

數(shù)據(jù)節(jié)點(diǎn)(dnode)： dnode 是 TDengine 服務(wù)器側(cè)執(zhí)行代碼 taosd 在物理節(jié)點(diǎn)上的一個(gè)運(yùn)行實(shí)例，一個(gè)工作的系統(tǒng)必須有至少一個(gè)數(shù)據(jù)節(jié)點(diǎn)。dnode 包含零到多個(gè)邏輯的虛擬節(jié)點(diǎn)(vnode)，零或者至多一個(gè)邏輯的管理節(jié)點(diǎn)(mnode)。dnode 在系統(tǒng)中的唯一標(biāo)識(shí)由實(shí)例的 End Point (EP)決定。EP 是 dnode 所在物理節(jié)點(diǎn)的 FQDN (Fully Qualified Domain Name)和系統(tǒng)所配置的網(wǎng)絡(luò)端口號(hào)(Port)的組合。通過(guò)配置不同的端口，一個(gè)物理節(jié)點(diǎn)(一臺(tái)物理機(jī)、虛擬機(jī)或容器）可以運(yùn)行多個(gè)實(shí)例，或有多個(gè)數(shù)據(jù)節(jié)點(diǎn)。

虛擬節(jié)點(diǎn)(vnode)： 為更好的支持?jǐn)?shù)據(jù)分片、負(fù)載均衡，防止數(shù)據(jù)過(guò)熱或傾斜，數(shù)據(jù)節(jié)點(diǎn)被虛擬化成多個(gè)虛擬節(jié)點(diǎn)(vnode，圖中 V2, V3, V4等)。每個(gè) vnode 都是一個(gè)相對(duì)獨(dú)立的工作單元，是時(shí)序數(shù)據(jù)存儲(chǔ)的基本單元，具有獨(dú)立的運(yùn)行線(xiàn)程、內(nèi)存空間與持久化存儲(chǔ)的路徑。一個(gè) vnode 包含一定數(shù)量的表（數(shù)據(jù)采集點(diǎn)）。當(dāng)創(chuàng)建一張新表時(shí)，系統(tǒng)會(huì)檢查是否需要?jiǎng)?chuàng)建新的 vnode。一個(gè)數(shù)據(jù)節(jié)點(diǎn)上能創(chuàng)建的 vnode 的數(shù)量取決于該數(shù)據(jù)節(jié)點(diǎn)所在物理節(jié)點(diǎn)的硬件資源。一個(gè) vnode 只屬于一個(gè) DB，但一個(gè) DB 可以有多個(gè) vnode。一個(gè) vnode 除存儲(chǔ)的時(shí)序數(shù)據(jù)外，也保存有所包含的表的 schema、標(biāo)簽值等。一個(gè)虛擬節(jié)點(diǎn)由所屬的數(shù)據(jù)節(jié)點(diǎn)的EP，以及所屬的 VGroup ID 在系統(tǒng)內(nèi)唯一標(biāo)識(shí)，由管理節(jié)點(diǎn)創(chuàng)建并管理。

管理節(jié)點(diǎn)(mnode)： 一個(gè)虛擬的邏輯單元，負(fù)責(zé)所有數(shù)據(jù)節(jié)點(diǎn)運(yùn)行狀態(tài)的監(jiān)控和維護(hù)，以及節(jié)點(diǎn)之間的負(fù)載均衡(圖中 M)。同時(shí)，管理節(jié)點(diǎn)也負(fù)責(zé)元數(shù)據(jù)(包括用戶(hù)、數(shù)據(jù)庫(kù)、表、靜態(tài)標(biāo)簽等)的存儲(chǔ)和管理，因此也稱(chēng)為 Meta Node。TDengine 集群中可配置多個(gè)(最多不超過(guò) 3 個(gè)) mnode，它們自動(dòng)構(gòu)建成為一個(gè)虛擬管理節(jié)點(diǎn)組(圖中 M0, M1, M2)。

mnode 間采用 master/slave 的機(jī)制進(jìn)行管理，而且采取強(qiáng)一致方式進(jìn)行數(shù)據(jù)同步, 任何數(shù)據(jù)更新操作只能在 Master 上進(jìn)行。mnode 集群的創(chuàng)建由系統(tǒng)自動(dòng)完成，無(wú)需人工干預(yù)。每個(gè) dnode 上至多有一個(gè) mnode，由所屬的數(shù)據(jù)節(jié)點(diǎn)的EP來(lái)唯一標(biāo)識(shí)。每個(gè) dnode 通過(guò)內(nèi)部消息交互自動(dòng)獲取整個(gè)集群中所有 mnode 所在的 dnode 的EP。

虛擬節(jié)點(diǎn)組(VGroup)： 不同數(shù)據(jù)節(jié)點(diǎn)上的 vnode 可以組成一個(gè)虛擬節(jié)點(diǎn)組(vnode group)來(lái)保證系統(tǒng)的高可靠。虛擬節(jié)點(diǎn)組內(nèi)采取 master/slave 的方式進(jìn)行管理。寫(xiě)操作只能在 master vnode 上進(jìn)行，系統(tǒng)采用異步復(fù)制的方式將數(shù)據(jù)同步到 slave vnode，這樣確保了一份數(shù)據(jù)在多個(gè)物理節(jié)點(diǎn)上有拷貝。一個(gè) vgroup 里虛擬節(jié)點(diǎn)個(gè)數(shù)就是數(shù)據(jù)的副本數(shù)。如果一個(gè) DB 的副本數(shù)為 N，系統(tǒng)必須有至少 N 數(shù)據(jù)節(jié)點(diǎn)。副本數(shù)在創(chuàng)建DB時(shí)通過(guò)參數(shù) replica 可以指定，缺省為 1。使用 TDengine 的多副本特性，可以不再需要昂貴的磁盤(pán)陣列等存儲(chǔ)設(shè)備，就可以獲得同樣的數(shù)據(jù)高可靠性。虛擬節(jié)點(diǎn)組由管理節(jié)點(diǎn)創(chuàng)建、管理，并且由管理節(jié)點(diǎn)分配一個(gè)系統(tǒng)唯一的 ID，VGroup ID。如果兩個(gè)虛擬節(jié)點(diǎn)的 vnode group ID 相同，說(shuō)明他們屬于同一個(gè)組，數(shù)據(jù)互為備份。虛擬節(jié)點(diǎn)組里虛擬節(jié)點(diǎn)的個(gè)數(shù)是可以動(dòng)態(tài)改變的，容許只有一個(gè)，也就是沒(méi)有數(shù)據(jù)復(fù)制。VGroup ID 是永遠(yuǎn)不變的，即使一個(gè)虛擬節(jié)點(diǎn)組被刪除，它的ID也不會(huì)被收回重復(fù)利用。

TAOSC： taosc 是 TDengine 給應(yīng)用提供的驅(qū)動(dòng)程序(driver)，負(fù)責(zé)處理應(yīng)用與集群的接口交互，提供 C/C++ 語(yǔ)言原生接口，內(nèi)嵌于 JDBC、C#、Python、Go、Node.js 語(yǔ)言連接庫(kù)里。應(yīng)用都是通過(guò) taosc 而不是直接連接集群中的數(shù)據(jù)節(jié)點(diǎn)與整個(gè)集群進(jìn)行交互的。這個(gè)模塊負(fù)責(zé)獲取并緩存元數(shù)據(jù)；將插入、查詢(xún)等請(qǐng)求轉(zhuǎn)發(fā)到正確的數(shù)據(jù)節(jié)點(diǎn)；在把結(jié)果返回給應(yīng)用時(shí)，還需要負(fù)責(zé)最后一級(jí)的聚合、排序、過(guò)濾等操作。對(duì)于 JDBC、C/C++、C#、Python、Go、Node.js 接口而言，這個(gè)模塊是在應(yīng)用所處的物理節(jié)點(diǎn)上運(yùn)行。同時(shí)，為支持全分布式的 RESTful 接口，taosc 在 TDengine 集群的每個(gè) dnode 上都有一運(yùn)行實(shí)例。

以上就是 TDengine 集群的主要邏輯單元，我們將會(huì)通過(guò)更多文章，向大家解讀 TDengine 集群的更多設(shè)計(jì)秘籍。

• 數(shù)據(jù)是時(shí)序的，一定帶有時(shí)間戳：聯(lián)網(wǎng)的設(shè)備按照設(shè)定的周期，或受外部的事件觸發(fā)，源源不斷的產(chǎn)生數(shù)據(jù)，每一個(gè)數(shù)據(jù)點(diǎn)是在一時(shí)間點(diǎn)產(chǎn)生的，這個(gè)時(shí)間對(duì)于數(shù)據(jù)的計(jì)算和分析十分重要，必須要記錄。
• 數(shù)據(jù)是結(jié)構(gòu)化的：網(wǎng)絡(luò)爬蟲(chóng)的數(shù)據(jù)、微博、微信的海量數(shù)據(jù)都是非結(jié)構(gòu)化的，可以是文字、圖片、視頻等。但時(shí)間序列數(shù)據(jù)往往是結(jié)構(gòu)化的，而且是數(shù)值型的，比如智能電表采集的電流、電壓就可以用 4 字節(jié)的標(biāo)準(zhǔn)的浮點(diǎn)數(shù)來(lái)表示。
• 數(shù)據(jù)極少有更新操作：時(shí)間序列數(shù)據(jù)是機(jī)器日志數(shù)據(jù)，一般不容許而且也沒(méi)有修改的必要。很少有場(chǎng)景，需要對(duì)采集的原始數(shù)據(jù)進(jìn)行修改。
• 數(shù)據(jù)源是唯一的：一個(gè)設(shè)備采集的數(shù)據(jù)與另外一個(gè)設(shè)備采集的數(shù)據(jù)是完全獨(dú)立的。一臺(tái)設(shè)備的數(shù)據(jù)一定是這臺(tái)設(shè)備產(chǎn)生的，不可能是人工或其他設(shè)備產(chǎn)生的，也就是說(shuō)一臺(tái)設(shè)備的數(shù)據(jù)只有一個(gè)生產(chǎn)者，時(shí)間序列數(shù)據(jù)的數(shù)據(jù)源是唯一的。
• 相對(duì)互聯(lián)網(wǎng)應(yīng)用，寫(xiě)多讀少：對(duì)于互聯(lián)網(wǎng)應(yīng)用，一條數(shù)據(jù)記錄，往往是一次寫(xiě)，很多次讀。比如一條微博或一篇微信公共號(hào)文章，一次寫(xiě)，但有可能上百萬(wàn)人讀。但時(shí)間序列數(shù)據(jù)不一樣，對(duì)于產(chǎn)生的數(shù)據(jù)，一般是計(jì)算、分析程序自動(dòng)的讀，而且計(jì)算、分析次數(shù)不多，只有分析事故等場(chǎng)景，人才會(huì)主動(dòng)看原始數(shù)據(jù)。
• 用戶(hù)關(guān)注的是一段時(shí)間的趨勢(shì)：對(duì)于一條銀行記錄，或者一條微博、微信，對(duì)于它的用戶(hù)而言，每一條都很重要。但對(duì)于時(shí)間序列數(shù)據(jù)，每個(gè)數(shù)據(jù)點(diǎn)與數(shù)據(jù)點(diǎn)的變化并不大，一般是漸變的，大家關(guān)心的更多是一段時(shí)間，比如過(guò)去的五分鐘，過(guò)去的一個(gè)小時(shí)數(shù)據(jù)變化的趨勢(shì)，一般對(duì)某一特定時(shí)間點(diǎn)的數(shù)據(jù)值并不關(guān)注。
• 數(shù)據(jù)是有保留期限的：采集的數(shù)據(jù)一般都有基于時(shí)長(zhǎng)的保留策略，比如僅僅保留一天、一周、一個(gè)月、一年甚至更長(zhǎng)時(shí)間，為節(jié)省存儲(chǔ)空間，系統(tǒng)最好能自動(dòng)刪除。
• 數(shù)據(jù)的查詢(xún)分析往往是基于時(shí)間段和某一組設(shè)備的：對(duì)于時(shí)間序列數(shù)據(jù)，做計(jì)算和分析的時(shí)候，一定是指定時(shí)間范圍的，不會(huì)只針對(duì)一個(gè)時(shí)間點(diǎn)或者整個(gè)歷史進(jìn)行。而且往往需要根據(jù)分析的維度，對(duì)設(shè)備的一個(gè)子集采集的數(shù)據(jù)進(jìn)行分析，比如某個(gè)地理區(qū)域的設(shè)備，某個(gè)型號(hào)、某個(gè)批次的設(shè)備，某個(gè)廠(chǎng)商的設(shè)備等。
• 除存儲(chǔ)查詢(xún)外，往往需要實(shí)時(shí)分析計(jì)算操作：對(duì)于大部分互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用，更多的是離線(xiàn)分析，即使有實(shí)時(shí)分析，但實(shí)時(shí)分析的要求并不高。比如用戶(hù)畫(huà)像、可以積累一定的用戶(hù)行為數(shù)據(jù)后進(jìn)行，早一天晚一天畫(huà)不會(huì)怎么影響結(jié)果。但是對(duì)于物聯(lián)網(wǎng)應(yīng)用，對(duì)時(shí)間序列數(shù)據(jù)的實(shí)時(shí)計(jì)算要求往往很高，因?yàn)樾枰鶕?jù)計(jì)算結(jié)果進(jìn)行實(shí)時(shí)報(bào)警，以避免事故的發(fā)生。
• 流量平穩(wěn)、可預(yù)測(cè)：給定物聯(lián)網(wǎng)數(shù)量、數(shù)據(jù)采集頻次，就可以較為準(zhǔn)確地估算出所需要的帶寬和流量，每天新生成的數(shù)據(jù)大小。而不是像電商，在“雙 11”期間，淘寶、天貓、京東等流量是幾十倍的漲幅。不像 12306 網(wǎng)站，春節(jié)期間，網(wǎng)站流量是幾十倍的增長(zhǎng)。
• 數(shù)據(jù)處理的特殊性：與典型的互聯(lián)網(wǎng)相比，還有不一樣的數(shù)據(jù)處理需求。比如要檢查某個(gè)具體時(shí)間的設(shè)備采集的某個(gè)量，但傳感器實(shí)際采集的時(shí)間不是這個(gè)時(shí)間點(diǎn)，這時(shí)候往往需要做插值處理。還有很多場(chǎng)景，需要基于采集量，做復(fù)雜的數(shù)學(xué)函數(shù)計(jì)算。
• 數(shù)據(jù)量巨大：以智能電表為例，一臺(tái)智能電表每隔 15 分鐘采集一次數(shù)據(jù)，每天自動(dòng)生成 96 條記錄，全國(guó)就有接近 5 億臺(tái)智能電表，每天光智能電表就生成近 500 億條記錄。一臺(tái)聯(lián)網(wǎng)的汽車(chē)每隔 10 到 15 秒就采集一次數(shù)據(jù)發(fā)到云端，一臺(tái)車(chē)一天就很容易產(chǎn)生 1000 條記錄。如果中國(guó) 2 億輛車(chē)全部聯(lián)網(wǎng)，每天將產(chǎn)生 2000 億條記錄。五年之內(nèi)，物聯(lián)網(wǎng)設(shè)備產(chǎn)生的數(shù)據(jù)將占世界數(shù)據(jù)總量的 90% 以上。

物聯(lián)網(wǎng)、工業(yè)互聯(lián)網(wǎng)的數(shù)據(jù)是流式數(shù)據(jù)，像視頻流，而且單個(gè)數(shù)據(jù)點(diǎn)的價(jià)值很低，甚至丟失一小段時(shí)間的數(shù)據(jù)也不影響分析的結(jié)論，也不影響系統(tǒng)的正常運(yùn)行。但看似簡(jiǎn)單的事情，由于數(shù)據(jù)記錄條數(shù)巨大，導(dǎo)致數(shù)據(jù)的實(shí)時(shí)寫(xiě)入成為瓶頸，查詢(xún)分析極為 緩慢，成為新的技術(shù)挑戰(zhàn)。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)、NoSQL 數(shù)據(jù)庫(kù)以及流式計(jì)算引擎由于沒(méi)有充分利用時(shí)間序列數(shù)據(jù)的特點(diǎn)，性能提升極為有限，只能依靠集群技術(shù)，投入更多的計(jì)算資源和存儲(chǔ)資源來(lái)處理，系統(tǒng)的運(yùn)營(yíng)維護(hù)成本急劇上升。

面對(duì)這一高速增長(zhǎng)的物聯(lián)網(wǎng)數(shù)據(jù)市場(chǎng)，近幾年出現(xiàn)一批專(zhuān)注時(shí)間序列數(shù)據(jù)處理的公司，比如美國(guó)的InfluxData，其產(chǎn)品InfluxDB在IT運(yùn)維監(jiān)測(cè)方面有相當(dāng)?shù)氖袌?chǎng)占有率。在工業(yè)控制領(lǐng)域老牌實(shí)時(shí)數(shù)據(jù)庫(kù)公司OSIsoft在2017年5月獲得軟銀12億美元的投資，期望成為新興的物聯(lián)網(wǎng)領(lǐng)域的數(shù)據(jù)庫(kù)的領(lǐng)頭羊。開(kāi)源社區(qū)也十分活躍，比如基于HBase開(kāi)發(fā)的OpenTSDB。中國(guó)國(guó)內(nèi)，阿里、百度、華為都有基于OpenTSDB的產(chǎn)品。

TDengine 是一款高性能、分布式、支持 SQL 的時(shí)序數(shù)據(jù)庫(kù)（Time Series Database，TSDB），其時(shí)序數(shù)據(jù)庫(kù)核心代碼包括集群功能全部開(kāi)源，同時(shí) TDengine 還帶有內(nèi)建的緩存、流式計(jì)算、數(shù)據(jù)訂閱等系統(tǒng)功能，能大幅減少研發(fā)和運(yùn)維的復(fù)雜度，可廣泛應(yīng)用于物聯(lián)網(wǎng)、車(chē)聯(lián)網(wǎng)、工業(yè)互聯(lián)網(wǎng)、IT 運(yùn)維、金融等領(lǐng)域。