隨著 5G 基站等通信工程的加快建設(shè)，城市治理、城市安全管理成為熱門話題，物聯(lián)設(shè)備在我們的社會中扮演的角色也變得越來越重要，智慧燃?xì)?、智能電表、智能井蓋、智能交通等項目在眾多城市開始布局，隨著一眾智慧城市項目的深入落地，海量時序數(shù)據(jù)的高效處理和成本管控也成為一個待解的難題。
為幫助大家尋找解決上述問題的最優(yōu)解，我們匯總了四家比較具有代表性的智慧城市升級項目的架構(gòu)改造案例，一起來看看他們都是如何做的。
SENSORO x TDengine
“我們進行的數(shù)據(jù)庫調(diào)研測試結(jié)果顯示，TDengine 的空間占用只有 Druid 的 60%（沒有計算 Druid 使用的 Deep Storage）。針對單一設(shè)備的查詢與聚和的響應(yīng)時間比 Druid 有倍數(shù)的提升，尤其時間跨度較久時差距更明顯（在十倍以上），同時 Druid 的響應(yīng)時間方差也較大。在實際業(yè)務(wù)環(huán)境中，我們創(chuàng)建了多列的超級表，雖然會存在大量的空列，但得益于 TDengine 的優(yōu)化，能達到恐怖的 0.01 的壓縮率，簡單計算下來大約需要 3.67GB 每億條?！?/span>
業(yè)務(wù)背景
SENSORO 面向城市基礎(chǔ)設(shè)施與核心要素提供全域數(shù)字化服務(wù)方案，建立城市級傳感器網(wǎng)絡(luò)所涉及的傳感器種類十分多樣，由此產(chǎn)生的數(shù)據(jù)量也十分龐大。在系統(tǒng)開發(fā)初期，SENSORO 先是選擇了 Apache Druid 作為存儲傳感數(shù)據(jù)的數(shù)據(jù)庫，然而在使用過程中卻遇到了各種各樣的問題，這使得其將目光轉(zhuǎn)移到了 TDengine 上，但因為平臺涉及的特殊數(shù)據(jù)模型，合作便一直擱置了下來。隨后 TDengine 經(jīng)過了多個版本迭代，支持了 join 查詢，而 SENSORO 的數(shù)據(jù)模型也發(fā)生了變化，遷移到 TDengine 時不再需要做出很多的系統(tǒng)模塊改動，由此雙方的合作也開始快速展開。
架構(gòu)圖
SENSORO 基于 TDengine 助力基層政府打造數(shù)字化應(yīng)用標(biāo)桿
北京智能建筑 x TDengine
“TDengine 幫助我們在邊緣側(cè)解決了一個很大的問題，即邊緣存儲的問題。因為很多時候邊緣是布署在資源比較少的機器上面，甚至是 ARM 的工業(yè)盒子上面，在資源使用上非常的苛刻，而現(xiàn)在得益于 TDengine 超強的壓縮算法，我們使用非常小的存儲空間就存儲了幾千萬數(shù)據(jù)，壓縮率遠(yuǎn)超 1/20，在單機上面布署一個 TDengine 服務(wù)器就可以輕輕松松地存儲上億的數(shù)據(jù)。此外它還擁有超強的計算能力，占用的資源也非常小，在我們的業(yè)務(wù)中千萬級數(shù)據(jù)檢索時間達到了毫秒級，從用戶角度來說產(chǎn)品體驗非常好。”
業(yè)務(wù)背景
北京智能建筑是北京市在智能建筑和智慧城市領(lǐng)域的創(chuàng)新平臺，同時也是冬奧科技平臺公司、智慧冬奧國家重點項目設(shè)計單位和核心實施單位。在邊緣側(cè)采集數(shù)據(jù)存儲方案中，其面臨著在有限的計算資源下，如何實現(xiàn)最高效的數(shù)據(jù)存儲、分析和計算的問題。經(jīng)過調(diào)研與測試，其最終選擇根據(jù)業(yè)務(wù)需求靈活搭配使用 TDengine 與 SQLite——由 TDengine 處理時序數(shù)據(jù)，SQLite 處理關(guān)系數(shù)據(jù)，以此更好地實現(xiàn)邊緣側(cè)的數(shù)據(jù)自治。
架構(gòu)圖
一個服務(wù)器存儲上億數(shù)據(jù)，TDengine 在北京智能建筑邊緣存儲的應(yīng)用
交通數(shù)據(jù)資源管理系統(tǒng) x TDengine
“所有車輛最新位置信息的查詢是交通運行監(jiān)控中的重中之重，最初‘使用何種查詢語句實現(xiàn)高效查詢’是非常困擾我們的一件事，后面在 TDengine 社區(qū)團隊的幫助下，我們利用了隱藏字段名 tbname 和 group by 方法，高效地查詢了車輛的最新定位信息。在頻繁查詢的情況下，接近六萬輛車的位置信息，只用了不到 1 秒的查詢時間，簡單而又高效，完全符合我們的業(yè)務(wù)需求；在數(shù)據(jù)統(tǒng)計分析上，一個 64 天數(shù)據(jù)量的表，進行每日數(shù)據(jù)條數(shù)的降維統(tǒng)計，所需時間也不到 1 秒?！?/span>
業(yè)務(wù)背景
為了強化全市交通運輸管理、統(tǒng)籌綜合交通發(fā)展、提升交通運行和管理效率，某市級管理單位建立了大交通數(shù)據(jù)資源管理系統(tǒng)及相關(guān)應(yīng)用 “一圖一庫”。其中“一庫”部分主要內(nèi)容包括：數(shù)據(jù)接入、數(shù)據(jù)存儲、數(shù)據(jù)共享；“一圖”部分主要內(nèi)容包括：GIS 信息及其關(guān)聯(lián)數(shù)據(jù)信息在二維、三維地圖上的形象表達。在數(shù)據(jù)中臺的建設(shè)中，存在大量的時序數(shù)據(jù)應(yīng)用場景，其中最為關(guān)鍵的就是車輛運行產(chǎn)生的時序數(shù)據(jù)的存儲與使用。為了實現(xiàn)高效的業(yè)務(wù)處理， 研發(fā)人員決定從 InfluxDB、ClickHouse 和 TDengine 三款時序數(shù)據(jù)庫（Time Series Database）中進行選型調(diào)研，最終憑借強大的產(chǎn)品力，TDengine 脫穎而出。
架構(gòu)搭建上的考慮
由于該系統(tǒng)業(yè)務(wù)開發(fā)框架使用的是 Srping 框架，在使用 TAOS-JDBCDriver 進行開發(fā)時，可以選擇兩種方式進行數(shù)據(jù)入庫——JDBC-JNI 方式或者是 JDBC-RESTful 方式。在 TDengine 官網(wǎng)，明確記載了“JDBC-RESTful 性能是 JDBC-JNI 的 50%～90%”，因此，其選擇了 JDBC-JNI 方式進行多線程入庫——以數(shù)據(jù)庫連接池（Hikari、druid）+原生 SQL 執(zhí)行寫入為主要寫入模式。
數(shù)字政通 x TDengine
“壓縮方面，通過查看 3 個節(jié)點的 Vnode 目錄總大小，可以得知目前數(shù)據(jù)占用總量為 8.7GB。而從上述表結(jié)構(gòu)我們也能看出實際入庫數(shù)據(jù)總量大概為 203GB，經(jīng)過壓縮后為 8.7GB，壓縮率達到了 4% 左右，大幅節(jié)約了存儲成本。在查詢上，對 9 億數(shù)據(jù)量的超級表使用降采樣查詢，展示設(shè)備指標(biāo)日月年線，耗時僅僅 0.22 秒?！?/span>
業(yè)務(wù)背景
隨著智慧城市的加速建設(shè)，物聯(lián)設(shè)備的管理問題凸顯，為此，數(shù)字政通研發(fā)“城市管理物聯(lián)網(wǎng)平臺”對物聯(lián)網(wǎng)設(shè)備實行監(jiān)督，提供各類設(shè)備的實時監(jiān)測數(shù)據(jù)及報警數(shù)據(jù)，進一步滿足各類設(shè)備的數(shù)據(jù)分析、關(guān)聯(lián)分析、歷史分析、對比分析等需求。簡單來講就是通過鳥瞰整體數(shù)據(jù)來發(fā)現(xiàn)設(shè)備問題，便于及時派單處理，助力智慧城市管理。面對海量物聯(lián)網(wǎng)數(shù)據(jù)的處理，TDengine 的高效存儲給了數(shù)字政通相當(dāng)大的助力。
架構(gòu)圖
助力 60+ 市區(qū)管理建設(shè)，TDengine 聯(lián)手?jǐn)?shù)字政通打造智慧城市平臺
結(jié)語
通過上面的幾大案例我們可以看到，在解決海量時序數(shù)據(jù)處理效率低、處理成本高等問題上，關(guān)鍵點就是要選對合適的時序數(shù)據(jù)庫（Time Series Database），當(dāng)前市面上時序數(shù)據(jù)庫產(chǎn)品眾多，在性能提升和降低資源消耗上究竟誰能更勝一籌？如果你也在思考這一問題，那或許寫入性能：TDengine 最高達到 InfluxDB 的 10.3 倍，TimeScaleDB 的 6.74 倍 - TDengine | 濤思數(shù)據(jù)、查詢性能： TDengine 最高達到了 InfluxDB 的 37 倍、 TimescaleDB 的 28.6 倍 - TDengine | 濤思數(shù)據(jù)這兩篇文章能給到你答案。
