業(yè)內(nèi)人應(yīng)該都知道，Time Series Database 是近幾年隨著物聯(lián)網(wǎng)等技術(shù)的發(fā)展才逐漸流行起來的，在此之前，各行各業(yè)的企業(yè)可選的數(shù)據(jù)庫方案都十分有限，以車聯(lián)網(wǎng)企業(yè)為例，行業(yè)中最普遍的選擇就是 MongoDB、HBase 一類的傳統(tǒng)大數(shù)據(jù)解決方案。

但隨著業(yè)務(wù)的發(fā)展，大量的時間序列數(shù)據(jù)產(chǎn)生了，這些企業(yè)或多或少都遭遇了數(shù)據(jù)架構(gòu)危機(jī)，甚至阻礙了業(yè)務(wù)的發(fā)展，不得不考慮進(jìn)行數(shù)據(jù)架構(gòu)的迭代和遷移。下文將從 MySQL、MongoDB、HBase 三個 database 維度列舉企業(yè)案例，進(jìn)行說明。

MySQL

在柳工的工業(yè)車聯(lián)網(wǎng)應(yīng)用 LiuGong iLink 中，由于應(yīng)用層不合理的復(fù)雜查詢和歷史數(shù)據(jù)的高頻寫入，導(dǎo)致 MySQL 處理速度緩慢，甚至容易宕機(jī)，嚴(yán)重影響用戶體驗。在分析原因后，他們得出了一個結(jié)論：關(guān)系型數(shù)據(jù)庫并不適用于存儲海量的時間序列數(shù)據(jù)，在海量數(shù)據(jù)聚合計算、抽稀等業(yè)務(wù)中效率很低。從這個結(jié)論出發(fā)，他們開始針對 Time Series Database 進(jìn)行選型。

由于其業(yè)務(wù)場景與 TDengine 的“一個設(shè)備采集點一張表”的理念十分吻合，且 TDengine 可以支持對大數(shù)據(jù)進(jìn)行聚合和降采樣查詢等操作，能夠經(jīng)有效改善 MySQL 的數(shù)據(jù)痛點問題，又經(jīng)過嚴(yán)謹(jǐn)?shù)恼{(diào)研和測試，最終他們決定遷移至 TDengine。
以一個真實場景看一下遷移效果：在替換 TDengine 之前，該項目每天都有一些業(yè)務(wù)報表需要展示，每一小時需統(tǒng)計一次下一個時區(qū)內(nèi)所有設(shè)備產(chǎn)生的 時間序列數(shù)據(jù)，這個流程在 MySQL 中經(jīng)常需要耗時1小時以上，無法正常執(zhí)行后續(xù)業(yè)務(wù)。而換到 TDengine 后，整個出表流程只需要 10 秒左右。

查詢對比如下圖所示：

參考資料：出表流程從 1 小時到 10 秒，TDengine 在柳工車聯(lián)網(wǎng)應(yīng)用中替換 MySQL

MongoDB & HBase

對于這兩大數(shù)據(jù)庫的應(yīng)用坑點，零跑汽車可以說是相當(dāng)有發(fā)言權(quán)了。作為一家典型的新能源車企，零跑汽車在時間序列數(shù)據(jù)的存儲選擇上一直都是 MongoDB 和 HBase，隨著業(yè)務(wù)的加速擴(kuò)張，出現(xiàn)了寫入速度太慢、支撐成本過高等問題。

用 MongoDB 存儲時間序列數(shù)據(jù)會全部存儲在內(nèi)存中，過高的存儲成本導(dǎo)致只能存儲一段時間內(nèi)的數(shù)據(jù)，且存儲的數(shù)據(jù)格式需要經(jīng)過業(yè)務(wù)組織處理，不僅業(yè)務(wù)變更不靈活，可以做的業(yè)務(wù)也非常有限，而 HBase 本身就是一個很重的數(shù)據(jù)庫，搭建 HBase 需要整套 HDFS 做支撐，使用、運維、人力等成本都很高。

在應(yīng)用 TDengine 進(jìn)行架構(gòu)升級后，壓縮性能直接提升了 10 到 20 倍，降低存儲壓力的同時解決了時間序列數(shù)據(jù)存儲成本高的問題，也解決了以前 HBase 入庫不及時的問題，可以用更少的服務(wù)器資源入庫更多的時間序列數(shù)據(jù)，節(jié)省更多成本。同時業(yè)務(wù)靈活性也有了極大提升，不用再像 MongoDB 一樣，在查詢前還需要根據(jù)業(yè)務(wù)加工出需求數(shù)據(jù)，TDengine 的列式存儲，直接以 SQL 計算即可。

諸多企業(yè)實踐證明，如果你面對的也是時間序列數(shù)據(jù)的處理場景，Time Series Database 才是最正確、最合理的選擇。