有限資源下如何實現最高效的資料處理？四個“智慧城市”專案尋找“最優解”

隨著 5G 基站等通訊工程的加快建設，城市治理、城市安全管理成為熱門話題，物聯裝置在我們的社會中扮演的角色也變得越來越重要，智慧燃氣、智慧電錶、智慧井蓋、智慧交通等專案在眾多城市開始佈局，隨著一眾智慧城市專案的深入落地，海量時序資料的高效處理和成本管控也成為一個待解的難題。

為幫助大家尋找解決上述問題的最優解，我們彙總了四家比較具有代表性的智慧城市升級專案的架構改造案例，一起來看看他們都是如何做的。

SENSORO x TDengine

“我們進行的資料庫調研測試結果顯示，TDengine 的空間佔用只有 Druid 的 60%（沒有計算 Druid 使用的 Deep Storage）。針對單一裝置的查詢與聚和的響應時間比 Druid 有倍數的提升，尤其時間跨度較久時差距更明顯（在十倍以上），同時 Druid 的響應時間方差也較大。在實際業務環境中，我們建立了多列的超級表，雖然會存在大量的空列，但得益於 TDengine 的最佳化，能達到恐怖的 0.01 的壓縮率，簡單計算下來大約需要 3.67GB 每億條。”

業務背景

SENSORO 面向城市基礎設施與核心要素提供全域數字化服務方案，建立城市級感測器網路所涉及的感測器種類十分多樣，由此產生的資料量也十分龐大。在系統開發初期，SENSORO 先是選擇了 Apache Druid 作為儲存感測資料的資料庫，然而在使用過程中卻遇到了各種各樣的問題，這使得其將目光轉移到了 TDengine 上，但因為平臺涉及的特殊資料模型，合作便一直擱置了下來。隨後 TDengine 經過了多個版本迭代，支援了 join 查詢，而 SENSORO 的資料模型也發生了變化，遷移到 TDengine 時不再需要做出很多的系統模組改動，由此雙方的合作也開始快速展開。

架構圖

點選案例檢視更多技術細節

北京智慧建築 x TDengine

“TDengine 幫助我們在邊緣側解決了一個很大的問題，即邊緣儲存的問題。因為很多時候邊緣是佈署在資源比較少的機器上面，甚至是 ARM 的工業盒子上面，在資源使用上非常的苛刻，而現在得益於 TDengine 超強的壓縮演算法，我們使用非常小的儲存空間就儲存了幾千萬資料，壓縮率遠超 1/20，在單機上面佈署一個 TDengine 伺服器就可以輕輕鬆鬆地儲存上億的資料。此外它還擁有超強的計算能力，佔用的資源也非常小，在我們的業務中千萬級資料檢索時間達到了毫秒級，從使用者角度來說產品體驗非常好。”

業務背景

北京智慧建築是北京市在智慧建築和智慧城市領域的創新平臺，同時也是冬奧科技平臺公司、智慧冬奧國家重點專案設計單位和核心實施單位。在邊緣側採集資料儲存方案中，其面臨著在有限的計算資源下，如何實現最高效的資料儲存、分析和計算的問題。經過調研與測試，其最終選擇根據業務需求靈活搭配使用 TDengine 與 SQLite——由 TDengine 處理時序資料，SQLite 處理關係資料，以此更好地實現邊緣側的資料自治。

架構圖

點選案例檢視更多技術細節

交通資料資源管理系統 x TDengine

“所有車輛最新位置資訊的查詢是交通執行監控中的重中之重，最初‘使用何種查詢語句實現高效查詢’是非常困擾我們的一件事，後面在 TDengine 社群團隊的幫助下，我們利用了隱藏欄位名 tbname 和 group by 方法，高效地查詢了車輛的最新定位資訊。在頻繁查詢的情況下，接近六萬輛車的位置資訊，只用了不到 1 秒的查詢時間，簡單而又高效，完全符合我們的業務需求；在資料統計分析上，一個 64 天資料量的表，進行每日資料條數的降維統計，所需時間也不到 1 秒。”

業務背景

為了強化全市交通運輸管理、統籌綜合交通發展、提升交通執行和管理效率，某市級管理單位建立了大交通資料資源管理系統及相關應用 “一圖一庫”。其中“一庫”部分主要內容包括：資料接入、資料儲存、資料共享；“一圖”部分主要內容包括：GIS 資訊及其關聯資料資訊在二維、三維地圖上的形象表達。在資料中臺的建設中，存在大量的時序資料應用場景，其中最為關鍵的就是車輛執行產生的時序資料的儲存與使用。為了實現高效的業務處理， 研發人員決定從 InfluxDB、ClickHouse 和 TDengine 三款時序資料庫（Time Series Database）中進行選型調研，最終憑藉強大的產品力，TDengine 脫穎而出。

架構搭建上的考慮

由於該系統業務開發框架使用的是 Srping 框架，在使用 TAOS-JDBCDriver 進行開發時，可以選擇兩種方式進行資料入庫——JDBC-JNI 方式或者是 JDBC-RESTful 方式。在 TDengine 官網，明確記載了“JDBC-RESTful 效能是 JDBC-JNI 的 50%～90%”，因此，其選擇了 JDBC-JNI 方式進行多執行緒入庫——以資料庫連線池（Hikari、druid）+原生 SQL 執行寫入為主要寫入模式

點選案例檢視更多技術細節

數字政通 x TDengine

“壓縮方面，透過檢視 3 個節點的 Vnode 目錄總大小，可以得知目前資料佔用總量為 8.7GB。而從上述表結構我們也能看出實際入庫資料總量大概為 203GB，經過壓縮後為 8.7GB，壓縮率達到了 4% 左右，大幅節約了儲存成本。在查詢上，對 9 億資料量的超級表使用降取樣查詢，展示裝置指標日月年線，耗時僅僅 0.22 秒。”

業務背景

隨著智慧城市的加速建設，物聯裝置的管理問題凸顯，為此，數字政通研發“城市管理物聯網平臺”對物聯網裝置實行監督，提供各類裝置的實時監測資料及報警資料，進一步滿足各類裝置的資料分析、關聯分析、歷史分析、對比分析等需求。簡單來講就是透過鳥瞰整體資料來發現裝置問題，便於及時派單處理，助力智慧城市管理。面對海量物聯網資料的處理，TDengine 的高效儲存給了數字政通相當大的助力。

架構圖

點選案例檢視更多技術細節

結語

透過上面的幾大案例我們可以看到，在解決海量時序資料處理效率低、處理成本高等問題上，關鍵點就是要選對合適的時序資料庫（Time Series Database），當前市面上時序資料庫產品眾多，在效能提升和降低資源消耗上究竟誰能更勝一籌？如果你也在思考這一問題，那或許《寫入效能：TDengine 最高達到 InfluxDB 的 10.3 倍，TimeScaleDB 的 6.74 倍》、《查詢效能：TDengine 最高達到了 InfluxDB 的 37 倍、TimeScaleDB 的 28.6 倍》這兩篇文章能給到你答案。

如果你的專案中也存在難以調節的資料痛點問題，歡迎新增 小T vx：tdengine1，我們會邀請你加入 TDengine 時序資料交流群，和專業的解決方案架構師點對點溝通，齊心協力攻克資料技術難題。