隨著 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 執行寫入為主要寫入模式。
數字政通 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 | 濤思數據這兩篇文章能給到你答案。
