随着 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 時不再需要做出很多的系統子產品改動，由此雙方的合作也開始快速展開。
架構圖
SENSORO 基于 TDengine 助力基層政府打造數字化應用标杆
北京智能建築 x TDengine
“TDengine 幫助我們在邊緣側解決了一個很大的問題，即邊緣存儲的問題。因為很多時候邊緣是布署在資源比較少的機器上面，甚至是 ARM 的工業盒子上面，在資源使用上非常的苛刻，而現在得益于 TDengine 超強的壓縮算法，我們使用非常小的存儲空間就存儲了幾千萬資料，壓縮率遠超 1/20，在單機上面布署一個 TDengine 伺服器就可以輕輕松松地存儲上億的資料。此外它還擁有超強的計算能力，占用的資源也非常小，在我們的業務中千萬級資料檢索時間達到了毫秒級，從使用者角度來說産品體驗非常好。”
業務背景
北京智能建築是北京市在智能建築和智慧城市領域的創新平台，同時也是冬奧科技平台公司、智慧冬奧國家重點項目設計機關和核心實施機關。在邊緣側采集資料存儲方案中，其面臨着在有限的計算資源下，如何實作最高效的資料存儲、分析和計算的問題。經過調研與測試，其最終選擇根據業務需求靈活搭配使用 TDengine 與 SQLite——由 TDengine 處理時序資料，SQLite 處理關系資料，以此更好地實作邊緣側的資料自治。
架構圖
一個伺服器存儲上億資料，TDengine 在北京智能建築邊緣存儲的應用
交通資料資源管理系統 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 執行寫入為主要寫入模式
TDengine 在“一圖一庫”中的應用，助力交通運輸實作資訊化轉型 - TDengine | 濤思資料
數字政通 x TDengine
“壓縮方面，通過檢視 3 個節點的 Vnode 目錄總大小，可以得知目前資料占用總量為 8.7GB。而從上述表結構我們也能看出實際入庫資料總量大概為 203GB，經過壓縮後為 8.7GB，壓縮率達到了 4% 左右，大幅節約了存儲成本。在查詢上，對 9 億資料量的超級表使用降采樣查詢，展示裝置名額日月年線，耗時僅僅 0.22 秒。”
業務背景
随着智慧城市的加速建設，物聯裝置的管理問題凸顯，為此，數字政通研發“城市管理物聯網平台”對物聯網裝置實行監督，提供各類裝置的實時監測資料及報警資料，進一步滿足各類裝置的資料分析、關聯分析、曆史分析、對比分析等需求。簡單來講就是通過鳥瞰整體資料來發現裝置問題，便于及時派單處理，助力智慧城市管理。面對海量物聯網資料的處理，TDengine 的高效存儲給了數字政通相當大的助力。
架構圖
助力 60+ 市區管理建設，TDengine 聯手數字政通打造智慧城市平台
結語
通過上面的幾大案例我們可以看到，在解決海量時序資料處理效率低、處理成本高等問題上，關鍵點就是要選對合适的時序資料庫（Time Series Database），目前市面上時序資料庫産品衆多，在性能提升和降低資源消耗上究竟誰能更勝一籌？如果你也在思考這一問題，那或許寫入性能：TDengine 最高達到 InfluxDB 的 10.3 倍，TimeScaleDB 的 6.74 倍 - TDengine | 濤思資料、查詢性能： TDengine 最高達到了 InfluxDB 的 37 倍、 TimescaleDB 的 28.6 倍 - TDengine | 濤思資料這兩篇文章能給到你答案。