物聯(lián)網(wǎng)數(shù)據(jù)處理涉及到大量的設備和傳感器收集的數(shù)據(jù)，這些數(shù)據(jù)都具有典型的時序數(shù)據(jù)特征，具備數(shù)據(jù)量大、結構化等特點。對于很多物聯(lián)網(wǎng)平臺來說，創(chuàng)建之初在數(shù)據(jù)架構的搭建上大多選擇了較為成熟和流行的關系型數(shù)據(jù)庫或其他通用數(shù)據(jù)庫，但隨著設備數(shù)的增加、時序數(shù)據(jù)的爆發(fā)式增長，原本的數(shù)據(jù)架構面臨運維難、開發(fā)難、成本高等問題。為了幫助企業(yè)找到物聯(lián)網(wǎng)場景下數(shù)據(jù)架構的最佳改造手段，本文匯總了四個典型的物聯(lián)網(wǎng)平臺的實踐經(jīng)驗，把它們曾面臨的數(shù)據(jù)難題以及解決思路分享給大家。

至數(shù)搖光 x TDengine

“目前改造工作已經(jīng)全部完成，改造后有大約 80% 左右的指標模型放到了 TDengine 中，20% 左右的主數(shù)據(jù)或維表數(shù)據(jù)存放在 MySQL 數(shù)據(jù)庫中。相較于改造前的 80% 指標模型存放在 MySQL 中，20% 指標數(shù)據(jù)存放在 OpenTSDB 數(shù)據(jù)庫中，結果剛好進行了顛倒，服務器資源使用情況也有所下降。應用整體的頁面影響速度顯著提高，數(shù)據(jù)模型及數(shù)據(jù)指標上也可以更加地靈活多變?！?/p>

業(yè)務背景

至數(shù)物聯(lián)網(wǎng)平臺場景多、數(shù)據(jù)模型復雜，改造前數(shù)據(jù)庫采用 OpenTSDB+MySQL 結合的方式實現(xiàn)，由于 OpenTSDB 無法滿足復雜查詢場景，因此 80% 的場景指標只能基于 MySQL 數(shù)據(jù)庫來實現(xiàn)，這樣帶來的問題就是 MySQL 數(shù)據(jù)庫的數(shù)據(jù)增長迅速，需要定時做冷熱數(shù)據(jù)分離及數(shù)據(jù)庫表維護動作。在對 TDengine 進行充分調研后，至數(shù)搖光決定從時序數(shù)據(jù)庫 OpenTSDB 遷移到 TDengine，并基于 TDengine 的特性對系統(tǒng)進行徹底性的改造。

架構圖

查看案例詳情

華自科技 x TDengine

“當前項目數(shù)據(jù)測點大概在 18 萬左右，改造后數(shù)據(jù)存儲周期由原來的 5 分鐘減少到 1 秒鐘，存儲的數(shù)據(jù)維度更精細了，能為平臺的智能診斷、智能分析服務提供更準確的數(shù)據(jù)支持，同時各業(yè)務場景下的計算查詢性能也提升了不少，數(shù)據(jù)庫服務器由原來的 6 臺減少到目前的 3 個節(jié)點集群。”

業(yè)務背景

華自科技旗下的物聯(lián)網(wǎng)數(shù)據(jù)平臺是電站及泵站智慧運維平臺的核心組成。在數(shù)據(jù)存儲上，此前其采用 MySQL 分庫分表方案來存儲歷史數(shù)據(jù)，使用 Redis 來存儲實時數(shù)據(jù)，在測點數(shù)較少或者集控需求不是很多的場景下，基本滿足需求，但隨著平臺業(yè)務的發(fā)展，接入的站點越來越多，運維難、開發(fā)難、成本高等問題逐漸凸顯。為了解決這些問題，華自科技決定重新進行技術選型，尋找替代方案，升級目前數(shù)據(jù)庫存儲方案。結合平臺實際需要，其調研了 InfluxDB、庚頓、麥杰、TimescaleDB、TDengine 這幾款數(shù)據(jù)庫產(chǎn)品，最終選擇了 TDengine。

改造遷移

由于 TDengine 采用了類 SQL 的語法，支持 MyBatis 等 ORM 框架，因此老業(yè)務在代碼層面的改動非常少，改動最多的就是將原來的 MySQL 函數(shù)結合應用代碼的一些計算邏輯直接用 TDengine 的函數(shù)替換掉。在通過業(yè)務系統(tǒng)觀察和驗證各項功能正常之后，就可以進行歷史數(shù)據(jù)的遷移了。由于 TDengine 的表結構與原來的 MySQL 存儲結構基本類似，因此物聯(lián)網(wǎng)數(shù)據(jù)平臺開發(fā)人員直接采用 DataX 的 TDengine 插件，歷史數(shù)據(jù)就很輕松地遷移過來了。

查看案例詳情

睿信物聯(lián)網(wǎng)平臺 x TDengine

“TDengine 的安裝部署非常簡單，配合 Docker 容器，在幾分鐘內就能完成。遷移到 TDengine 之后，我們的運營監(jiān)控工作也變簡單了，只需要對 TDengine 的幾個進程進行監(jiān)控，占用的磁盤空間減少到了原來的 1/5，使用的主機也減少到原來的 1/5，極大節(jié)省了資源開銷。遇到技術難題，不僅可以直接在官方渠道 https://github.com/taosdata/TDengine 提 issue，也可以在 TDengine 的技術社區(qū)提問，TDengine 的技術專家響應非?？臁！?/p>

業(yè)務背景

睿信物聯(lián)網(wǎng)平臺此前采用 OpenTSDB 進行時序數(shù)據(jù)的存儲，功能上基本滿足現(xiàn)有需求，但是由于 OpenTSDB 架構復雜，體量過重，給開發(fā)測試、安裝部署以及運維管理等工作帶來了不小的麻煩。隨著業(yè)務的發(fā)展，問題逐漸凸顯，開始影響工作效率，具體可以歸納為安裝難、調試難、運維難、成本高四大問題。從業(yè)務發(fā)展的角度出發(fā)，睿信開發(fā)人員決定重新進行技術選型，尋找 OpenTSDB 的替代方案，分別對 InfluxDB、TimescaleDB 和 TDengine 三款時序數(shù)據(jù)庫進行調研。

架構圖

查看案例詳情

蒼穹數(shù)碼 x TDengine

“我們以近 10 年全省的雨量站小時雨量數(shù)據(jù)為測試數(shù)據(jù)，從常用的應用場景對 TimescaleDB 和 TDengine 兩款數(shù)據(jù)庫進行對比分析，歷史數(shù)據(jù)批量入庫場景中 TimescaleDB 用時 24 小時，TDengine 用時僅僅 2 小時；入庫后數(shù)據(jù)文件大小對比結果中 TimescaleDB 是 38GB，TDengine 是 698MB；常見查詢場景比對中 TDengine 也均優(yōu)于 TimescaleDB。從入庫、壓縮比及查詢 3 個維度來看，TDengine 都是完勝?！?/p>

業(yè)務背景

在地災專業(yè)監(jiān)測物聯(lián)網(wǎng)平臺項目中，首先需要解決的就是海量時序數(shù)據(jù)的存儲和計算問題，其有著體量大、時間長，寫入、查詢要求高等特點，傳統(tǒng)關系型數(shù)據(jù)庫已經(jīng)無法滿足實時寫入與高性能查詢要求。該項目在 2018 年創(chuàng)建之初采用的是大型企業(yè)級數(shù)據(jù)庫 Oracle，目前已經(jīng)無法滿足實時寫入與高性能查詢要求，特別是當雨季來臨，傳感器數(shù)據(jù)采集頻率提高到秒級、毫秒級別，數(shù)據(jù)入庫就會阻塞，效率非常低下。蒼穹數(shù)碼選擇接入 TDengine 以解決海量時序數(shù)據(jù)的存儲和計算問題。

架構圖

查看案例詳情

通過上面幾個實踐我們也能看到，時序數(shù)據(jù)積累得非?？?，每秒產(chǎn)生數(shù)百萬條數(shù)據(jù)，通用數(shù)據(jù)庫并不是為處理這種規(guī)模的數(shù)據(jù)而設計的——關系數(shù)據(jù)庫在非常大的數(shù)據(jù)集上表現(xiàn)很差，NoSQL 數(shù)據(jù)庫雖然解決了擴展能力，但是其通用的數(shù)據(jù)組織方式并不完全適用于對時序數(shù)據(jù)存儲和查詢需求，用戶必須根據(jù)實際應用場景，進行特殊設計甚至大量數(shù)據(jù)冗余存儲才能較好的利用資源處理請求。

而在時序數(shù)據(jù)庫（Time Series Database）的選擇上，企業(yè)也要擦亮雙眼，進行充分的調研測試，選擇性能最好資源使用率最高的產(chǎn)品，此前我們基于第三方性能基準測試平臺 TSBS 測試發(fā)布的 IoT 場景下 TDengine 3.0 性能對比分析報告，大家也可做參考。如果你正面臨數(shù)據(jù)處理難題，歡迎添加小T微信（tdengine）尋求幫助。