作為入場較早的時(shí)序數(shù)據(jù)庫產(chǎn)品，OpenTSDB 占據(jù)了一定的先機(jī)，在一些企業(yè)的時(shí)序數(shù)據(jù)場景中被廣泛應(yīng)用，但從實(shí)際效果來看，反饋到性能體現(xiàn)和業(yè)務(wù)需求上，卻遠(yuǎn)沒有想象中那么美好。

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

改造后有大約 80% 左右的指標(biāo)模型放到了 TDengine 中，20% 左右的主數(shù)據(jù)或維表數(shù)據(jù)存放在 MySQL 中。相較于改造前的 80% 指標(biāo)模型存放在 MySQL 中，20% 指標(biāo)數(shù)據(jù)存放在 OpenTSDB 中，結(jié)果剛好進(jìn)行了顛倒，服務(wù)器資源使用情況也有所下降。

改造前后查詢性能對(duì)比如下，TDengine 徹底彌補(bǔ)了 OpenTSDB 無法滿足復(fù)雜查詢場景的缺點(diǎn)：

在應(yīng)用 OpenTSDB 后“踩坑”的企業(yè)，至數(shù)搖光并不是獨(dú)一例，順豐科技、睿信物聯(lián)網(wǎng)同樣遭遇了此類問題。

順豐科技是圍繞 OpenFalcon 搭建的大數(shù)據(jù)監(jiān)控平臺(tái)，但 OpenFalcon 以 rrdtool 作為數(shù)據(jù)存儲(chǔ)，不適合做全量監(jiān)控?cái)?shù)據(jù)的存儲(chǔ)，他們便采用了 OpenTSDB+HBase 作為大數(shù)據(jù)監(jiān)控平臺(tái)全量監(jiān)控?cái)?shù)據(jù)的存儲(chǔ)方案，但隨著平臺(tái)接入數(shù)據(jù)量的增長，在此數(shù)據(jù)庫方案下痛點(diǎn)問題頻發(fā)，包括依賴多、使用成本高和性能不能滿足等問題。

順豐科技采用 4 節(jié)點(diǎn) OpenTSDB + 21 節(jié)點(diǎn) HBase 作為全量監(jiān)控?cái)?shù)據(jù)存儲(chǔ)集群，壓縮后每天仍需要 1.5TB（3副本）左右空間存儲(chǔ)，整體成本較高。在性能上，OpenTSDB 作為全量監(jiān)控?cái)?shù)據(jù)存儲(chǔ)方案，在寫入方面性能基本滿足需求，但是在日常大跨度和高頻次查詢方面已無法滿足要求。一方面，OpenTSDB 查詢返回結(jié)果慢，在時(shí)間跨度比較大的情況下需要十幾秒；另一方面，OpenTSDB 支持的 QPS 較低，隨著用戶規(guī)模的擴(kuò)大穩(wěn)定性受到挑戰(zhàn)，容易引發(fā)系統(tǒng)崩潰導(dǎo)致整個(gè)服務(wù)不可用。

后面通過對(duì) IoTDB、Druid、ClickHouse、TDengine 等時(shí)序數(shù)據(jù)存儲(chǔ)方案進(jìn)行調(diào)研，最終順豐科技選擇將數(shù)據(jù)遷移至 TDengine。完成改造后，大數(shù)據(jù)監(jiān)控平臺(tái)擺脫了對(duì)大數(shù)據(jù)組件的依賴，有效縮短了數(shù)據(jù)處理鏈路，穩(wěn)定性有了極大提升；理想情況下，集群寫入速度最高達(dá)到 90W 條/s 的寫入速度；在使用預(yù)計(jì)算函數(shù)情況下，查詢 p99 都在 0.7 秒以內(nèi)；服務(wù)端物理機(jī)由 21 臺(tái)降至 3 臺(tái)，每日所需存儲(chǔ)空間為 93 GB（2 副本），同等副本下僅為 OpenTSDB+HBase 的約 1/10。

同樣，此前睿信互聯(lián)網(wǎng)也是采用 OpenTSDB 進(jìn)行時(shí)序數(shù)據(jù)的存儲(chǔ)，但由于 OpenTSDB 架構(gòu)復(fù)雜，體量過重，給開發(fā)測試、安裝部署以及運(yùn)維管理等工作帶來了不小的麻煩，隨著業(yè)務(wù)發(fā)展，出現(xiàn)的調(diào)試難、運(yùn)維難、成本高等諸多難題嚴(yán)重影響著工作效率。遷移到 TDengine 后，硬件資源減少到原來的 1/5，效率也有了明顯的提升；開發(fā)人員可以在自己電腦上搭建一套環(huán)境，隨便折騰，不用擔(dān)心跑不起來，也不用擔(dān)心影響別人；在性能測試的時(shí)候，用配置低一些的機(jī)器也沒問題，照樣能做出壓測效果；運(yùn)營監(jiān)控工作也變的更簡單了，只需要對(duì) TDengine 的幾個(gè)進(jìn)程進(jìn)行監(jiān)控……

從這些企業(yè)的親身經(jīng)歷來看，也就不難理解為什么他們會(huì)放棄繼續(xù)使用 OpenTSDB 了。