智能制造企業(yè)案例

西門子 x TDengine

“從高性能、高可用、低成本、高度一體化幾個目標(biāo)出發(fā)，我們發(fā)現(xiàn) TDengine 正好符合產(chǎn)品重構(gòu)所有的要求，尤其是低成本和高度一體化這兩個點，這是目前絕大部分?jǐn)?shù)據(jù)平臺或時序數(shù)據(jù)庫都不具備的。在確定選擇 TDengine 作為系統(tǒng)的數(shù)據(jù)庫后，我們在 SIMICAS? OEM 2.0 版本中移除了Flink、Kafka 以及 Redis，系統(tǒng)架構(gòu)大大簡化?！?/p>

業(yè)務(wù)背景

SIMICAS? OEM 設(shè)備遠程運維套件是由 SIEMENS DE&DS DSM 團隊開發(fā)的一套面向設(shè)備制造商的數(shù)字化解決方案。在其 1.0 版中，團隊使用了 Flink + Kafka + PostgreSQL + Redis 的架構(gòu)，因為引入了 Flink 和 Kafka，導(dǎo)致系統(tǒng)部署時非常繁瑣，服務(wù)器開銷巨大；同時為了滿足大量數(shù)據(jù)的存儲問題，PostgreSQL 中不得不做分庫分表操作，應(yīng)用程序較為復(fù)雜。這種情況下，如何降低系統(tǒng)復(fù)雜度、減少硬件資源開銷，幫助客戶減少成本，成為研發(fā)團隊的核心任務(wù)。在調(diào)研過程中，TDengine 脫穎而出。

架構(gòu)圖

美的 x TDengine

“當(dāng)前，TDengine 主要被應(yīng)用于中央空調(diào)制冷設(shè)備的監(jiān)控業(yè)務(wù)中，作為先行試點，這一場景已經(jīng)取得了不錯的效果。在樓宇智能化方面，我們也有很多工作要做，從邊緣側(cè)的監(jiān)控、到指令控制、再到邊云協(xié)同的一體化服務(wù)，我們會在這些場景中繼續(xù)探索和挖掘 TDengine 的潛力?！?/p>

業(yè)務(wù)背景

在 2021 樓宇科技 TRUE 大會上，美的暖通與樓宇事業(yè)部首次發(fā)布了數(shù)字化平臺 iBuilding，以“軟驅(qū)硬核”方式賦能建筑行業(yè)。作為一個全新的項目，iBuilding 在數(shù)據(jù)庫選型上比較謹(jǐn)慎，分別對比了關(guān)系型數(shù)據(jù)庫以及主流的時序數(shù)據(jù)庫，包括 InfluxDB、TDengine、MySQL 等，因為在需求上更偏向于高效的存儲和大范圍時間的數(shù)據(jù)拉取，iBuilding 在綜合評估了適配、查詢、寫入和存儲等綜合能力后，最終選擇了 TDengine。

架構(gòu)圖

拓斯達 x TDengine

“運行一段時間后，TDengine 的查詢、寫入速度完全可以滿足我們目前的客戶需求，最慢的分鐘級，最快的能達到 1 秒一條；一個設(shè)備一天最多能寫入近十萬條數(shù)據(jù)，近千個設(shè)備同時寫入也完全沒有問題，相較于之前，寫入速度提升了數(shù)十倍。查詢數(shù)據(jù)在以月為單位的時間范圍內(nèi)也沒有過于明顯的延遲，整體的數(shù)據(jù)壓縮比大概是 1/10，目前每天產(chǎn)生的數(shù)據(jù)量在數(shù) G 左右?！?/p>

業(yè)務(wù)背景

在拓斯達的業(yè)務(wù)中，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫已經(jīng)無法高效處理時序數(shù)據(jù)，在加載、存儲和查詢等多個方面都遇到了挑戰(zhàn)，主要問題包括寫入吞吐低、存儲成本大、維護成本高、查詢性能差。為了更好地滿足時序數(shù)據(jù)的處理需求，拓斯達開始進行數(shù)據(jù)庫選型調(diào)研，他們發(fā)現(xiàn)，TDengine 專為時序數(shù)據(jù)所打造和優(yōu)化的寫入、存儲、查詢等功能，非常匹配工業(yè)傳感器數(shù)據(jù)的應(yīng)用分析場景，最終其使用 TDengine 搭建了新的數(shù)據(jù)處理架構(gòu)。

架構(gòu)實現(xiàn)思路

通過網(wǎng)關(guān)采集設(shè)備數(shù)據(jù)推送到 MQTT，Java 后端監(jiān)聽到后會寫入 TDengine，在后端按需求查詢處理后再把數(shù)據(jù)返回給前端。具體來說，網(wǎng)關(guān)會先讀取后臺發(fā)布的上行規(guī)則，在采集到設(shè)備數(shù)據(jù)后，使用上行規(guī)則對數(shù)據(jù)進行處理計算后再將結(jié)果返回給下行規(guī)則模塊，后臺監(jiān)聽到后，會連接 TDengine 進行數(shù)據(jù)庫表的創(chuàng)建修改和數(shù)據(jù)寫入。之前在云平臺拓斯達使用過 Kafka 進行數(shù)據(jù)的發(fā)布訂閱，現(xiàn)在所有環(huán)境都改為 MQTT 了。

和利時 x TDengine

“在測試階段，我們發(fā)現(xiàn)，同等條件下，TDengine 的壓縮率最高，數(shù)據(jù)占用的存儲空間最??；在原始數(shù)據(jù)查詢上，OpenTSDB 最慢，TDengine 與 HolliTSDB 在伯仲之間；在聚合查詢操作上，TDengine 最快，HolliTSDB 的速度和 InfluxDB 相當(dāng)，OpenTSDB 最慢。同時，InfluxDB 只能單機部署，集群版本并未開源，且查詢性能存在瓶頸，其 QPS 約為 30-50。”

業(yè)務(wù)背景

在智能制造場景下，面對龐大的時序數(shù)據(jù)處理需求，Oracle、PostgreSQL 等傳統(tǒng)關(guān)系型數(shù)據(jù)庫越來越吃力，因此和利時開始進行時序數(shù)據(jù)庫的選型，對包括 InfluxDB、OpenTSDB、HolliTSDB（和利時自研時序數(shù)據(jù)庫）和 TDengine 在內(nèi)的四款時序數(shù)據(jù)庫進行了選型調(diào)研及相關(guān)測試。測試結(jié)果顯示，在同等條件下，TDengine 在查詢、存儲等方面均優(yōu)于其他幾款數(shù)據(jù)庫，最終和利時決定接入 TDengine，以享受更多元的本地化支持和響應(yīng)。

架構(gòu)圖

從以上案例中不難看出，在智能制造場景下，面對龐大的時序數(shù)據(jù)處理需求，專業(yè)的時序數(shù)據(jù)庫顯然比傳統(tǒng)的數(shù)據(jù)解決方案效果更加明顯，上述企業(yè)案例在架構(gòu)改造之后，確實達到了更高程度的降本增效。如果你有同樣的困擾，歡迎添加小T微信（tdengine），加入 TDengine 技術(shù)交流群，和專業(yè)的解決方案架構(gòu)師點對點溝通。