TSBS 測試表明，對于少于 100 萬臺設(shè)備的數(shù)據(jù)集，InfluxDB OSS 3.0 的數(shù)據(jù)寫入速度實(shí)際上比 InfluxDB OSS 1.8 更慢。

對于 100 萬臺及以上設(shè)備的數(shù)據(jù)集，InfluxDB OSS 3.0 的數(shù)據(jù)寫入性能才開始超過 InfluxDB OSS 1.8。

InfluxDB OSS 3.0 的數(shù)據(jù)寫入接口與 InfluxDB 1.8 并不兼容，用戶無法順利遷移。

早在 2023 年，在 InfluxDB 3.0 推向企業(yè)用戶時，官方曾宣稱其相比舊版本有顯著的性能提升。為了驗(yàn)證這一說法，InfluxData 還發(fā)布了一份基準(zhǔn)測試報告，對比了 InfluxDB 3.0 企業(yè)版與 InfluxDB OSS 1.8，結(jié)果顯示 InfluxDB 3.0 在各方面表現(xiàn)出色。

我們對這個版本非常好奇，但作為非企業(yè)用戶，只能和大多數(shù)人一樣等待了一年半，直到今年 1 月 InfluxDB OSS 3.0 終于公開發(fā)布。雖然目前的版本僅是“public alpha”，但這并不妨礙我們對其性能抱有很高的期待，畢竟 InfluxData 已經(jīng)第二次徹底重構(gòu)產(chǎn)品架構(gòu)。對于那些希望平穩(wěn)升級的用戶來說，這無疑是個不小的沖擊，更何況官方還直接放棄了 Flux 語言。如果 InfluxDB 3.0 無法在性能上帶來真正的突破，那這樣的升級又有何意義？

實(shí)際測試：InfluxDB 3.0 更快嗎？

為了驗(yàn)證 InfluxDB 3.0 是否真的如官方宣傳般帶來巨大性能提升，我們采用 Time Series Benchmark Suite (TSBS) 進(jìn)行對比測試。TSBS 由 InfluxData 最初開發(fā)，目前由 Timescale 維護(hù)，是業(yè)界公認(rèn)的時序數(shù)據(jù)庫基準(zhǔn)測試工具。理論上，InfluxDB 3.0 仍支持 InfluxQL 和傳統(tǒng)的 Line Protocol，因此應(yīng)該能夠直接運(yùn)行針對 1.8 版本的測試套件。然而，在實(shí)際測試過程中，我們遇到了多個兼容性問題，不得不尋找替代方案，這部分將在后續(xù)介紹測試方法的章節(jié)中詳細(xì)說明。

我們之所以選擇 TSBS 作為測試工具，不僅因?yàn)樗?QuestDB 之前發(fā)布的簡單基準(zhǔn)測試更全面，還因?yàn)樗峁┝艘粋€公開透明的測試框架，讓不同數(shù)據(jù)庫的對比變得更加公平。然而，測試結(jié)果卻讓我們大跌眼鏡。

TSBS 提供了兩個測試場景：DevOps 監(jiān)控（CPU 監(jiān)測）和物聯(lián)網(wǎng)（IoT，車輛跟蹤）。在測試中，我們使用 TSBS 生成數(shù)據(jù)，并分別寫入 InfluxDB 3 0.1.0（修訂版 v2.5.0-14345）、InfluxDB OSS 1.8 和 TDengine OSS 3.3.5.8。以下圖表展示了各系統(tǒng)在不同測試場景下的寫入性能（指標(biāo)數(shù)/秒）。

TSBS DevOps 用例：

TSBS IoT 用例：

測試結(jié)果分析：InfluxDB 3.0 寫入提升遠(yuǎn)不及 45 倍

在最大規(guī)模的數(shù)據(jù)集中，InfluxDB 3.0 在 DevOps 場景下的寫入性能提升了 5.4 倍，在物聯(lián)網(wǎng)（IoT）場景下提升了 4.9 倍。這與 InfluxData 基準(zhǔn)測試報告中聲稱的“寫入吞吐量提升 45 倍”相去甚遠(yuǎn)。更令人意外的是，在設(shè)備數(shù)量不超過 10 萬的場景下，InfluxDB 1.8 的寫入性能竟然優(yōu)于 InfluxDB 3.0。這表明，InfluxDB 3.0 所謂的性能提升，要么僅適用于企業(yè)版，要么在獨(dú)立測試中并不成立。

InfluxData 網(wǎng)站上的聲明：https://www.influxdata.com/blog/influxdb-3-0-is-2.5x-45x-faster-compared-to-influxdb-open-source/

從測試結(jié)果我們也可以看到，TDengine 的寫入速度比 InfluxDB 3.0 快 4.4 至 11.3 倍，相較 InfluxDB 1.8 更是提升了 3.1 至 22.8 倍。這進(jìn)一步證明，即便 InfluxDB 3.0 進(jìn)行了徹底重構(gòu)，其寫入性能仍難以與 TDengine 相媲美。

TSBS 適配已完成，歡迎查看源碼自行測試

本次測試在一臺 40 核、256GB 內(nèi)存的服務(wù)器上進(jìn)行。該服務(wù)器的配置略低于 InfluxDB 官方基準(zhǔn)測試環(huán)境，高于 QuestDB 的測試環(huán)境，但硬件差異對整體性能趨勢的影響可忽略不計。

由于 TSBS 尚未針對 InfluxDB 3.0 進(jìn)行更新，我們不得不對其進(jìn)行一定的修改。為確保公平性，我們盡量減少了改動，但仍需解決以下問題：

• 數(shù)據(jù)庫管理指令不兼容 TSBS 運(yùn)行 InfluxDB 1.8 時使用的 SHOW、CREATE、DELETE 數(shù)據(jù)庫命令在 InfluxDB 3.0 中已不可用。因此，我們改用 InfluxDB v3 API：
  • GET /api/v3/configure/database 查詢數(shù)據(jù)庫
  • POST /api/v3/configure/database 創(chuàng)建數(shù)據(jù)庫
  • DELETE /api/v3/configure/database 刪除數(shù)據(jù)庫
• 多線程寫入失敗 在使用多個并發(fā)寫入進(jìn)程時，InfluxDB 3.0 頻繁出現(xiàn)寫入失敗，并報錯 Invalid write response (status 409): catalog update error: table already exists。為解決此問題，我們修改了 TSBS，使其在遇到該錯誤時自動重試，而不是直接退出。此外，數(shù)據(jù)寫入采用 InfluxDB 3.0 提供的 /api/v3/write_lp 接口。

現(xiàn)在所有修改均已提交到我們維護(hù)的 TSBS 分支，任何人都可以查看源碼并自行運(yùn)行測試。

結(jié)語

盡管 InfluxDB 3.0 經(jīng)過全面重構(gòu)，并宣傳性能顯著提升，但從寫入性能來看，至少對開源用戶而言，這一承諾并未兌現(xiàn)。測試結(jié)果表明，其寫入性能僅在超大規(guī)模數(shù)據(jù)集下略優(yōu)于 InfluxDB 1.8，而對于大多數(shù)用戶，尤其是設(shè)備數(shù)少于 100 萬場景下，性能反而有所下降。即便目前仍處于 Public Alpha 階段，但該版本已開發(fā)一年多的時間，它的表現(xiàn)真的值得開源社區(qū)期待嗎？

此外，InfluxDB 3.0 采用了全新架構(gòu)，導(dǎo)致用戶無法順利從 1.8 版本升級。對于開源用戶而言，這次升級是否值得，也確實(shí)需要慎重考慮。尤其是當(dāng)數(shù)據(jù)寫入性能成為瓶頸時，從目前的測試結(jié)果來看，InfluxDB 3.0 并未能提供令人信服的解決方案。相比之下，TDengine 始終堅持對開源社區(qū)的承諾，不僅提供高性能、全功能的軟件，還確保所有用戶都能公平獲取和使用。面對時序數(shù)據(jù)存儲與處理的挑戰(zhàn)，選擇一款真正高效、穩(wěn)定的數(shù)據(jù)庫，才是更明智的決定。

如果你已經(jīng)使用過 InfluxDB，可能就不需要想象這些情景了，因?yàn)檫@實(shí)際上已經(jīng)發(fā)生在 InfluxDB 的用戶身上，而且不止一次。

InfluxDB的“三重語言”困境

InfluxDB 最初于 2013 年發(fā)布時，使用了 InfluxQL 作為查詢語言。InfluxQL 是一種類似 SQL 的語言，專門為時序數(shù)據(jù)設(shè)計。盡管其語法與 SQL 相似，但靈活性較差，數(shù)據(jù)聚合和轉(zhuǎn)換的便捷性也較小。

然而，隨著 2020 年 InfluxDB 2.0 的發(fā)布，F(xiàn)lux 語言被引入。Flux 比 InfluxQL 更強(qiáng)大，但也更為復(fù)雜。用戶表示，他們需要參加“InfluxDB 大學(xué)”課程才能理解這門語言，而且通常要參與三個以上的 Flux 項(xiàng)目才能真正熟悉并運(yùn)用這門語言。InfluxDB 當(dāng)時信心十足地認(rèn)為 Flux 會是未來的方向，許多忠實(shí)用戶也紛紛投入時間，翻譯查詢并重寫應(yīng)用程序，以支持 Flux 語言。

但誰能想到，僅僅四年后，InfluxDB 3.0 發(fā)布時，F(xiàn)lux 卻被棄用，取而代之的是 SQL。那些花費(fèi)時間學(xué)習(xí) Flux 并更新項(xiàng)目的用戶，發(fā)現(xiàn)自己無法將項(xiàng)目升級到 InfluxDB 3.0，并且意識到他們在 Flux 上投入的時間和精力付之東流。

雖然 TDengine 和 InfluxDB一樣認(rèn)為 SQL 是時序數(shù)據(jù)庫的最佳語言選擇，但我們更希望他們能在浪費(fèi)廣大用戶的時間之前，就得出這個結(jié)論。

Flux與SQL查詢對比

以下是 InfluxDB 的 Flux 查詢與 TDengine 的 SQL 查詢對比，直觀展示了兩者的簡潔性和可讀性，給到大家參考。

Flux查詢：

from(bucket:"power")
  |> range(start:-1h)
  |> filter(fn:(r) =>
  r.measurement == "smeter" and
   r.field == "voltage" and
   r.location == "chicago"
   )
   |> aggregateWindow(every: 1m, fn: mean)

TDengine SQL 查詢：

SELECT AVG(voltage) FROM power.smeter WHERE ts > now - 1h AND location = "chicago" INTERVAL(1m);

從這兩段查詢的對比中，我們可以明顯看出 TDengine 的 SQL查詢更簡潔、易讀。

TDengine 對 SQL 的承諾

在經(jīng)歷了五十年的發(fā)展后，SQL 已被證明是最穩(wěn)固的查詢語言。自其誕生以來，就迅速成為了頂級數(shù)據(jù)庫管理系統(tǒng)的查詢語言，并且成為了數(shù)據(jù)庫管理員和用戶的重要工具。如今，可以毫不夸張地說，幾乎所有與數(shù)據(jù)相關(guān)的人——從剛剛畢業(yè)、尋求第一份工作的數(shù)據(jù)科學(xué)專業(yè)畢業(yè)生，到在行業(yè)中耕耘數(shù)十年的資深專家——都具備一定的 SQL 使用經(jīng)驗(yàn)。

而 TDengine 自發(fā)布之初就一直支持標(biāo)準(zhǔn) SQL，并承諾將繼續(xù)堅定地支持這一語言。未來，我們將繼續(xù)擴(kuò)展 SQL 的實(shí)現(xiàn)，而不會用任何其他查詢語言來替代它。

在支持標(biāo)準(zhǔn) SQL 的同時，TDengine 還在 SQL 語言上進(jìn)行了針對時序數(shù)據(jù)處理特點(diǎn)的功能擴(kuò)展，比如數(shù)據(jù)匯總、插值和時間加權(quán)平均等功能，這使得用戶不僅能享受 SQL 的靈活性，也能應(yīng)用到類似 InfluxQL 的專用功能。事實(shí)上，TDengine 中的幾乎所有功能——如流處理、數(shù)據(jù)訂閱、權(quán)限管理、集群管理等——都可以通過 SQL 語句來實(shí)現(xiàn)。

TDengine 對 SQL 的支持大大減少了新用戶學(xué)習(xí)曲線的難度，任何曾經(jīng)使用過其他 SQL 數(shù)據(jù)庫的用戶，都能輕松上手 TDengine。我們相信，SQL 是時序數(shù)據(jù)管理的最佳選擇，我們也非常重視開發(fā)者的時間，絕不希望他們?yōu)榱耸褂梦覀兊漠a(chǎn)品而學(xué)習(xí)一門專門的語言。

此外，我們深知，穩(wěn)定和長期的解決方案對任何工業(yè)數(shù)據(jù)基礎(chǔ)設(shè)施都至關(guān)重要。客戶希望能擁有一致的產(chǎn)品體驗(yàn)，而不是每隔幾年就發(fā)生一次重大轉(zhuǎn)型。許多用戶發(fā)現(xiàn)，將現(xiàn)有的 InfluxDB 項(xiàng)目升級到 3.0 的工作量，幾乎和遷移到另一個時序數(shù)據(jù)庫產(chǎn)品相當(dāng)。因此，我們誠邀這些用戶嘗試 TDengine 的開源版本（OSS）或 TDengine Cloud，親自體驗(yàn)這一數(shù)據(jù)庫產(chǎn)品如何輕松上手并快速部署。

實(shí)際上，InfluxDB 僅提供基礎(chǔ)的連續(xù)查詢功能，嚴(yán)格意義上來說并不算真正的“流式計算”，僅適用于某些場景，無法滿足復(fù)雜實(shí)時數(shù)據(jù)流的處理需求。而 TDengine 則具備真正的流式計算能力，可以無縫集成與處理來自各種數(shù)據(jù)源的實(shí)時數(shù)據(jù)流，避免了依賴 Spark 或 Flink 等外部框架進(jìn)行復(fù)雜的流數(shù)據(jù)處理。這樣不僅簡化了架構(gòu)設(shè)計，還顯著降低了運(yùn)維成本。

流式計算功能對比

InfluxDB 不具備真正的流式計算功能

InfluxDB 只提供簡單的連續(xù)查詢（Continuous Query）功能，支持簡單的滑動窗口計算?；瑒哟翱谑且环N基于固定時間間隔的計算方式，計算結(jié)果會隨著時間推移動態(tài)更新。例如，可以對每一分鐘的數(shù)據(jù)進(jìn)行聚合分析。然而，InfluxDB 的流式計算功能相對簡單，基本上只能處理滑動窗口和基礎(chǔ)的聚合任務(wù)，難以滿足更加復(fù)雜的應(yīng)用場景。

使用 InfluxDB 的用戶，往往還需要依賴 Spark、Flink 等外部流處理框架來補(bǔ)充流式計算的功能，以實(shí)現(xiàn)更復(fù)雜的數(shù)據(jù)處理和實(shí)時分析。這種做法不僅增加了架構(gòu)的復(fù)雜性，還需要額外的運(yùn)維成本來管理和維護(hù)多個系統(tǒng)的協(xié)調(diào)工作。此外，數(shù)據(jù)在不同平臺之間的傳輸和同步也可能帶來延遲和性能瓶頸，尤其是在高并發(fā)、高頻次的數(shù)據(jù)寫入和查詢場景下。

TDengine 的流式計算

TDengine 則在流式計算方面提供了更加豐富和靈活的功能。除了支持基礎(chǔ)的滑動窗口外，TDengine 還提供了多種窗口類型，包括狀態(tài)窗口、會話窗口、計數(shù)窗口、事件窗口等。這些窗口類型允許用戶根據(jù)不同需求切分?jǐn)?shù)據(jù)并進(jìn)行聚合分析。

事件驅(qū)動的流式計算

TDengine 支持事件驅(qū)動的流式計算，這使得用戶可以根據(jù)業(yè)務(wù)事件的發(fā)生來觸發(fā)計算，而不僅僅是依賴固定的時間間隔。這一特性在處理與實(shí)際業(yè)務(wù)事件緊密相關(guān)的數(shù)據(jù)時尤為重要，可以大幅降低計算延遲并提高系統(tǒng)的響應(yīng)速度。

豐富的窗口類型

TDengine 在窗口類型的設(shè)計上具有顯著優(yōu)勢，能夠滿足更復(fù)雜的時序數(shù)據(jù)分析需求。以下是 TDengine 支持的幾種窗口類型：

• 時間窗口

時間窗口是最常用的窗口類型，能夠按時間間隔對數(shù)據(jù)進(jìn)行切分，適用于大多數(shù)時序數(shù)據(jù)分析場景。在 TDengine 中，時間窗口不僅支持滑動時間窗口，還支持翻轉(zhuǎn)時間窗口，進(jìn)一步增強(qiáng)了靈活性。

• 滑動時間窗口：隨著時間的推移，計算窗口會動態(tài)向前滑動，允許對最新的數(shù)據(jù)進(jìn)行連續(xù)聚合計算。
• 翻轉(zhuǎn)時間窗口：不同于滑動窗口，翻轉(zhuǎn)窗口不會產(chǎn)生重疊，每次計算一個獨(dú)立的時間段，適用于不需要重疊數(shù)據(jù)的場景。

• 狀態(tài)窗口

狀態(tài)窗口通過根據(jù)數(shù)據(jù)的狀態(tài)變化進(jìn)行聚合計算，適用于需要捕捉不同狀態(tài)之間變化的數(shù)據(jù)處理。例如，在監(jiān)控系統(tǒng)中，可以利用狀態(tài)窗口來計算某一設(shè)備從正常狀態(tài)到故障狀態(tài)的持續(xù)時間。

• 會話窗口

會話窗口根據(jù)數(shù)據(jù)之間的“會話”進(jìn)行分組，適合用來分析需要根據(jù)某些事件或者行為聚集的數(shù)據(jù)。例如，在用戶行為分析中，你可以通過會話窗口計算每個用戶的一次完整活動周期。

• 計數(shù)窗口

計數(shù)窗口根據(jù)固定的數(shù)據(jù)行數(shù)進(jìn)行劃分。默認(rèn)情況下，數(shù)據(jù)首先按時間戳排序，然后根據(jù) count_val（每個窗口中包含的最大數(shù)據(jù)行數(shù)）的值將數(shù)據(jù)分成多個窗口，并進(jìn)行聚合計算。

• 事件窗口

事件窗口更為特殊，它允許用戶基于特定的事件觸發(fā)來進(jìn)行數(shù)據(jù)聚合分析。通過設(shè)定事件的起始和結(jié)束條件，用戶可以靈活地控制計算窗口的范圍和內(nèi)容。

計算性能和延遲

高吞吐量和低延遲

TDengine 的流式計算引擎具有非常高的吞吐量，能夠在高頻數(shù)據(jù)寫入的同時保持毫秒級的計算延遲。這對于實(shí)時監(jiān)控、預(yù)測性維護(hù)等應(yīng)用場景尤為重要。例如，在智能電表的應(yīng)用中，電表每 10 秒采集一次數(shù)據(jù)，而用戶往往需要每 1 分鐘查詢一次溫度的平均值，TDengine 的流式計算能夠高效完成這類任務(wù)。

輕量級替代方案

與傳統(tǒng)的復(fù)雜流處理系統(tǒng)相比，TDengine 提供了一個輕量級的流式計算解決方案。它通過內(nèi)建的窗口子句和簡單的 SQL 語法，使得用戶無需引入額外的流處理引擎便能夠進(jìn)行實(shí)時數(shù)據(jù)處理，這樣不僅降低了系統(tǒng)復(fù)雜度，還節(jié)省了計算資源。

窗口子句的語法及使用

TDengine 的窗口子句非常靈活，支持通過 SQL 語法輕松實(shí)現(xiàn)各種窗口計算。下面是窗口子句的一些基本語法示例：

SELECT tbname, _wstart, _wend, avg(voltage)
FROM meters
WHERE ts >= "2022-01-01T00:00:00+08:00"
AND ts < "2022-01-01T00:05:00+08:00"
PARTITION BY tbname
INTERVAL(1m, 5s) SLIDING(2s)
SLIMIT 1;

在這個查詢中，數(shù)據(jù)首先按照子表名進(jìn)行切分，然后按 1 分鐘的時間窗口進(jìn)行聚合，窗口每 2 秒滑動一次。TDengine 支持多種窗口類型和聚合函數(shù)，用戶可以根據(jù)需求靈活組合使用。

結(jié)語

與 InfluxDB 相比，TDengine 在流式計算的基礎(chǔ)上，還具備強(qiáng)大的 ETL 能力——它不僅能處理時序數(shù)據(jù)，還能自動進(jìn)行數(shù)據(jù)清洗與轉(zhuǎn)換，幫助用戶實(shí)現(xiàn)更加高效、靈活的數(shù)據(jù)處理。這一優(yōu)勢使得 TDengine 能在更多復(fù)雜的應(yīng)用場景中提供卓越的性能，尤其是對于需要實(shí)時數(shù)據(jù)分析和高效數(shù)據(jù)處理的行業(yè)，提供了更為完善的解決方案。

TDengine 內(nèi)建的流式計算能力使得用戶能夠更加高效地進(jìn)行數(shù)據(jù)實(shí)時分析，減少了多平臺整合、運(yùn)維監(jiān)控等額外開銷，實(shí)現(xiàn)了更優(yōu)的性能和更低的運(yùn)維復(fù)雜度，尤其在大規(guī)模物聯(lián)網(wǎng)、車聯(lián)網(wǎng)等實(shí)時數(shù)據(jù)處理場景中，優(yōu)勢更加明顯。

如果你也想體驗(yàn)一把 TDengine 流計算，可以訪問官方文檔，詳細(xì)了解其配置和使用方法，充分發(fā)揮 TDengine 在實(shí)時數(shù)據(jù)處理中的強(qiáng)大優(yōu)勢。

TDengine 3.0 企業(yè)版和 TDengine Cloud 為用戶提供了便捷的數(shù)據(jù)接入解決方案。通過插件集成框架，支持快速擴(kuò)展各類數(shù)據(jù)源，并且具備接入 InfluxDB 數(shù)據(jù)到 TDengine 的功能。

配置方法

讓我們一起看看如何將數(shù)據(jù)從 InfluxDB 接入至 TDengine。

配置方法很簡單，你只需要登錄到 TDengine 企業(yè)版或 TDengine Cloud 的 Web 管理界面，選擇 Data in 并添加 InfluxDB 作為數(shù)據(jù)源，注意需要提前創(chuàng)建時間精度為納秒（ns）的數(shù)據(jù)庫。

然后簡單配置一下 InfluxDB 服務(wù)所在的 IP 地址和端口，以及 InfluxDB 版本、OrgId、和 token 等參數(shù)。

最后選擇需要導(dǎo)出的 Bucket、 Measurements、導(dǎo)入數(shù)據(jù)的起始時間、結(jié)束時間（可選項(xiàng)）以及讀取時間窗口（可選項(xiàng)），并指定已經(jīng)提前建好的數(shù)據(jù)庫名稱，提交即可。

TDengine 的數(shù)據(jù)接入后還可以進(jìn)行數(shù)據(jù)清洗和轉(zhuǎn)換，用戶可以根據(jù)業(yè)務(wù)需要設(shè)計相應(yīng)的數(shù)據(jù)清洗和轉(zhuǎn)換規(guī)則，實(shí)現(xiàn)完整的數(shù)據(jù) ETL 流程。

TDengine 3.0 企業(yè)版和 TDengine Cloud 憑借簡潔易用的命令行操作，為用戶提供了高效、可靠的數(shù)據(jù)接入方法。無論你是想要從 InfluxDB 遷移數(shù)據(jù)，還是想將多個數(shù)據(jù)源的數(shù)據(jù)集中到時序數(shù)據(jù)庫（Time Series Database） TDengine 中，TDengine 3.0 企業(yè)版和 TDengine Cloud 都能夠滿足你的需求。

現(xiàn)在注冊?TDengine Cloud?就可以立即體驗(yàn)強(qiáng)大的數(shù)據(jù)接入功能，感受輕松便捷的接入體驗(yàn)，獲得更深入的數(shù)據(jù)洞察力。還在等什么~趕快與我們聯(lián)系，了解關(guān)于 TDengine 企業(yè)版和 TDengine Cloud 的更多信息，開啟前所未有的數(shù)據(jù)之旅！

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

以下的性能基準(zhǔn)報告均使用了 TSBS 作為基礎(chǔ) Benchmark 平臺，我們從時間跨度和發(fā)布廠商的知名度同時來看，就能發(fā)現(xiàn)，基礎(chǔ)測試平臺 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)行性能對比。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

基于對 TDengine 的定義和理解，筆者將會在本篇文章中從 TDengine 能解決什么問題、它的優(yōu)勢與亮點(diǎn)、它與其它數(shù)據(jù)庫的區(qū)別等維度展開詳述，希望能幫助到對 TDengine 感興趣的小伙伴。

“區(qū)別于通用數(shù)據(jù)庫，TDengine 拋掉無用包袱”

數(shù)據(jù)庫想要完成出色的的讀寫，最核心的能力就是索引，一般數(shù)據(jù)庫產(chǎn)品都具備正向索引能力。所謂正向索引就是通過文檔記錄里面的標(biāo)識符為關(guān)鍵字，通過關(guān)鍵標(biāo)識符不再需要進(jìn)行全盤掃描。雖然 B樹索引、哈希索引、位圖索引有區(qū)別，但是大方向都屬于正向索引。

除了正向索引，還有反向索引【也稱倒排索引】，反向索引主要用于全文檢索，例如 ElasticSearch，大多數(shù)據(jù)庫都是正向索引。TDengine 也是使用正向索引，它的特別之處是標(biāo)識符肯定包含時間戳，再加上一個維度指標(biāo)數(shù)據(jù)，構(gòu)成一個對數(shù)據(jù)值明確的描述——某個時間某個指標(biāo)對象的數(shù)據(jù)值是多少。

從數(shù)據(jù)組織的存儲引擎來看，數(shù)據(jù)庫底層可以分為 B樹機(jī)制、LSM 機(jī)制，兩種機(jī)制沒有最好，各有各的優(yōu)點(diǎn)和缺點(diǎn)：

B樹最大好處在于它對數(shù)據(jù)持續(xù)高漲讀性能的處理，即使數(shù)據(jù)量級增大，它的讀也沒有放大。奧秘在于對數(shù)據(jù)進(jìn)行終極持久存儲時，B樹是以有序有規(guī)律的數(shù)據(jù)結(jié)構(gòu)保存在硬盤上的。這樣隨著數(shù)據(jù)越來越大，它依然保持有序有規(guī)律的特性，面對成千上萬的讀操作，都可以遵循條件運(yùn)行，減少或避免讀放大的行為。

與 B樹機(jī)制截然相反，LSM 機(jī)制則是減少避免了寫放大。LSM 機(jī)制充分利用了內(nèi)存，在內(nèi)存里面開辟了一個空間，寫數(shù)據(jù)優(yōu)先往內(nèi)存里放，寫進(jìn)去直接返回用戶成功，而不是像 B樹那樣寫一個，我要找出誰比我大誰比我小，只要內(nèi)存有夠，就直接往內(nèi)存里面填就好，當(dāng)內(nèi)存達(dá)到一定的閾值，將內(nèi)存中的數(shù)據(jù)以批量、順序的方式一次寫入硬盤上，內(nèi)存則重置清零再服務(wù)新的寫要求。

傳統(tǒng)數(shù)據(jù)庫 MySQL、Oracle 使用的是 B樹機(jī)制，而 TiDB、OceanBase 使用的是優(yōu)化后的 LSM 機(jī)制，而 TDengine 使用的是 B樹 + LSM 機(jī)制的方式，其中 B樹存儲的是元數(shù)據(jù)【主要是時間戳+指標(biāo)數(shù)據(jù)】，LSM 機(jī)制存儲的是具體的數(shù)據(jù)，元數(shù)據(jù)以有序表結(jié)構(gòu)方式進(jìn)行存儲，而具體數(shù)據(jù)則是以追加的方式寫入，這樣即避免了讀話大和寫放大。

一般來說，OLTP 產(chǎn)品為了提升并發(fā)控制的性能，必定會有寫時復(fù)制或者 MVCC 的功能選項(xiàng)，寫時復(fù)制與 MVCC 雖然保障了數(shù)據(jù)的一致性，但是帶來更多的 IO 負(fù)擔(dān)。TDengine 不需要對數(shù)據(jù)進(jìn)行修改，所以不需要考慮數(shù)據(jù)一致性的問題，數(shù)據(jù)是以有序的規(guī)律并追加的形式寫進(jìn)去的，因?yàn)橹挥凶x和寫，所以也不需要鎖保護(hù)，拋掉一些無用的包袱，可以集中優(yōu)化其它地方，例如列式表。

業(yè)界通用數(shù)據(jù)庫針對各種業(yè)務(wù)都會有行式表、列式表甚至完全的內(nèi)存庫，對于具體的數(shù)據(jù)存儲 TDengine 使用完全列式存儲在硬盤，而維度指標(biāo)則行式保存在內(nèi)存中。因?yàn)?TDengine 面對的是機(jī)器的數(shù)據(jù)，機(jī)器 24 小時工作精確到每個毫秒都在產(chǎn)生數(shù)據(jù)，為了存儲更多的數(shù)據(jù)，所以 TDengine 用上行列并存、用途分離的方式。

一般來說，數(shù)據(jù)庫里面每一行的文檔記錄都是非常重要的，即使這行記錄信息無關(guān)交易，只是一個用戶的基本信息，那它的價值密度也十分高。但時序數(shù)據(jù)庫（Time Series Database）不同，單行文檔記錄價值密度低，因?yàn)?1 秒可以產(chǎn)生 1 萬條記錄，必須要把數(shù)據(jù)聚合匯總起來才能體現(xiàn)數(shù)據(jù)的價值。快速并有效聚合普通數(shù)據(jù)使之變成價值密度高的數(shù)據(jù)，這個也是時序數(shù)據(jù)庫區(qū)別于其它數(shù)據(jù)庫的一個重要的特征。

TDengine目前提供了三個版本的產(chǎn)品：社區(qū)版，企業(yè)版以及云版本， 以滿足市場的需求和個人開發(fā)者的需求。

“拆解時序數(shù)據(jù)庫，幾大產(chǎn)品特點(diǎn)分析”

從技術(shù)上區(qū)分定位，TDengine 是專注時間序列領(lǐng)域的一個分布式的海量數(shù)據(jù)分析平臺。它的競爭對手可以分為直接競爭對手和間接競爭對手，間接競爭對手有國內(nèi)的 TiDB、OceanBase、GaussDB 以及國外的 Oracle、MySQL 等等，雖然它們在綜合技術(shù)維度上與 TDengine 沒有對標(biāo)，但是分析上只要是使用時間戳，與時間序列有關(guān)系，這里就有 TDengine 的用武之地。與 TDengine 構(gòu)成直接競爭的對手有 Druid、OpenTSDB、InfluxDB集群版，他們都是時間序列分析的前輩。

Druid 是一個分布式系統(tǒng)，采用 Lambda 架構(gòu)，有利于充分利用內(nèi)存，也會把歷史數(shù)據(jù)保存到硬盤上，按一定的時間粒度對數(shù)據(jù)進(jìn)行聚合，實(shí)時處理和批處理數(shù)據(jù)解耦分開。實(shí)時處理面向?qū)懚嘧x少的場景，主要是以流方式處理增量數(shù)據(jù)，批處理面向讀多寫少的場景，主要是以此方式處理離線數(shù)據(jù)。Druid 依賴 Hadoop，集群中采用 share nothing 的架構(gòu)，各個節(jié)點(diǎn)都有自己的計算和存儲能力，整個系統(tǒng)通過 Zookeeper 進(jìn)行協(xié)調(diào)。為了提高計算性能，其會采用近似計算方法包括 HyperLoglog、DataSketches 的一些基數(shù)計算。

OpenTSDB 是一個開源的時序數(shù)據(jù)庫，支持存儲數(shù)千億的數(shù)據(jù)點(diǎn)，并提供精確的查詢，采用 Java 語言編寫，通過基于 HBase 的存儲實(shí)現(xiàn)橫向擴(kuò)展，OpenTSDB 廣泛用于服務(wù)器的監(jiān)控和度量，包括網(wǎng)絡(luò)和服務(wù)器、傳感器、IoT、金融數(shù)據(jù)的實(shí)時監(jiān)控領(lǐng)域。OpenTSDB 在設(shè)計思路上是利用 HBase 的 key 去存儲一些 tag 信息，將同一個小時數(shù)據(jù)放在一行存儲，以此提高查詢速度。OpenTSDB 通過預(yù)先定義好維度 tag 等，采用精巧的數(shù)據(jù)組織形式放在 HBase 里面，通過 HBase 的 keyRange 可以進(jìn)行快速查詢，但是在任意維度的組織查詢下，OpenTSDB的效率會降低。

InfluxDB 是一款非常流行的時序數(shù)據(jù)庫，采用 Go 語言開發(fā)，社區(qū)非常活躍，技術(shù)特點(diǎn)支持任意數(shù)量的列，去模式化，集成了數(shù)據(jù)采集、存儲和可視化存儲，使用高壓縮比的算法支持高效存儲，采用 TIME SERIES MERGE TREE 的內(nèi)部存儲引擎，支持與 SQL 類似的語言（2.0 版本不再支持）。

時間序列的業(yè)務(wù)背景，在 OLAP 場景中一般會進(jìn)行預(yù)聚合來減少數(shù)據(jù)量，影響預(yù)聚合主要因素可以匯總?cè)缦拢?/p>

• 維度指標(biāo)的個數(shù)
• 維度指標(biāo)的基數(shù)
• 維度指標(biāo)組合程度
• 時間維度指標(biāo)的粗粒度和細(xì)粒度

為了實(shí)現(xiàn)高效的預(yù)聚合，TDengine 的秘訣是超級表，Druid 會提前定義預(yù)計算，InfluxDB 也有自己的連續(xù)查詢方法，只有 HBase 使用時才進(jìn)行拼接，所以涉及不同的維度指標(biāo)查詢，HBase 會慢一些。

據(jù)了解，TDengine 基于 TSBS 的測試報告將于近日出爐，第一期報告針對 InfluxDB 和 TimeScaleDB 進(jìn)行了詳細(xì)的性能層面的對比分析，感興趣的小伙伴最近可以多多關(guān)注下公眾號的內(nèi)容。

“放到今天，TDengine 一定是首選”

我對 TDengine 的認(rèn)識和了解要從過去的項(xiàng)目經(jīng)驗(yàn)說起，以 2018 年為背景，我給大家講述一個工業(yè)界壞件故障件預(yù)測的故事。

某知名集團(tuán)隨著公司業(yè)務(wù)的快速增長、新工廠的不斷增加，各種有價值的數(shù)據(jù)不能很好的整合、分析與挖掘出它應(yīng)有的價值。此時公司發(fā)展已經(jīng)進(jìn)入下一輪“拼”的戰(zhàn)略，快速響應(yīng)與準(zhǔn)確預(yù)測是業(yè)務(wù)發(fā)展的關(guān)鍵，大數(shù)據(jù)在其中起到舉足輕重的作用，以科學(xué)的分析手法整合各系統(tǒng)數(shù)據(jù)、推動工廠制造智能化發(fā)展，成為一件迫在眉睫的工作。

當(dāng)前工廠生產(chǎn)過程中出現(xiàn)了同一種特殊問題的 glass id，glass 的品質(zhì)由于各種原因是參差不齊的，甚至?xí)衅焚|(zhì)異常的 glass。這些異常 glass 在檢測過程中，是無法檢測出異常原因的，如果無法快速定位出異常原因，就會造成更多的異常 glass，嚴(yán)重影響生產(chǎn)。應(yīng)對的具體手段包括：

1. 通過品質(zhì)異常的 glass，找到產(chǎn)生此異常的相關(guān)性因子。如：機(jī)臺、物料、載具、參數(shù)等。
2. 異常 glass 偵測預(yù)警，通過對產(chǎn)生品質(zhì)異常的因子進(jìn)行數(shù)學(xué)建模，預(yù)測出偏離正常范圍的異常玻璃，提前預(yù)警。
3. 分析 glass 的特征值與特征值之間的關(guān)聯(lián)關(guān)系，并建立預(yù)測模型，提前預(yù)測出 glass 的特征值。
4. 分析 glass 相關(guān)的電壓、電阻、電流、溫度、濕度影響。

很明顯這是數(shù)據(jù)挖掘的項(xiàng)目，要分析以上 glass 在生產(chǎn)過程中的環(huán)境信息、檢測機(jī)臺資料、量測機(jī)臺資料、制程參數(shù)信息，以及 FDC、OEE 系統(tǒng)的數(shù)據(jù)，才能找出產(chǎn)生這種問題的原因。第一步是數(shù)據(jù)收集整合，第二步是數(shù)據(jù)探索，第三步是模型調(diào)校——找出可能性、影響最大的因素的特征因素，第四步是投入生產(chǎn)驗(yàn)證，通過 spark ml 提供預(yù)測動力。

當(dāng)時的技術(shù)棧用的是 CDH，首先要通過 Kafka 采集數(shù)據(jù)，Spark對接 Kafka 進(jìn)行初步計算去噪并匯總到 Hadoop 里面，以 parquet 的格式保存，如果需要進(jìn)一步的加工，就通過 impala 進(jìn)行。這樣每天掛起 N 個任務(wù)，不停的調(diào)度計算。

CDH Hadoop 雖然無法做到實(shí)時數(shù)據(jù)分析，但是也還能做些事，聊勝于無，就繼續(xù)用著。當(dāng)時這個壞件故障件預(yù)測項(xiàng)目有以下痛點(diǎn)，主要是及時性、有效性、準(zhǔn)確性的問題：

• 難以滿足用戶需求，某些機(jī)器數(shù)據(jù)的聚合計算需要第二天才能出結(jié)果，甚至更多的時間才能出來。
• 經(jīng)濟(jì)成本的費(fèi)用較高，CPU、磁盤、網(wǎng)絡(luò)都在一個高段的使用狀態(tài)，針對越來越多的數(shù)據(jù)需要投入新機(jī)器。
• 維護(hù)成本高，你需要維護(hù) Hadoop 所有的機(jī)器，各種 HBase、Spark、Zookeeper、HDFS 之類，不但對工程師要求高，而且工作量巨大。
• 低質(zhì)量數(shù)據(jù)，因?yàn)閿?shù)據(jù)流程或者錯誤的邏輯整合，導(dǎo)致機(jī)器傳感器聚合后數(shù)據(jù)模型無法正常使用。
• 無法做到實(shí)時監(jiān)測，機(jī)器數(shù)據(jù)作為寶貴的自變量因素?zé)o法及時傳輸并進(jìn)行計算，自然會影響因變量。

筆者經(jīng)歷了這個項(xiàng)目，知道這個壞件故障預(yù)測與時間序列有緊密的關(guān)系。時至今日，時間序列分析也是重要的數(shù)據(jù)分析技術(shù)，尤其面對季節(jié)性、周期性變化數(shù)據(jù)時，傳統(tǒng)的回歸擬合技術(shù)難以奏效，這時就需要復(fù)雜的時間序列模型，以時間為特征作為抓手點(diǎn)。這樣即使你不太懂業(yè)務(wù)的前提下，也可以進(jìn)行數(shù)據(jù)挖掘的工作。

那這個項(xiàng)目與 TDengine 有什么關(guān)系呢？實(shí)際上，這個項(xiàng)目并沒有用上 TDengine，后來集團(tuán)搭建了一個 Hadoop集群試點(diǎn)，這次居然用了 HDP，理由很簡單，因?yàn)?HDP 默認(rèn)搭載了時序數(shù)據(jù)庫 Druid。

當(dāng)時技術(shù)負(fù)責(zé)人認(rèn)為壞件故障預(yù)測模型的數(shù)據(jù)庫基座應(yīng)該是時序數(shù)據(jù)庫，而不是 Hadoop 不停的進(jìn)行數(shù)據(jù)采集、數(shù)據(jù)轉(zhuǎn)換以及各種批計算，通過時序數(shù)據(jù)庫不但可以實(shí)時計算，而且輸出的數(shù)據(jù)質(zhì)量高。至于選擇哪個時序數(shù)據(jù)庫，彼時考慮平穩(wěn)過渡替換以及學(xué)習(xí)成本綜合因素后他們選擇了 Druid。

但當(dāng)時是 2017 年，TDengine 也還沒有面世，如果放到今天，TDengine 必定是選型考慮的首選。

要知道，TDengine 的優(yōu)勢相對 Druid 要多了去了，首先 Druid 不是一個經(jīng)過開源版本 1.00 正式發(fā)布的軟件，雖然發(fā)展多年，直至 HDP 與 CDH 兩家公司融合，HDP 搭配的 Druid 也不是 1.00 版；其次 Druid 依賴 Hadoop，動輒就使用大量的資源以及各種復(fù)雜的 Hadoop 組件，最后 Druid 只提供 json 的方式，對傳統(tǒng)的 DBA 使用十分不友好。

TDengine 有一個我認(rèn)為很秀的功能，就是它的超級表的跨指標(biāo)維度建模思想，目前它僅用于自由組合維度指標(biāo)，拼接不同的時間粒度進(jìn)行聚合。在我看來，將來應(yīng)用于時間序列機(jī)器學(xué)習(xí)模型也會是它的一個亮點(diǎn)，在數(shù)據(jù)建模方面，針對工廠的設(shè)施、設(shè)備、機(jī)床、機(jī)房、車間、測臺等必須要做高效準(zhǔn)確的定義。我們進(jìn)行項(xiàng)目規(guī)劃建設(shè)時，都會做大量的數(shù)據(jù)治理工作，但是在具體實(shí)施工作上，還是要使用這些傳統(tǒng)工具和技術(shù)。TDengine 可以有效匯集各種機(jī)器數(shù)據(jù)源，并且能夠高質(zhì)量的提煉，這個是過去的時序數(shù)據(jù)產(chǎn)品所不具備的。

“是提速，更是賦能”

中國有句話叫做“長江后浪推前浪，一代新人勝舊人”，IT 世界千變?nèi)f化，如果你和我一樣，一直在關(guān)注著 TDengine，就會發(fā)現(xiàn)，它這幾年崛起的非常迅速。去年 TDengine 推出 3.0 版本，新版本升級成為了一款真正的云原生時序數(shù)據(jù)庫，優(yōu)化了流計算功能，而且還重新設(shè)計了計算引擎，優(yōu)化工程師對 SQL 的使用，另外增加了 taosX，利用自己的數(shù)據(jù)訂閱功能來解決增量備份、異地容災(zāi)，更加方便了企業(yè)應(yīng)用。

我對 TDengine 未來的期望是，希望它增加庫內(nèi)機(jī)器學(xué)習(xí)函數(shù)，增加 ARIMA 模型、MA 模型等時間相關(guān)功能，TDengine 的未來是一個智能學(xué)習(xí)時間序列數(shù)據(jù)庫，對工業(yè) 4. 0 來說不僅是提速，更是賦能。

中冶京誠工程技術(shù)有限公司（簡稱：中冶京誠）是我國最早從事冶金工程咨詢、設(shè)計、工程承包業(yè)務(wù)的國家級大型科技型企業(yè)，是由冶金工業(yè)部北京鋼鐵設(shè)計研究總院改制成立的國際化工程技術(shù)公司，現(xiàn)隸屬于中國冶金科工集團(tuán)有限公司，是世界五百強(qiáng)中國五礦集團(tuán)有限公司的核心骨干子企業(yè)。

作為國內(nèi)外客戶認(rèn)可的知名品牌企業(yè)，近 70 年來，先后為國內(nèi)外 500 余家客戶提供了近 6500 項(xiàng)工程技術(shù)服務(wù)，參與完成了寶鋼、鞍鋼、武鋼、太鋼、首鋼京唐、河鋼等國內(nèi)鋼鐵企業(yè)的新建和改擴(kuò)建工程，海外工程業(yè)務(wù)拓展 27 個國家，是我國鋼鐵工業(yè)建設(shè)的主要力量和工程技術(shù)輸出的重要參與者。在歷年國家住建部、勘察設(shè)計協(xié)會等年度排名中，均位居行業(yè)前列。

其中中冶京誠高速棒線材智能化團(tuán)隊(duì)?wèi){借 70 多年棒線材軋制工程技術(shù)底蘊(yùn)和經(jīng)驗(yàn)積累，持續(xù)打造技術(shù)領(lǐng)先的基礎(chǔ)自動化系統(tǒng)，結(jié)合機(jī)器視覺、數(shù)據(jù)分析、人工智能等先進(jìn)技術(shù)，打造完善統(tǒng)一的智能化數(shù)據(jù)中心，成功構(gòu)建了新一代高速棒線材車間智能化整體解決方案。中冶京誠計劃將所有生產(chǎn)線數(shù)據(jù)匯總接入到過程數(shù)據(jù)中心，通過數(shù)據(jù)中心打破車間數(shù)據(jù)孤島，實(shí)現(xiàn)生產(chǎn)過程數(shù)據(jù)、工廠設(shè)計數(shù)據(jù)、視頻音頻圖像數(shù)據(jù)、生產(chǎn)管理數(shù)據(jù)等車間數(shù)據(jù)的深度融合。

而過往使用的 InfluxDB集群 實(shí)時數(shù)據(jù)庫在性能上稍顯不足，且不符合國產(chǎn)化獨(dú)立自主的趨勢，中冶京誠希望找到其他替換的國產(chǎn)時序數(shù)據(jù)庫解決方案。與 InfluxDB 相比，國產(chǎn)時序數(shù)據(jù)庫（Time Series Database，TSDB） TDengine 搭建集群的成本更低廉、查詢更具有優(yōu)勢，存儲性能和穩(wěn)定性表現(xiàn)也更加突出。在這些優(yōu)勢的加持下，中冶京誠選擇與 TDengine 展開合作，共同實(shí)現(xiàn)鋼鐵工業(yè)智慧化，并在鋼鐵智能車間多個項(xiàng)目中實(shí)現(xiàn)了車間數(shù)據(jù)的深度融合應(yīng)用。

北京科技大學(xué)設(shè)計研究院有限公司作為北京科技大學(xué)全資產(chǎn)業(yè)化技術(shù)推廣機(jī)構(gòu)，從 2013 年開始在冶金、鋼鐵行業(yè)進(jìn)行業(yè)務(wù)系統(tǒng)開發(fā)和實(shí)施，圍繞先進(jìn)材料、綠色低碳和智能制造不斷深耕細(xì)作，持續(xù)創(chuàng)新。其擁有高效軋制與智能制造國家工程研究中心、國家板帶生產(chǎn)先進(jìn)裝備工程技術(shù)研究中心和北京市交通與能源用特殊鋼工程技術(shù)研究中心三個主要研究機(jī)構(gòu)，多年來一直專注于金屬材料加工領(lǐng)域的自動化、信息化、智能化全產(chǎn)業(yè)鏈解決方案，已經(jīng)建立起完備的控制管理體系、售后服務(wù)體系和維保服務(wù)體系，并已通過質(zhì)量、環(huán)境、職業(yè)健康、信息安全、信息技術(shù)服務(wù)等多項(xiàng)管理體系認(rèn)證，獲得北京市優(yōu)秀技術(shù)轉(zhuǎn)移機(jī)構(gòu)及首屆鋼鐵工業(yè)智能制造優(yōu)秀品牌稱號、入選北京市專精特新中小企業(yè)，“金屬材料軋制過程智能檢測與精準(zhǔn)控制關(guān)鍵技術(shù)應(yīng)用”榮獲中國技術(shù)市場協(xié)會金橋獎項(xiàng)目一等獎。

在企業(yè)數(shù)字化的早期階段，很多企業(yè)在處理工業(yè)生產(chǎn)中大量的典型時序數(shù)據(jù)時，因海外軟件(OpenTSDB、influxdb集群版)有先發(fā)優(yōu)勢，大都選擇了 Wonderware InTouch + InSQL/Historian 的解決方案。但是隨著業(yè)務(wù)的發(fā)展，生產(chǎn)中需要監(jiān)測的指標(biāo)從幾萬個增加到幾十萬甚至百萬個以上，原有方案在擴(kuò)展能力上遇到瓶頸，出現(xiàn)了以下挑戰(zhàn)：

• 非國產(chǎn)化：在復(fù)雜的國際形勢下，存在一些不確定性
• 封閉性：很多軟件是閉源的，而且處于自己的封閉體系之下，擴(kuò)展性差
• 高度復(fù)雜度：需要采購一系列產(chǎn)品組合
• 高成本：采購價格昂貴、功能擴(kuò)展需要額外付費(fèi)，依賴 Windows、SQL Server 等其他軟件，會產(chǎn)生額外的采購成本
• 服務(wù)響應(yīng)慢：國外產(chǎn)品普遍服務(wù)響應(yīng)不及時，反饋經(jīng)常以天為單位，服務(wù)保障性差

面對上述挑戰(zhàn)，國產(chǎn)開源時序數(shù)據(jù)庫(Time Series Database)TDengine 在提升數(shù)據(jù)存取效率、打破傳統(tǒng)數(shù)據(jù)孤島、提升數(shù)據(jù)有效利用率方面為北京科技大學(xué)設(shè)計研究院的冶金數(shù)字化提供了實(shí)質(zhì)性的幫助，協(xié)助打造了智能化統(tǒng)一平臺，方便部署、簡化整體架構(gòu)的同時，憑借高性能、高壓縮率，TDengine 時序數(shù)據(jù)庫(TSDB)還實(shí)現(xiàn)了總體擁有成本的大幅降低、滿足國產(chǎn)化等要求。

未來，TDengine 將與北京科技大學(xué)設(shè)計研究院一起，充分利用雙方技術(shù)優(yōu)勢，賦能冶金行業(yè)發(fā)展，讓冶金行業(yè)的數(shù)據(jù)處理能力得到實(shí)質(zhì)性提升。

此外，在開源大勢所趨的背景下，基礎(chǔ)軟件如果不將代碼、特別是核心代碼開源，想要贏得市場是完全不可能的事情。因此，我們才將 TDengine 完全開源，包括集群功能，而事實(shí)證明，開源使?jié)紨?shù)據(jù)獲得了高速增長，這是一個完全正確的決定。

但從產(chǎn)品角度來看，開源是 TDengine 的一大優(yōu)勢嗎？看起來是，但細(xì)想一下，其實(shí)不是，它只是取得成功的一個必要條件。因?yàn)槿蚴袌錾祥_源的的時序數(shù)據(jù)庫產(chǎn)品很多，中國本土開源的 Time Series Database 也不止 TDengine 一家，大家不會由于 TDengine 是開源的就選擇它，而是有其他特點(diǎn)才會選用它，諸如性能優(yōu)勢、支持 SQL 等。

如果市場上還沒有開源的 Time Series Database，那么開源就是 TDengine 最大的亮點(diǎn)。我們決定將集群開源，根本的原因是由于 InfluxDB集群沒有開源，這給了我們高速增長的機(jī)會。只有別人做不到或比不上你的功能或性能，那才是你需要宣傳的特點(diǎn)。功能或性能指標(biāo)的跟隨者永遠(yuǎn)不值得做任何推廣。

在進(jìn)行客戶調(diào)研時我們發(fā)現(xiàn)，很多企業(yè)在不了解一款產(chǎn)品時，不會輕易下定購買的決心，就說 InfluxDB，作為一款較早流行的 Time Series Database，基本都會被有時序數(shù)據(jù)處理需求的企業(yè)列為調(diào)研對象，但由于 InfluxDB集群功能需要高價購買才能使用，用戶在不了解的情況下難以下定決心。其實(shí)，真正好的產(chǎn)品，是不怕因?yàn)楹诵墓δ芏奸_源就會失去競爭力的，反而有全部開源來讓用戶全面檢測的決心。

事實(shí)上，在早期 InfluxDB集群也是處于開源狀態(tài)的，后面因?yàn)槲粗驔Q定將集群進(jìn)行閉源，而這一決定也確實(shí)在一定程度上降低了 InfluxDB集群的應(yīng)用規(guī)模，流失了一部分集群客戶。而對于國內(nèi)的企業(yè)來說，除了對 InfluxDB集群不開源，無法支持水平擴(kuò)展抱有擔(dān)憂外，InfluxDB 糟糕的本地化服務(wù)也是讓他們望而卻步的原因之一。

相反，TDengine 之所以能夠成為這些客戶堅定的選擇，除了集群開源外，還有其支持 SQL 等特性，而且 TDengine 各項(xiàng)功能的設(shè)計，是真正從 Time Series Database 的特點(diǎn)出發(fā)而設(shè)定的，對于時序大數(shù)據(jù)具有更強(qiáng)的處理性能。

時序數(shù)據(jù)及時序數(shù)據(jù)的應(yīng)用有其典型特點(diǎn)（詳細(xì)請看官網(wǎng)博客 )，如果充分利用時序數(shù)據(jù)的特點(diǎn)，我們可以將數(shù)據(jù)寫入和查詢性能大幅提高，數(shù)據(jù)壓縮率也能大幅提高。 TDengine 之所以在 2016 年被研發(fā)出來，其中一個核心原因就是團(tuán)隊(duì)認(rèn)為 InflxuDB 并沒有充分利用時序數(shù)據(jù)特點(diǎn)。如果都是 Time Series Database，用戶當(dāng)然也會選擇性能或效率更高的產(chǎn)品。因此從研發(fā)的第一天起，濤思數(shù)據(jù)整個團(tuán)隊(duì)就一直在追求極致的性能，幸運(yùn)的是，TDengine 日益增進(jìn)的功能效果，也讓一眾支持者不負(fù)眾望。

有些公司為了避免麻煩，就選用 OpenTSDB，因?yàn)樗逊植际桨姹疽查_源了。從使用的角度來看，OpenTSDB 底層的存儲引擎用的是 HBase，安裝維護(hù)極為復(fù)雜，存儲壓縮性能不夠，查詢效率也很低，不是一個優(yōu)秀的產(chǎn)品。但它仍然有相當(dāng)多的用戶，這唯一的原因就是由于它支持分布式，可以水平線性擴(kuò)展。

TDengine 的設(shè)計是基于單個硬件、軟件系統(tǒng)不可靠，基于任何單臺計算機(jī)都無法提供足夠計算能力和存儲能力處理海量數(shù)據(jù)的假設(shè)而進(jìn)行設(shè)計的。因此 TDengine 從研發(fā)的第一天起，就是按照水平擴(kuò)展、高可用架構(gòu)進(jìn)行設(shè)計的。通過對數(shù)據(jù)進(jìn)行分區(qū)、分片，而且采用虛擬節(jié)點(diǎn)(vnode)技術(shù)，保證系統(tǒng)的處理能力是水平擴(kuò)展的。如果要增加系統(tǒng)的處理能力，只需要增加新的節(jié)點(diǎn)即可。

更好的是，和 InfluxDB集群功能閉源不同，2020年8月，TDengine 團(tuán)隊(duì)將集群版開源了。
TDengine 是通過數(shù)據(jù)采集點(diǎn)以及時間兩個維度，對大數(shù)據(jù)進(jìn)行切分，實(shí)現(xiàn)水平擴(kuò)展的。

分片：在 TDengine Database 的設(shè)計與實(shí)現(xiàn)里，一個集群有多個節(jié)點(diǎn)，每個節(jié)點(diǎn)可以有一個或多個虛擬節(jié)點(diǎn)(vnode)，每個虛擬節(jié)點(diǎn)里存儲了一定數(shù)量的數(shù)據(jù)采集點(diǎn)的數(shù)據(jù)，而一個數(shù)據(jù)采集點(diǎn)的數(shù)據(jù)永遠(yuǎn)只存放在一個 vnode 里。這樣如果有很多數(shù)據(jù)采集點(diǎn)，這些數(shù)據(jù)采集點(diǎn)的數(shù)據(jù)將會分布在多個 vnode 上，分布在多個節(jié)點(diǎn)里。數(shù)據(jù)寫入時，TDengine Database 的客戶端將要寫入的數(shù)據(jù)直接寫入對應(yīng)的 vnode，從而實(shí)現(xiàn)寫入的水平擴(kuò)展。對于單個數(shù)據(jù)采集點(diǎn)數(shù)據(jù)的查詢，毫無疑問，是水平擴(kuò)展的，節(jié)點(diǎn)越多，吞吐率就越大。對于聚合查詢，查詢請求將先發(fā)送到對應(yīng)的 vnode 里，vnode 先做完聚合操作，客戶端然后將來自多個 vnode 的查詢結(jié)果做第二次聚合，因?yàn)?vnode 數(shù)量有限，這樣在客戶端做的聚合查詢計算量不大，從而實(shí)現(xiàn)聚合查詢的水平擴(kuò)展能力。

分區(qū)：除將數(shù)據(jù)分片之外，TDengine 還將一個 vnode 里存儲的時序數(shù)據(jù)按照時間段進(jìn)行切分。每個時間段的數(shù)據(jù)都一定保存在一起，不同時間段的數(shù)據(jù)不會有交集，時間段可以是一天，幾天，一周，由用戶自己定義。按照時間段切分時序數(shù)據(jù)有很多好處，查詢數(shù)據(jù)時，根據(jù)時間段，可以直接定位要查找的文件，從而加快查詢速度。另外一方面，可以高效地實(shí)現(xiàn)數(shù)據(jù)保留策略。超過最長保留時間的數(shù)據(jù)，直接刪除一個時間段對應(yīng)的文件即可。而且按照時間段切分?jǐn)?shù)據(jù)，還可以方便實(shí)現(xiàn)多級存儲，冷熱數(shù)據(jù)放在不同存儲介質(zhì)上，進(jìn)一步降低存儲成本。

TDengine 還通過虛擬節(jié)點(diǎn)組技術(shù)來提供系統(tǒng)的高可用。不同物理節(jié)點(diǎn)上的 vnode 可以形成一個虛擬節(jié)點(diǎn)組，這個虛擬節(jié)點(diǎn)組里的數(shù)據(jù)是通過 Master-Slave 來進(jìn)行同步的，來保證這個虛擬節(jié)點(diǎn)組內(nèi)數(shù)據(jù)的一致性。數(shù)據(jù)寫入只能在 master 進(jìn)行，但查詢可以在 master 和 slave 上同時進(jìn)行。如果 Master 出現(xiàn)故障，系統(tǒng)將自動選主，這樣來保證系統(tǒng)的高可用，不會由于某臺機(jī)器宕機(jī)，而無法對外提供服務(wù)。

關(guān)于集群的具體使用，請看《集群管理》。