小 T 導讀：除了(le)(le)要(yao)對幾(ji)千臺(tai)攝像(xiang)頭進(jin)行(xing)數(shu)據采集加(jia)在(zai)(zai)線檢測，蘇州(zhou)大學還有(you) 1500 多(duo)臺(tai)交換機和(he) 4000 多(duo)臺(tai)服務器(qi)，在(zai)(zai)數(shu)據庫的(de)選擇上，它需(xu)要(yao)在(zai)(zai)扛住如(ru)此大量設備(bei) 24 * 7 高頻長期寫(xie)入的(de)同時(shi)，還要(yao)確保(bao)相(xiang)當出(chu)色的(de)查詢(xun)效(xiao)率。從 PostgreSQL 到 TDengine，本(ben)文分享了(le)(le)江蘇縱目在(zai)(zai)面對業務難點時(shi)，在(zai)(zai)數(shu)據庫的(de)選擇、應用和(he)成效(xiao)方面的(de)經(jing)驗。

企業簡介

蘇(su)(su)州大(da)學(xue)（Soochow University），簡稱(cheng)“蘇(su)(su)大(da)”，坐落(luo)于美麗(li)的江蘇(su)(su)省(sheng)蘇(su)(su)州市，是教(jiao)育部與江蘇(su)(su)省(sheng)人民(min)政府共建高(gao)校(xiao)(xiao)，國(guo)家“雙一流”建設高(gao)校(xiao)(xiao)，國(guo)家“211 工(gong)程”、“2011 計(ji)劃”首批入選高(gao)校(xiao)(xiao)，前身是 1900 年創辦(ban)的東吳大(da)學(xue)，是中(zhong)國(guo)最早以(yi)現代大(da)學(xue)學(xue)科體(ti)系舉(ju)辦(ban)的大(da)學(xue)。

項目介紹

作為一所重點高校，蘇州大學具備規模較大的 IT 基礎設施及應用系統，資源壓力大，網絡故障波及用戶數量多。為保障全校系統以及網絡、服務器硬件、操作系統的可用性、可靠性和安全性，學校必須建立規范且全面的運維管理體系。在此背景下，我們江蘇縱目與蘇州大學與開展技術合作，打造了蘇州大學智慧運維管理平臺。

該(gai)業務(wu)場景(jing)面(mian)臨著以下(xia)難點：

• 資源設備類型、品牌、版本繁雜，各廠商協議區別大，人員經驗無法全覆蓋，原廠難以及時響應。
• 業務應用、服務與資源的關聯關系復雜，問題定位時間遠超過解決問題的時間。
• 缺乏事前運維的有效工具，系統網絡異常會波及各部門/院系師生的教學工作的開展，被動處理負擔重，導致業務部門投訴。

海量設備數據的存儲和查詢問題首當其沖

對(dui)(dui)于這樣一個(ge)規模較大的(de)(de) IT 基(ji)礎設(she)施及應(ying)用系統來說，解決問(wen)題(ti)(ti)本身并不難，難的(de)(de)是如(ru)何高效地處(chu)理(li)小問(wen)題(ti)(ti)、科(ke)學地預防大問(wen)題(ti)(ti)、迅速地定位問(wen)題(ti)(ti)的(de)(de)根(gen)本原因。就從監控數(shu)(shu)據層面來說，如(ru)果想對(dui)(dui)設(she)備(bei)進(jin)行 24 * 7 不間斷監控的(de)(de)話，那么海量的(de)(de)設(she)備(bei)數(shu)(shu)據存儲和查詢對(dui)(dui)于 Database 的(de)(de)壓(ya)力將會(hui)非常(chang)大。

蘇州大學(xue)有(you)幾千臺攝(she)像頭(tou)，光攝(she)像頭(tou)的(de)數(shu)(shu)據采集加(jia)在線檢測(ce)的(de)數(shu)(shu)據量就已經(jing)很大了(le)，更別提(ti)還(huan)有(you) 1500 多臺交換(huan)機、4000 多臺服務器，在數(shu)(shu)據庫(ku)的(de)選擇(ze)上，它需(xu)要(yao)在扛住如(ru)此大量設備(bei) 24 * 7 高頻長(chang)期(qi)寫入的(de)同(tong)時(shi)，還(huan)要(yao)確保相當出(chu)色(se)的(de)查詢效率。

此前，我們使用的(de)是 PostgreSQL 數據(ju)庫單(dan)機版，由于是關系型數據(ju)庫（Relational Database），在該時序數據(ju)的(de)場(chang)景下(xia)數達到億級數據(ju)量時，查詢分析延遲會達到大幾秒，壓(ya)縮率上(shang)也不(bu)太理(li)想(xiang)（后(hou)文會有實(shi)際對比(bi)），無法撐(cheng)起一個(ge)全(quan)域一體化運維監(jian)控平(ping)臺的(de)持(chi)續運行(xing)。

數據的存儲與讀寫是一切業務的根基，因此數據庫選型這個環節尤為重要。早在此前，我們就針對此類業務對時序數據庫（Time Series Database）做了充分的(de)調研(yan)與實(shi)測(ce)。其(qi)中 TDengine 作為一個(ge)專(zhuan)為物聯(lian)網、車(che)聯(lian)網、工業互(hu)聯(lian)網、運維監(jian)測(ce)等優化而設(she)計的(de)時(shi)序數(shu)據庫，十分契合(he)該場景。最終我們選擇將 TDengine 集成到我們自研(yan)且專(zhuan)用于監(jian)控時(shi)序數(shu)據的(de) Argus 平臺中 。

實際應用與效果分析

其實，從 2020 年開始(shi)，我(wo)們(men)就開始(shi)關注(zhu)和接(jie)觸 TDengine 了，很(hen)開心最終修成了正果，在使用 TDengine 對 Argus 平臺進(jin)行(xing)全(quan)面升級后，不管是(shi)查詢(xun)效率、分析性能還是(shi)磁盤占用，都(dou)得(de)到了質的提(ti)升。

在將(jiang) TDengine 作為平臺時(shi)序數(shu)據永久存儲之后，各項(xiang)功(gong)能都符(fu)合(he)甚(shen)至超(chao)出了我們的預期：

落腳到實踐上，我們是在一臺 4C 16G 機械硬盤規格的服務器上落地了該項目，使用單列模型建表，針對每個數據類型的指標都創建一個子表，并用一個超級表來統一管理。當前，子表數量已經達到四十多萬張，輕松達成了數十萬級指標的實時監控。

在寫入層面，由于各個設備采集頻率不太一樣，每秒鐘大概寫入 6000 多行，這對于 TDengine 來說毫無壓力，我們通過官方測試工具 taosBenchmark，在自己的虛擬機上都能跑出每秒寫出數百萬測點的成績。

目(mu)前，我們(men)的數(shu)據存儲(chu)周(zhou)期（keep 7天）為一周(zhou)，TDengine 所(suo)包含的數(shu)據量如下： 

以下為用作對比的(de) PostgreSQL 中的(de)數據量。

可以看到，TDengine 存儲的大概 2 億行數據，實際占用存儲空間不過 2 GB。（注：Vnode2 是 log 庫所占用的空間，即 TDengine 用于內部監控而自帶的數據庫），比起 PostgreSQL 占用的超過 200GB 的空間，幾乎可以忽略不計。

在查詢上也是一樣，針對性能詳情頁的指標查詢，PostgreSQL 的很多查詢都需要幾秒返回結果，而TDengine 都是毫秒級別。

寫在最后

當下，由于(yu)我(wo)們(men)的重點(dian)業(ye)務是實時(shi)監(jian)(jian)控，所以(yi)對歷史數據還沒(mei)有那么高(gao)的安全優先級，但后續業(ye)務會涉(she)及到對此前的監(jian)(jian)控進行(xing)復盤，我(wo)們(men)將會升級到 TDengine 集群版(ban)來(lai)(lai)確保數據的高(gao)可用。總而言之，從當前的應(ying)用情況來(lai)(lai)看，TDengine 適(shi)配非常(chang)順(shun)利，為我(wo)們(men)的系統提供了非常(chang)大的助(zhu)力(li)。