作為入場較早的時序數據庫產品，OpenTSDB 占據了一定的先機，在一些企業的時序數據場景中被廣泛應(ying)用，但從實際(ji)效果來(lai)看，反(fan)饋(kui)到性(xing)能體現和業(ye)務需(xu)求(qiu)上，卻遠沒(mei)有想象中那么美好。

在至數物聯網平臺至數搖光改造前，數據庫架構就采用了 OpenTSDB + MySQL 結合的方式實現，目標是幫助醫療機構實現有源設備的高效管理、提效降耗，但由于 OpenTSDB 無法滿足復雜查詢場景，因此 80% 的場景指標只能基于 MySQL 數據庫來實現，這樣帶來的問題就是 MySQL 數據庫的數據增長迅速，需要定時做冷熱數據分離及數據庫表維護動作。
對于至數搖光來說，OpenTSDB 作為一個大而全的數據庫，在實際運作中還是稍顯笨重，伴隨著業務需求的不斷迭代及數據量的不斷上漲，其局限性也日益凸顯，系統的架構升級和改造工作日漸迫切。隨后通過一系列調研，至數搖光決定將數據從 OpenTSDB 遷移至更為專業且完全自主研發的國產時序數據庫 TDengine 上。

改造后有(you)大約 80% 左右的指標(biao)(biao)模型(xing)放(fang)(fang)到了 TDengine 中，20% 左右的主數(shu)據或維(wei)表數(shu)據存放(fang)(fang)在(zai) MySQL 中。相較于改造前的 80% 指標(biao)(biao)模型(xing)存放(fang)(fang)在(zai) MySQL 中，20% 指標(biao)(biao)數(shu)據存放(fang)(fang)在(zai) OpenTSDB 中，結果(guo)剛好進行了顛倒，服務器資源使用情況也有(you)所下降。

改(gai)造前后查詢性能對比如下，TDengine 徹底彌補(bu)了 OpenTSDB 無法滿足復雜查詢場景的缺點(dian)：

在應(ying)用 OpenTSDB 后“踩坑”的(de)企業(ye)，至數搖光并不是獨一例，順豐科技、睿信物聯(lian)網(wang)同樣遭遇了此類問題。

順豐科技(ji)是圍繞(rao) OpenFalcon 搭建的(de)大數(shu)(shu)據(ju)監(jian)控(kong)平(ping)(ping)臺，但(dan) OpenFalcon 以 rrdtool 作(zuo)為(wei)數(shu)(shu)據(ju)存儲(chu)，不(bu)適合做(zuo)全(quan)量監(jian)控(kong)數(shu)(shu)據(ju)的(de)存儲(chu)，他們便采用了 OpenTSDB+HBase 作(zuo)為(wei)大數(shu)(shu)據(ju)監(jian)控(kong)平(ping)(ping)臺全(quan)量監(jian)控(kong)數(shu)(shu)據(ju)的(de)存儲(chu)方案，但(dan)隨著平(ping)(ping)臺接入數(shu)(shu)據(ju)量的(de)增長，在(zai)此數(shu)(shu)據(ju)庫方案下(xia)痛(tong)點問題頻發，包(bao)括依賴多、使用成本高(gao)和性(xing)能(neng)不(bu)能(neng)滿足(zu)等問題。

順(shun)豐(feng)科技采用 4 節點 OpenTSDB + 21 節點 HBase 作為全(quan)(quan)量監控數據(ju)存(cun)儲集群，壓縮后每天仍需(xu)(xu)要(yao) 1.5TB（3副本(ben)）左右空(kong)間(jian)存(cun)儲，整(zheng)體成本(ben)較高(gao)。在(zai)性(xing)能上，OpenTSDB 作為全(quan)(quan)量監控數據(ju)存(cun)儲方案，在(zai)寫入方面性(xing)能基本(ben)滿足(zu)需(xu)(xu)求(qiu)(qiu)，但是(shi)在(zai)日常大(da)跨度和高(gao)頻次查(cha)詢方面已無(wu)法滿足(zu)要(yao)求(qiu)(qiu)。一(yi)方面，OpenTSDB 查(cha)詢返回(hui)結(jie)果(guo)慢，在(zai)時(shi)間(jian)跨度比(bi)較大(da)的(de)情況(kuang)下需(xu)(xu)要(yao)十幾秒；另一(yi)方面，OpenTSDB 支持的(de) QPS 較低，隨著用戶規(gui)模的(de)擴大(da)穩定(ding)性(xing)受到(dao)挑戰，容易引發系統崩潰(kui)導致整(zheng)個服(fu)務不可用。

后面通過對 IoTDB、Druid、ClickHouse、TDengine 等時序數(shu)據(ju)(ju)存儲(chu)方案(an)進行調(diao)研，最終順豐科(ke)技選(xuan)擇將數(shu)據(ju)(ju)遷移至(zhi)(zhi) TDengine。完成(cheng)改造后，大(da)數(shu)據(ju)(ju)監控平臺(tai)擺脫了(le)(le)對大(da)數(shu)據(ju)(ju)組件的(de)依(yi)賴(lai)，有(you)效縮短了(le)(le)數(shu)據(ju)(ju)處(chu)理(li)鏈路(lu)，穩定(ding)性有(you)了(le)(le)極大(da)提(ti)升；理(li)想情(qing)(qing)況下(xia)，集群(qun)寫入速(su)度最高達到 90W 條/s 的(de)寫入速(su)度；在使(shi)用預計(ji)算函數(shu)情(qing)(qing)況下(xia)，查詢(xun) p99 都在 0.7 秒(miao)以(yi)內；服(fu)務端物理(li)機(ji)由 21 臺(tai)降至(zhi)(zhi) 3 臺(tai)，每日(ri)所需存儲(chu)空間為 93 GB（2 副本），同等副本下(xia)僅為 OpenTSDB+HBase 的(de)約 1/10。

同(tong)樣(yang)，此前睿信互聯網也(ye)是采用 OpenTSDB 進(jin)行時序數據的存儲，但(dan)由于 OpenTSDB 架構復雜，體量過重，給開發測試(shi)、安裝部(bu)署以(yi)及運(yun)維管理等(deng)工作(zuo)(zuo)帶(dai)來了不(bu)小的麻(ma)煩(fan)，隨著(zhu)業(ye)務發展，出(chu)(chu)現(xian)的調試(shi)難、運(yun)維難、成本高等(deng)諸多難題嚴重影(ying)響著(zhu)工作(zuo)(zuo)效(xiao)率。遷(qian)移(yi)到 TDengine 后(hou)，硬件資源減少到原來的 1/5，效(xiao)率也(ye)有了明顯的提(ti)升；開發人員可以(yi)在自己電腦(nao)上搭建一套環境，隨便折騰，不(bu)用擔心跑(pao)不(bu)起來，也(ye)不(bu)用擔心影(ying)響別人；在性(xing)能(neng)測試(shi)的時候，用配置低一些的機器也(ye)沒問(wen)題，照樣(yang)能(neng)做出(chu)(chu)壓測效(xiao)果；運(yun)營監控工作(zuo)(zuo)也(ye)變(bian)的更(geng)簡(jian)單了，只(zhi)需(xu)要對(dui) TDengine 的幾(ji)個(ge)進(jin)程進(jin)行監控……

從這些(xie)企業(ye)的親身(shen)經歷來看，也就不難理(li)解為什么他們會放棄繼續使用 OpenTSDB 了。