在萬(wan)物互聯的(de)(de)(de)時(shi)代，大(da)(da)到(dao)(dao)企業數(shu)(shu)字化(hua)轉型、數(shu)(shu)字城市建設，小(xiao)到(dao)(dao)和(he)生(sheng)活(huo)息息相關的(de)(de)(de)家(jia)居(ju)生(sheng)活(huo)、智能(neng)駕(jia)駛、運動健(jian)康等，都離不開智能(neng)物理設備(bei)廣(guang)泛的(de)(de)(de)連接(jie)和(he)互通。在 IoT 設備(bei)的(de)(de)(de)整體運作過(guo)程中(zhong)，會(hui)產(chan)生(sheng)大(da)(da)量的(de)(de)(de)時(shi)序數(shu)(shu)據，而傳統的(de)(de)(de)數(shu)(shu)據解決方(fang)案不管是在性(xing)能(neng)還是成本(ben)(ben)管控上都捉襟(jin)見肘。因此，IoT 產(chan)品/平臺想要實現快速發展，首要解決的(de)(de)(de)難題就(jiu)是數(shu)(shu)據處理痛點。本(ben)(ben)文(wen)優選(xuan)出幾(ji)大(da)(da) IoT 項目的(de)(de)(de)數(shu)(shu)據架構改(gai)造實踐，給到(dao)(dao)大(da)(da)家(jia)參考。

OPPO x TDengine

“我們寫入 60 萬行數據，到 MySQL（目前部分業務部署在 MySQL 集群）和 TDengine 的(de) 4C 12G 容器上，對 CPU/內(nei)(nei)存(cun)/磁(ci)盤進行觀察(cha)。測(ce)試(shi)發現 CPU 和內(nei)(nei)存(cun)消耗基本持平的(de)情況下，TDengine 的(de)落盤數(shu)據是(shi) MySQL 環(huan)境的(de)1/4左右。”

業務背景

在 OPPO 的穿戴產品的手環/手表類業務中，產生的數據類型為時序數據，具有寫入量巨大且存在離線/歷史數據補錄（更新）的處理需求。此前使用的 MongoDB/MySQL 集群方案，后端存儲壓力較大，需要經常擴盤，針對此痛點，OPPO 云計算中心智慧物聯云團隊嘗試調研對比了幾款時序數據庫（Time Series Database，TSDB ）產品，試(shi)圖尋找(zhao)一個(ge)降本增(zeng)效的解(jie)決方案(an)，最(zui)后(hou)選中了 TDengine。

集群部署如下：

京東云 x TDengine

“在與 TDengine 工(gong)程師溝通(tong)后， 我們只(zhi)使用了(le) 3 臺(tai) 4C16GB 構成的(de)(de) TDengine 的(de)(de)集群，就承(cheng)載(zai)了(le)線上(shang)的(de)(de)業(ye)務(wu)。數據(ju)聚合(he)(he)方面，根據(ju) TDengine 的(de)(de)性能(neng)、機(ji)器配置和前期測試的(de)(de)時間(jian)開銷，只(zhi)需很短的(de)(de)時間(jian)就完成了(le)全量(liang)設備的(de)(de)數據(ju)聚合(he)(he)。CPU 方面也一(yi)直很穩定，在常態下(xia) CPU 低于 10%，由(you)于設備的(de)(de)數據(ju)聚合(he)(he)需要消耗(hao)大(da)量(liang)的(de)(de) CPU，因此(ci)在每個整點 CPU 會(hui)有所上(shang)升，但是也不會(hui)超過(guo) 45% 的(de)(de)負載(zai)。”

業務背景

京東(dong)(dong)云智(zhi)(zhi)能家居場景維護(hu)著大(da)(da)量(liang)的智(zhi)(zhi)能設(she)備，這些設(she)備聯網后(hou)，會根據(ju)(ju)設(she)備設(she)定的速(su)率持續產生時(shi)序數據(ju)(ju)，比如有的設(she)備采樣間隔是 15 秒。京東(dong)(dong)云 IoT 團隊結合本公司數據(ju)(ju)特點與(yu)業務需求，對多種工業時(shi)序數據(ju)(ju)庫進(jin)行(xing)了技術選(xuan)型，以(yi)解決龐大(da)(da)的數據(ju)(ju)存(cun)儲和計(ji)算帶來(lai)的挑戰，在進(jin)行(xing)選(xuan)型時(shi)對比了 OpenTSDB 和 TDengine，最終 TDengine 以(yi)明顯(xian)優(you)勢勝出。

CPU 消耗圖示

圖撲物聯 x TDengine

“在(zai)(zai)(zai)(zai)之(zhi)前一個(ge)版本，平(ping)臺底(di)層使用(yong)的是 InfluxDB 來存(cun)儲時序(xu)數據(ju)，然(ran)而 InfluxDB 在(zai)(zai)(zai)(zai)面對海(hai)量數據(ju)時的讀寫性能存(cun)在(zai)(zai)(zai)(zai)瓶(ping)頸，在(zai)(zai)(zai)(zai)深入使用(yong) TDengine 后(hou)，我們還發現了諸多優勢。受益于 TDengine 的超高性能和超小(xiao)體量，我們在(zai)(zai)(zai)(zai)山東大禹水處理有限公司中央水機(ji)監控項(xiang)目中的整(zheng)個(ge)平(ping)臺架(jia)構(gou)變得更加簡(jian)化，解決了工業(ye)物(wu)聯網監控分析系統(tong)開(kai)發成本高、周期長、運維難度大等(deng)痛點。”

業務背景

針對海量(liang)的(de)(de)設備上報數(shu)(shu)據(ju)(ju)(ju)，圖撲 IoT 平臺在做實時(shi)顯示(shi)的(de)(de)同時(shi)還考慮將歷史數(shu)(shu)據(ju)(ju)(ju)也進行無損(sun)保存，并在 IoT Platform 上還要(yao)給用戶提供數(shu)(shu)據(ju)(ju)(ju)查詢的(de)(de)支持，但這就(jiu)對底(di)層的(de)(de)時(shi)序數(shu)(shu)據(ju)(ju)(ju)存儲提出了相(xiang)當高的(de)(de)要(yao)求。在對比了包括 InfluxDB 在內的(de)(de)幾個數(shu)(shu)據(ju)(ju)(ju)庫(ku)后(hou)，在最新的(de)(de)解決方(fang)案中，我們(men)選用了 TDengine 作(zuo)為時(shi)序數(shu)(shu)據(ju)(ju)(ju)的(de)(de)存儲引(yin)擎。

架構圖

寫在最后

在合適的時候選擇合適的數據庫是支持業務發展的關鍵，但數據庫的更換也并不是頭腦一熱就能拍板決定的，還需要進行數據庫產品的縝密觀察和調研，希望上述企業實踐能夠給到大家幫助。目前 TDengine 已經運營了幾十個用戶交流群，如果你有要進群溝通了解的需求，可以添加小T微信：tdengine1 。