你是否也遇到過這樣的問題？
在設計和實現監控系統時，因為在數據存儲上過于依賴 Kafka、Spark 和 HBase 等大數據組件，導致大數據處理鏈路越來越長，不僅運維和使用成本越來越高，系統的可靠性保障也出現了更多的挑戰。一旦監控系統本身出現漏洞，業務系統存在的問題便將難以定位，進而就可能會造成巨大的實際業務損失。
此前順豐科技便被以上問題所困擾，他們使用 OpenTSDB 作為全量監控數據存儲方案，不僅運維和使用成本很高，性能上也越來越難以滿足需求——日常大跨度和高頻次查詢方面已經無法滿足當前業務發展的需求，查詢返回結果甚至需要十幾秒。此外，隨著用戶量的增加，支持較低 QPS 的 OpenTSDB 非常容易崩潰，一旦崩潰將導致整個服務都變為不可用狀態。
順豐科技并不是獨一例，睿信物聯網平臺同樣遭遇了此類問題。為了解決這個問題，兩家企業都開始重新進行數據庫選型，但為什么最終它們都選擇了 TDengine Database？TDengine 又帶給了它們哪些改變？
以順豐科技為例，他們分別調研了 IoTDB、Druid、ClickHouse、TDengine 等幾大市面流行的支持時序數據處理的產品。
在調研時發現，單機性能不錯的 IoTDB 尚不支持集群模式，單機模式在容災和擴展方面無法滿足需求；性能強大的 Druid 卻過于依賴 ZooKeeper 和 Hadoop 作為深度存儲，整體復雜度較高；性能算是最好的 ClickHouse 卻由于運維成本太高擴展特別復雜。最終，性能、成本、運維難度都滿足且支持橫向擴展的 TDengine 脫穎而出，成為了順豐科技的最佳選項。
改造成功后，順豐科技智慧物流服務系統發生了四個顯著變化：
- 在穩定性方面，大數據監控平臺擺脫了對大數據組件的依賴，有效縮短了數據處理鏈路
- 在寫入方面，理想情況下集群寫入速度最高能達到 90w 條/s
- 在查詢方面，在使用預計算函數情況下，查詢 p99 都在 0.7 秒以內
- 在成本方面，服務端物理機由 21 臺降至 3 臺
無獨有偶，睿信物聯網平臺也收獲了這些驚喜效果，但是他們還遇到了一個問題，就是如何將歷史數據順利遷移，為此他們還自發做了一個遷移工具。
為了更加方便企業從 OpenTSDB等產品順利遷移至 TDengine，TDengine 研發團隊專門開發了解決方案。
今天的公開課分成了：
如上這三部分來多角度、全方位解讀TDengine Database的核心功能與最佳遷移路徑。
