你是否也遇到過這樣的問題？

在設(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)的可靠性保障也出現(xiàn)了更多的挑戰(zhàn)。一旦監(jiān)控系統(tǒng)本身出現(xiàn)漏洞，業(yè)務(wù)系統(tǒng)存在的問題便將難以定位，進(jìn)而就可能會造成巨大的實(shí)際業(yè)務(wù)損失。

此前順豐科技便被以上問題所困擾，他們使用 OpenTSDB 作為全量監(jiān)控?cái)?shù)據(jù)存儲方案，不僅運(yùn)維和使用成本很高，性能上也越來越難以滿足需求——日常大跨度和高頻次查詢方面已經(jīng)無法滿足當(dāng)前業(yè)務(wù)發(fā)展的需求，查詢返回結(jié)果甚至需要十幾秒。此外，隨著用戶量的增加，支持較低 QPS 的 OpenTSDB 非常容易崩潰，一旦崩潰將導(dǎo)致整個服務(wù)都變?yōu)椴豢捎脿顟B(tài)。

順豐科技并不是獨(dú)一例，睿信物聯(lián)網(wǎng)平臺同樣遭遇了此類問題。為了解決這個問題，兩家企業(yè)都開始重新進(jìn)行數(shù)據(jù)庫選型，但為什么最終它們都選擇了 TDengine Database？TDengine 又帶給了它們哪些改變？

以順豐科技為例，他們分別調(diào)研了 IoTDB、Druid、ClickHouse、TDengine 等幾大市面流行的支持時序數(shù)據(jù)處理的產(chǎn)品。

在調(diào)研時發(fā)現(xiàn)，單機(jī)性能不錯的 IoTDB 尚不支持集群模式，單機(jī)模式在容災(zāi)和擴(kuò)展方面無法滿足需求；性能強(qiáng)大的 Druid 卻過于依賴 ZooKeeper 和 Hadoop 作為深度存儲，整體復(fù)雜度較高；性能算是最好的 ClickHouse 卻由于運(yùn)維成本太高擴(kuò)展特別復(fù)雜。最終，性能、成本、運(yùn)維難度都滿足且支持橫向擴(kuò)展的 TDengine 脫穎而出，成為了順豐科技的最佳選項(xiàng)。

改造成功后，順豐科技智慧物流服務(wù)系統(tǒng)發(fā)生了四個顯著變化：

• 在穩(wěn)定性方面，大數(shù)據(jù)監(jiān)控平臺擺脫了對大數(shù)據(jù)組件的依賴，有效縮短了數(shù)據(jù)處理鏈路
• 在寫入方面，理想情況下集群寫入速度最高能達(dá)到 90w 條/s
• 在查詢方面，在使用預(yù)計(jì)算函數(shù)情況下，查詢 p99 都在 0.7 秒以內(nèi)
• 在成本方面，服務(wù)端物理機(jī)由 21 臺降至 3 臺

無獨(dú)有偶，睿信物聯(lián)網(wǎng)平臺也收獲了這些驚喜效果，但是他們還遇到了一個問題，就是如何將歷史數(shù)據(jù)順利遷移，為此他們還自發(fā)做了一個遷移工具。

為了更加方便企業(yè)從 OpenTSDB等產(chǎn)品順利遷移至 TDengine，TDengine 研發(fā)團(tuán)隊(duì)專門開發(fā)了解決方案。

今天的公開課分成了：

1. TDengine 3.0 技術(shù)演進(jìn)規(guī)劃
2. TDengine 技術(shù)內(nèi)幕分享——兼容 OpenTSDB
3. 全面超越OpenTSDB——TDengine 的能力、遷移方案與行業(yè)案例

如上這三部分來多角度、全方位解讀TDengine Database的核心功能與最佳遷移路徑。