隨著 5G 基站等通信工程的加快建設，城市治理、城市安全管理成為熱門話題，物聯設備在我們的社會中扮演的角色也變得越來越重要，智慧燃氣、智能電表、智能井蓋、智能交通等項目在眾多城市開始布局，隨著一眾智慧城市項目的深入落地，海量時序數據的高效處理和成本管控也成為一個待解的難題。
為幫助大家(jia)尋找解決上述問題的最優解，我們匯總了(le)四家(jia)比較(jiao)具(ju)有代表性的智慧城市升級項目的架(jia)構改造案例，一起來看看他們都是如何做的。
SENSORO x TDengine
“我們進行(xing)的(de)數據庫調研測試結果顯(xian)示(shi)，TDengine 的(de)空(kong)(kong)間占用(yong)只有(you) Druid 的(de) 60%（沒有(you)計(ji)算(suan) Druid 使(shi)用(yong)的(de) Deep Storage）。針對單一設備(bei)的(de)查詢(xun)與聚和的(de)響應時(shi)間比 Druid 有(you)倍數的(de)提升，尤其時(shi)間跨度較久時(shi)差(cha)距更明顯(xian)（在十倍以(yi)上(shang)），同時(shi) Druid 的(de)響應時(shi)間方差(cha)也較大。在實際業務環境中，我們創建了多列的(de)超級(ji)表，雖然會存(cun)在大量的(de)空(kong)(kong)列，但得益(yi)于(yu) TDengine 的(de)優化，能達到恐(kong)怖(bu)的(de) 0.01 的(de)壓縮率，簡(jian)單計(ji)算(suan)下來大約需要 3.67GB 每億(yi)條。”
業務背景
SENSORO 面向城市基礎設施與核心要素提(ti)供全域數(shu)(shu)字化(hua)服務方案，建(jian)立城市級傳感器(qi)網絡所涉及的傳感器(qi)種類十(shi)分多(duo)(duo)樣，由(you)此產生的數(shu)(shu)據量也(ye)十(shi)分龐大(da)。在(zai)系統開(kai)發初期，SENSORO 先(xian)是選擇了(le)(le) Apache Druid 作(zuo)(zuo)為存儲傳感數(shu)(shu)據的數(shu)(shu)據庫(ku)，然而(er)在(zai)使用過程中卻遇到(dao)了(le)(le)各種各樣的問題(ti)，這使得其將目光轉移到(dao)了(le)(le) TDengine 上，但(dan)因為平(ping)臺涉及的特(te)殊數(shu)(shu)據模(mo)型，合作(zuo)(zuo)便(bian)一直擱(ge)置了(le)(le)下來。隨后 TDengine 經過了(le)(le)多(duo)(duo)個版本迭代，支持了(le)(le) join 查詢，而(er) SENSORO 的數(shu)(shu)據模(mo)型也(ye)發生了(le)(le)變化(hua)，遷移到(dao) TDengine 時不再需要做(zuo)出很(hen)多(duo)(duo)的系統模(mo)塊改(gai)動，由(you)此雙方的合作(zuo)(zuo)也(ye)開(kai)始快速展開(kai)。
架構圖
SENSORO 基(ji)于 TDengine 助力(li)基(ji)層政(zheng)府打造數字化應用標(biao)桿(gan)
北京智能建筑 x TDengine
“TDengine 幫助我們在(zai)(zai)邊緣側解決了一(yi)(yi)個很(hen)大的(de)問(wen)題(ti)(ti)，即(ji)邊緣存(cun)儲(chu)的(de)問(wen)題(ti)(ti)。因為(wei)很(hen)多時候邊緣是(shi)布(bu)署(shu)在(zai)(zai)資源(yuan)(yuan)比較少的(de)機(ji)器(qi)上(shang)(shang)(shang)面(mian)，甚至是(shi) ARM 的(de)工(gong)業盒子(zi)上(shang)(shang)(shang)面(mian)，在(zai)(zai)資源(yuan)(yuan)使(shi)用(yong)上(shang)(shang)(shang)非(fei)常(chang)的(de)苛(ke)刻，而現在(zai)(zai)得(de)益于 TDengine 超(chao)(chao)強的(de)壓縮算法，我們使(shi)用(yong)非(fei)常(chang)小的(de)存(cun)儲(chu)空間就存(cun)儲(chu)了幾千萬(wan)(wan)數(shu)據，壓縮率遠(yuan)超(chao)(chao) 1/20，在(zai)(zai)單機(ji)上(shang)(shang)(shang)面(mian)布(bu)署(shu)一(yi)(yi)個 TDengine 服務器(qi)就可(ke)以輕輕松松地存(cun)儲(chu)上(shang)(shang)(shang)億的(de)數(shu)據。此外它還擁(yong)有(you)超(chao)(chao)強的(de)計算能力，占用(yong)的(de)資源(yuan)(yuan)也非(fei)常(chang)小，在(zai)(zai)我們的(de)業務中千萬(wan)(wan)級數(shu)據檢索時間達到了毫(hao)秒級，從用(yong)戶(hu)角度來說產品體驗(yan)非(fei)常(chang)好。”
業務背景
北京(jing)智(zhi)(zhi)(zhi)能(neng)建筑(zhu)是北京(jing)市在智(zhi)(zhi)(zhi)能(neng)建筑(zhu)和智(zhi)(zhi)(zhi)慧(hui)(hui)城市領域的(de)(de)(de)創新(xin)平(ping)臺，同(tong)時也是冬(dong)奧科技平(ping)臺公司(si)、智(zhi)(zhi)(zhi)慧(hui)(hui)冬(dong)奧國家(jia)重點項目設計(ji)單位和核心實(shi)(shi)施單位。在邊(bian)緣側采集數(shu)(shu)據存(cun)儲方案(an)中，其(qi)面臨著在有限的(de)(de)(de)計(ji)算(suan)資源下，如何(he)實(shi)(shi)現(xian)最高效的(de)(de)(de)數(shu)(shu)據存(cun)儲、分(fen)析和計(ji)算(suan)的(de)(de)(de)問題。經過(guo)調研(yan)與測試，其(qi)最終選擇根據業務需求靈活(huo)搭配使用(yong) TDengine 與 SQLite——由 TDengine 處理(li)時序數(shu)(shu)據，SQLite 處理(li)關系數(shu)(shu)據，以此(ci)更好地實(shi)(shi)現(xian)邊(bian)緣側的(de)(de)(de)數(shu)(shu)據自治(zhi)。
架構圖
一個服務(wu)器存儲上億數(shu)據，TDengine 在北(bei)京智能建筑邊緣存儲的應用(yong)
交通數據資源管理系統 x TDengine
“所有車輛最(zui)新位(wei)(wei)置信息(xi)的(de)查(cha)詢是(shi)交通(tong)運行監控中的(de)重(zhong)中之重(zhong)，最(zui)初‘使(shi)用何種查(cha)詢語句實現高(gao)效查(cha)詢’是(shi)非常困(kun)擾(rao)我(wo)們的(de)一(yi)件事，后(hou)面在(zai) TDengine 社區團隊的(de)幫助(zhu)下(xia)，我(wo)們利用了隱藏(zang)字段名 tbname 和 group by 方(fang)法，高(gao)效地查(cha)詢了車輛的(de)最(zui)新定(ding)位(wei)(wei)信息(xi)。在(zai)頻繁查(cha)詢的(de)情況下(xia)，接近六萬輛車的(de)位(wei)(wei)置信息(xi)，只用了不到 1 秒(miao)的(de)查(cha)詢時間，簡單(dan)而又高(gao)效，完全符合我(wo)們的(de)業(ye)務需(xu)求；在(zai)數(shu)據(ju)統計分析上，一(yi)個 64 天數(shu)據(ju)量(liang)的(de)表，進行每日(ri)數(shu)據(ju)條數(shu)的(de)降維統計，所需(xu)時間也不到 1 秒(miao)。”
業務背景
為了(le)強化(hua)全市(shi)交通運輸(shu)管(guan)理(li)(li)(li)、統籌(chou)綜合(he)交通發(fa)展、提升(sheng)交通運行和管(guan)理(li)(li)(li)效(xiao)率，某市(shi)級管(guan)理(li)(li)(li)單位建立了(le)大(da)交通數(shu)據(ju)資源管(guan)理(li)(li)(li)系統及相關應用 “一圖(tu)一庫”。其中“一庫”部(bu)分主要(yao)內(nei)(nei)容包括：數(shu)據(ju)接入、數(shu)據(ju)存儲(chu)、數(shu)據(ju)共享；“一圖(tu)”部(bu)分主要(yao)內(nei)(nei)容包括：GIS 信息及其關聯(lian)數(shu)據(ju)信息在(zai)二維、三維地圖(tu)上的(de)形(xing)象表達。在(zai)數(shu)據(ju)中臺(tai)的(de)建設中，存在(zai)大(da)量的(de)時(shi)序(xu)數(shu)據(ju)應用場(chang)景，其中最(zui)為關鍵的(de)就是車(che)輛運行產生的(de)時(shi)序(xu)數(shu)據(ju)的(de)存儲(chu)與使用。為了(le)實(shi)現高效(xiao)的(de)業務處理(li)(li)(li)， 研(yan)發(fa)人(ren)員決(jue)定從 InfluxDB、ClickHouse 和 TDengine 三款時(shi)序(xu)數(shu)據(ju)庫（Time Series Database）中進行選型(xing)調研(yan)，最(zui)終憑借強大(da)的(de)產品力，TDengine 脫穎而出。
架構搭建上的考慮
由于該(gai)系(xi)統業務開發框架使用的是(shi)(shi) Srping 框架，在(zai)使用 TAOS-JDBCDriver 進行(xing)(xing)開發時，可(ke)以選擇兩種方(fang)式(shi)進行(xing)(xing)數(shu)據(ju)入(ru)(ru)庫(ku)——JDBC-JNI 方(fang)式(shi)或者(zhe)是(shi)(shi) JDBC-RESTful 方(fang)式(shi)。在(zai) TDengine 官網，明確記載了“JDBC-RESTful 性能是(shi)(shi) JDBC-JNI 的 50%～90%”，因(yin)此，其選擇了 JDBC-JNI 方(fang)式(shi)進行(xing)(xing)多線程入(ru)(ru)庫(ku)——以數(shu)據(ju)庫(ku)連接池（Hikari、druid）+原生(sheng) SQL 執行(xing)(xing)寫(xie)入(ru)(ru)為主要寫(xie)入(ru)(ru)模式(shi)。
數字政通 x TDengine
“壓縮方面(mian)，通過查(cha)看 3 個節點的(de) Vnode 目錄總(zong)大(da)小，可以得知目前(qian)數據(ju)(ju)占用(yong)總(zong)量為(wei) 8.7GB。而從上述(shu)表結構我(wo)們也能(neng)看出實際入庫數據(ju)(ju)總(zong)量大(da)概為(wei) 203GB，經過壓縮后為(wei) 8.7GB，壓縮率達到了(le) 4% 左右，大(da)幅節約(yue)了(le)存儲成本(ben)。在查(cha)詢(xun)上，對 9 億數據(ju)(ju)量的(de)超級表使用(yong)降(jiang)采樣查(cha)詢(xun)，展示設備指標日月年線，耗時(shi)僅(jin)僅(jin) 0.22 秒。”
業務背景
隨著智慧城市的加速建設，物聯設備的管理問題凸顯，為此，數字政通研發“城市管理物聯網平臺”對物聯網設備實行監督，提供各類設備的實時監測數據及報警數據，進一步滿足各類設備的數據分析、關聯分析、歷史分析、對比分析等需求。簡單來講就是通過鳥瞰整體數據來發現設備問題，便于及時派單處理，助力智慧城市管理。面對海量物聯網數據的處理，TDengine 的高效存儲給了數字政通相當大的助力。
架構圖
助力 60+ 市區管(guan)理建設(she)，TDengine 聯手(shou)數(shu)字政通打造智(zhi)慧(hui)城市平臺(tai)
結語
通過上面(mian)(mian)的(de)(de)幾大(da)案(an)例(li)我們可以看到(dao)(dao)，在(zai)(zai)解決海量時(shi)(shi)序數據(ju)處理效率低、處理成(cheng)本(ben)高等問題上，關(guan)鍵(jian)點(dian)就是要選對合適的(de)(de)時(shi)(shi)序數據(ju)庫（Time Series Database），當前市面(mian)(mian)上時(shi)(shi)序數據(ju)庫產品眾(zhong)多，在(zai)(zai)性能(neng)提升和降(jiang)低資源消耗上究竟誰能(neng)更勝一籌(chou)？如果你也在(zai)(zai)思考這一問題，那或許、這兩篇(pian)文章能(neng)給到(dao)(dao)你答案(an)。
