物(wu)聯網數(shu)(shu)(shu)(shu)據(ju)(ju)處(chu)理涉及到(dao)大量(liang)的(de)(de)(de)設(she)備(bei)和傳(chuan)感器收集的(de)(de)(de)數(shu)(shu)(shu)(shu)據(ju)(ju)，這些數(shu)(shu)(shu)(shu)據(ju)(ju)都具(ju)有(you)典型的(de)(de)(de)時(shi)序數(shu)(shu)(shu)(shu)據(ju)(ju)特(te)征，具(ju)備(bei)數(shu)(shu)(shu)(shu)據(ju)(ju)量(liang)大、結構(gou)化等(deng)特(te)點。對于很多物(wu)聯網平(ping)臺(tai)來說，創建之初(chu)在(zai)數(shu)(shu)(shu)(shu)據(ju)(ju)架構(gou)的(de)(de)(de)搭建上(shang)大多選擇(ze)了較為成(cheng)熟和流行的(de)(de)(de)關系型數(shu)(shu)(shu)(shu)據(ju)(ju)庫或其(qi)他(ta)通用(yong)數(shu)(shu)(shu)(shu)據(ju)(ju)庫，但(dan)隨著設(she)備(bei)數(shu)(shu)(shu)(shu)的(de)(de)(de)增(zeng)(zeng)加、時(shi)序數(shu)(shu)(shu)(shu)據(ju)(ju)的(de)(de)(de)爆發式(shi)增(zeng)(zeng)長，原本的(de)(de)(de)數(shu)(shu)(shu)(shu)據(ju)(ju)架構(gou)面臨運維(wei)難、開發難、成(cheng)本高等(deng)問題。為了幫助企業找到(dao)物(wu)聯網場(chang)景(jing)下數(shu)(shu)(shu)(shu)據(ju)(ju)架構(gou)的(de)(de)(de)最(zui)佳改造手段，本文(wen)匯總了四個典型的(de)(de)(de)物(wu)聯網平(ping)臺(tai)的(de)(de)(de)實踐經驗，把它們(men)曾(ceng)面臨的(de)(de)(de)數(shu)(shu)(shu)(shu)據(ju)(ju)難題以及解決思路(lu)分享(xiang)給大家。
至數搖光 x TDengine
“目(mu)前改造(zao)(zao)工作已(yi)經全部完成(cheng)，改造(zao)(zao)后有大約 80% 左(zuo)(zuo)右(you)的(de)指標模(mo)型放到了(le) TDengine 中(zhong)，20% 左(zuo)(zuo)右(you)的(de)主數(shu)據(ju)或維(wei)表數(shu)據(ju)存(cun)放在(zai) MySQL 數(shu)據(ju)庫(ku)(ku)中(zhong)。相較于改造(zao)(zao)前的(de) 80% 指標模(mo)型存(cun)放在(zai) MySQL 中(zhong)，20% 指標數(shu)據(ju)存(cun)放在(zai) OpenTSDB 數(shu)據(ju)庫(ku)(ku)中(zhong)，結果剛(gang)好進行了(le)顛倒，服務器資源使用(yong)情況也有所下降。應用(yong)整體的(de)頁面影響速度顯著提高，數(shu)據(ju)模(mo)型及數(shu)據(ju)指標上也可以更加地靈活多變(bian)。”
業務背景
至數物聯網平臺場景多、數據模型復雜，改造前數據庫采用 OpenTSDB+MySQL 結合的方式實現，由于 OpenTSDB 無法滿足復雜查詢場景，因此 80% 的場景指標只能基于 MySQL 數據庫來實現，這樣帶來的問題就是 MySQL 數據庫的數據增長迅速，需要定時做冷熱數據分離及數據庫表維護動作。在對 TDengine 進行充分調研后，至數搖光決定從時序數據庫 OpenTSDB 遷移(yi)到(dao) TDengine，并基于 TDengine 的特性對系統(tong)進行徹底(di)性的改造。
架構圖
華自科技 x TDengine
“當前項(xiang)目數據測點大概(gai)在(zai) 18 萬左(zuo)右，改造后數據存儲(chu)周(zhou)期由原(yuan)來的 5 分鐘(zhong)(zhong)減少(shao)到 1 秒鐘(zhong)(zhong)，存儲(chu)的數據維度更(geng)精細了(le)，能為平臺的智能診斷、智能分析服務提供(gong)更(geng)準確的數據支持，同時各(ge)業(ye)務場景下的計算查詢(xun)性能也提升了(le)不少(shao)，數據庫服務器由原(yuan)來的 6 臺減少(shao)到目前的 3 個節點集群。”
業務背景
華(hua)(hua)自科技旗(qi)下(xia)的(de)物聯(lian)網數(shu)(shu)(shu)據平臺(tai)(tai)是電站(zhan)(zhan)(zhan)及泵(beng)站(zhan)(zhan)(zhan)智慧運(yun)維平臺(tai)(tai)的(de)核心組成(cheng)。在數(shu)(shu)(shu)據存(cun)(cun)儲(chu)上，此前其采用(yong) MySQL 分(fen)(fen)庫(ku)分(fen)(fen)表方案(an)來存(cun)(cun)儲(chu)歷史數(shu)(shu)(shu)據，使(shi)用(yong) Redis 來存(cun)(cun)儲(chu)實時(shi)數(shu)(shu)(shu)據，在測(ce)點數(shu)(shu)(shu)較少或(huo)者(zhe)集控需(xu)求不是很(hen)多(duo)的(de)場景(jing)下(xia)，基(ji)本滿足需(xu)求，但隨著(zhu)平臺(tai)(tai)業務的(de)發(fa)展，接入的(de)站(zhan)(zhan)(zhan)點越(yue)來越(yue)多(duo)，運(yun)維難(nan)、開發(fa)難(nan)、成(cheng)本高等問(wen)題(ti)逐漸凸顯。為(wei)了解決(jue)這些問(wen)題(ti)，華(hua)(hua)自科技決(jue)定重新進(jin)行技術選(xuan)型，尋找替(ti)代方案(an)，升級(ji)目前數(shu)(shu)(shu)據庫(ku)存(cun)(cun)儲(chu)方案(an)。結合平臺(tai)(tai)實際需(xu)要，其調研了 InfluxDB、庚頓、麥杰、TimescaleDB、TDengine 這幾(ji)款數(shu)(shu)(shu)據庫(ku)產品，最終(zhong)選(xuan)擇了 TDengine。
改造遷移
由于 TDengine 采用了(le)類 SQL 的語法，支持 MyBatis 等 ORM 框(kuang)架，因此老業(ye)務(wu)在(zai)代(dai)(dai)碼層(ceng)面的改動非(fei)常少，改動最多的就是將原來的 MySQL 函數結合(he)應用代(dai)(dai)碼的一些計(ji)算(suan)邏輯(ji)直接(jie)(jie)用 TDengine 的函數替換掉。在(zai)通過(guo)業(ye)務(wu)系統觀察(cha)和驗證各項功能正(zheng)常之后，就可以進(jin)行歷(li)史(shi)數據(ju)的遷移了(le)。由于 TDengine 的表結構與(yu)原來的 MySQL 存儲(chu)結構基(ji)本類似(si)，因此物聯網(wang)數據(ju)平臺開發人員直接(jie)(jie)采用 DataX 的 TDengine 插件，歷(li)史(shi)數據(ju)就很(hen)輕松地遷移過(guo)來了(le)。
睿信物聯網平臺 x TDengine
“TDengine 的(de)(de)(de)(de)安裝(zhuang)部署非常(chang)簡單，配合 Docker 容(rong)器，在幾分鐘(zhong)內就(jiu)能完成。遷(qian)移到 TDengine 之(zhi)后，我們的(de)(de)(de)(de)運營監(jian)控工作也變(bian)簡單了(le)，只需要對 TDengine 的(de)(de)(de)(de)幾個(ge)進(jin)程進(jin)行監(jian)控，占(zhan)用的(de)(de)(de)(de)磁盤空間減(jian)少(shao)到了(le)原(yuan)來(lai)的(de)(de)(de)(de) 1/5，使用的(de)(de)(de)(de)主機也減(jian)少(shao)到原(yuan)來(lai)的(de)(de)(de)(de) 1/5，極大節(jie)省(sheng)了(le)資源開銷。遇(yu)到技術(shu)難題，不僅可以(yi)直接在官方渠道 //github.com/taosdata/TDengine 提 issue，也可以(yi)在 TDengine 的(de)(de)(de)(de)技術(shu)社(she)區提問，TDengine 的(de)(de)(de)(de)技術(shu)專(zhuan)家響應(ying)非常(chang)快。”
業務背景
睿(rui)(rui)信(xin)物聯網平臺此前采用 OpenTSDB 進行時(shi)序數據的(de)存儲，功能上基本滿足現有(you)需求，但是由于(yu) OpenTSDB 架(jia)構復雜，體(ti)量過重，給開(kai)發測試(shi)、安裝部署(shu)以及運維管理等工作帶來(lai)了不小的(de)麻煩。隨著業務(wu)的(de)發展，問(wen)題逐漸凸(tu)顯，開(kai)始影響工作效率，具體(ti)可以歸納為安裝難、調(diao)試(shi)難、運維難、成本高(gao)四大問(wen)題。從業務(wu)發展的(de)角(jiao)度(du)出發，睿(rui)(rui)信(xin)開(kai)發人(ren)員決定重新進行技(ji)術選型(xing)，尋找(zhao) OpenTSDB 的(de)替代方案(an)，分(fen)別對 InfluxDB、TimescaleDB 和 TDengine 三款(kuan)時(shi)序數據庫進行調(diao)研。
架構圖
蒼穹數碼 x TDengine
“我們以近 10 年全省(sheng)的雨(yu)量站(zhan)小時雨(yu)量數(shu)據(ju)(ju)為測試數(shu)據(ju)(ju)，從(cong)常(chang)用的應用場景(jing)對(dui)(dui) TimescaleDB 和 TDengine 兩款(kuan)數(shu)據(ju)(ju)庫(ku)進(jin)行對(dui)(dui)比(bi)分析(xi)，歷史數(shu)據(ju)(ju)批量入庫(ku)場景(jing)中 TimescaleDB 用時 24 小時，TDengine 用時僅(jin)僅(jin) 2 小時；入庫(ku)后數(shu)據(ju)(ju)文件大小對(dui)(dui)比(bi)結(jie)果(guo)中 TimescaleDB 是 38GB，TDengine 是 698MB；常(chang)見查詢場景(jing)比(bi)對(dui)(dui)中 TDengine 也(ye)均(jun)優于 TimescaleDB。從(cong)入庫(ku)、壓縮(suo)比(bi)及查詢 3 個維度來看，TDengine 都是完勝。”
業務背景
在地災專(zhuan)業監測物聯(lian)網平臺項目中，首先需要解決(jue)的就是(shi)(shi)海量(liang)(liang)時(shi)序(xu)數(shu)(shu)(shu)據(ju)(ju)的存儲和(he)計(ji)算(suan)問(wen)題(ti)，其有(you)著體量(liang)(liang)大(da)、時(shi)間長，寫入(ru)(ru)、查(cha)(cha)詢(xun)要求高等(deng)特點，傳統關系(xi)型(xing)數(shu)(shu)(shu)據(ju)(ju)庫(ku)已(yi)經無(wu)(wu)法滿(man)足實時(shi)寫入(ru)(ru)與(yu)高性(xing)能查(cha)(cha)詢(xun)要求。該(gai)項目在 2018 年創建之(zhi)初采用的是(shi)(shi)大(da)型(xing)企業級數(shu)(shu)(shu)據(ju)(ju)庫(ku) Oracle，目前已(yi)經無(wu)(wu)法滿(man)足實時(shi)寫入(ru)(ru)與(yu)高性(xing)能查(cha)(cha)詢(xun)要求，特別(bie)是(shi)(shi)當雨(yu)季來臨(lin)，傳感器數(shu)(shu)(shu)據(ju)(ju)采集(ji)頻率(lv)提高到秒(miao)級、毫秒(miao)級別(bie)，數(shu)(shu)(shu)據(ju)(ju)入(ru)(ru)庫(ku)就會阻塞，效率(lv)非(fei)常(chang)低下。蒼穹數(shu)(shu)(shu)碼選擇接入(ru)(ru) TDengine 以解決(jue)海量(liang)(liang)時(shi)序(xu)數(shu)(shu)(shu)據(ju)(ju)的存儲和(he)計(ji)算(suan)問(wen)題(ti)。
架構圖
通(tong)過(guo)上面(mian)幾個實踐我(wo)們也能(neng)看到，時(shi)序(xu)數(shu)(shu)(shu)(shu)據(ju)積累(lei)得非常快(kuai)，每秒產生(sheng)數(shu)(shu)(shu)(shu)百萬條數(shu)(shu)(shu)(shu)據(ju)，通(tong)用(yong)數(shu)(shu)(shu)(shu)據(ju)庫并不(bu)是為處(chu)理這種規模的(de)數(shu)(shu)(shu)(shu)據(ju)而(er)設計(ji)的(de)——關系數(shu)(shu)(shu)(shu)據(ju)庫在非常大的(de)數(shu)(shu)(shu)(shu)據(ju)集上表現很差，NoSQL 數(shu)(shu)(shu)(shu)據(ju)庫雖然(ran)解(jie)決了擴展(zhan)能(neng)力，但是其通(tong)用(yong)的(de)數(shu)(shu)(shu)(shu)據(ju)組織方(fang)式(shi)并不(bu)完(wan)全適(shi)用(yong)于對(dui)時(shi)序(xu)數(shu)(shu)(shu)(shu)據(ju)存儲和查詢需(xu)求，用(yong)戶必須(xu)根據(ju)實際(ji)應(ying)用(yong)場景，進行特殊設計(ji)甚至大量(liang)數(shu)(shu)(shu)(shu)據(ju)冗余存儲才(cai)能(neng)較好的(de)利用(yong)資源(yuan)處(chu)理請求。
而在時序數據庫（Time Series Database）的選擇上，企業也要擦亮雙眼，進行充分的調研測試，選擇性能最好資源使用率最高的產品，此前我們基于第三方性能基準測試平臺 TSBS 測試發布的 IoT 場景下 TDengine 3.0 性能對比分析報告，大家也(ye)可(ke)做參考。如果你(ni)正面臨數(shu)據(ju)處理難題，歡迎添加小(xiao)T微(wei)信（tdengine）尋求(qiu)幫助。
