隨著業(yè)務(wù)的不斷發(fā)展，數(shù)據(jù)壓力的不斷增加，越來越多的企業(yè)在數(shù)據(jù)庫的選擇上更加糾結(jié)，也更為慎重。智能制造、能源、金融、汽車等領(lǐng)域的企業(yè)，面對時序大數(shù)據(jù)業(yè)務(wù)場景，也逐漸將選型調(diào)研的目光轉(zhuǎn)移至更為專業(yè)的時序數(shù)據(jù)庫（Time Series Database）之上。

作為一款較為流行的時序數(shù)據(jù)庫，OpenTSDB 主要作為監(jiān)控系統(tǒng)被廣泛使用，一方面能夠存儲和檢索指標(biāo)（metric）數(shù)據(jù)并保存很長時間，另一方面如果需要增加功能也可以添加新指標(biāo)。但是作為眾多企業(yè)選型調(diào)研的 Database 之一，OpenTSDB 真的是一個優(yōu)選方案嗎？一起來看看它的優(yōu)劣勢。

OpenTSDB 是一個開源框架，使用 HBase 作為核心平臺來存儲和檢索所收集的指標(biāo)數(shù)據(jù)，可以靈活地增加指標(biāo)，也可以支持采集上萬臺機(jī)器和上億個數(shù)據(jù)點(diǎn)，具有高可擴(kuò)展性。在時序數(shù)據(jù)庫（TSDB）領(lǐng)域，OpenTSDB 算是入場較早的“玩家”之一，其基于 HBase 的產(chǎn)品模式有利也有弊：在為有 HBase 基礎(chǔ)服務(wù)的企業(yè)降低門檻的同時，過度依賴 HBase，也為其性能、壓縮效果加設(shè)了一個瓶頸。

具體來說，從專業(yè)性角度，其優(yōu)劣勢總結(jié)如下：

優(yōu)勢

• 在數(shù)據(jù)壓縮上，時間戳采用 delta 編碼進(jìn)行壓縮，數(shù)據(jù)值采用 XOR 進(jìn)行壓縮；存儲與計(jì)算解耦，為 IoT 場景海量數(shù)據(jù)、動態(tài)熱點(diǎn)的數(shù)據(jù)特征量身打造，方便按照并發(fā)度和存儲量按需獨(dú)立擴(kuò)容。
• 采用分布式架構(gòu)，支持橫向水平擴(kuò)展。
• 較強(qiáng)的時序數(shù)據(jù)計(jì)算能力，主要體現(xiàn)為：插值，缺失的數(shù)據(jù)點(diǎn)，支持線性插值數(shù)據(jù)補(bǔ)全；降精度，支持預(yù)降精度和實(shí)時降精度計(jì)算，滿足高效查詢需求；空間聚合，支持按照不同的 tag 進(jìn)行空間聚合和分組計(jì)算。

劣勢

• 依賴其他軟件：比如 Gnuplot ，需要提前安裝，版本要求為最小 4.2 最大 4.4。
• 安裝部署較復(fù)雜：因?yàn)榈讓邮腔?HBase 設(shè)計(jì)的，而 HBase 又是建立在 Hadoop 集群之上，所以在部署方面相對復(fù)雜，由此還帶來了后期的維護(hù)成本增加的問題；ZooKeeper 也需要單獨(dú)配置部署。
• 在使用方面，OpenTSDB 不支持 SQL 語言，對于很多用戶來說并不友好，特別是之前使用關(guān)系庫的用戶來講，如果支持 SQL 語言，那學(xué)習(xí)成本會降低很多。
• 支持的函數(shù)相對較少，不支持表連接。
• 使用過程中如遇到問題，尋求幫助的渠道較少，不像國產(chǎn)時序數(shù)據(jù)庫，可以輕松地找到技術(shù)人員協(xié)助支持。

而在企業(yè)的具體實(shí)踐上，隨著實(shí)時數(shù)據(jù)庫業(yè)務(wù)量的攀升，OpenTSDB 的劣勢越來越明顯。很多企業(yè)在使用 OpenTSDB 設(shè)計(jì)和實(shí)現(xiàn)監(jiān)控系統(tǒng)時，因?yàn)槠湓跀?shù)據(jù)存儲上過于依賴 Kafka、Spark 和 HBase 等大數(shù)據(jù)組件，會導(dǎo)致大數(shù)據(jù)處理鏈路越來越長，不僅運(yùn)維和使用成本越來越高，系統(tǒng)的可靠性保障也遭受到了極大挑戰(zhàn)——一旦監(jiān)控系統(tǒng)本身出現(xiàn)漏洞，業(yè)務(wù)系統(tǒng)存在的問題便將難以定位，進(jìn)而就可能會造成巨大的實(shí)際業(yè)務(wù)損失。