業內人應該都知道，Time Series Database 是近幾年隨著(zhu)物聯網(wang)等技術的(de)發展才逐(zhu)漸流行(xing)(xing)起來的(de)，在此之(zhi)前，各(ge)行(xing)(xing)各(ge)業(ye)的(de)企業(ye)可(ke)選的(de)數(shu)據(ju)庫(ku)方(fang)案都(dou)十分有限，以(yi)車(che)聯網(wang)企業(ye)為(wei)例，行(xing)(xing)業(ye)中最普遍的(de)選擇就是 MongoDB、HBase 一類(lei)的(de)傳統大數(shu)據(ju)解決方(fang)案。

但隨著業務的發展，大量的時間序列數據產生了，這些(xie)企業或多或少都遭(zao)遇了數(shu)據架(jia)構危(wei)機，甚(shen)至阻礙了業務的發展，不(bu)得(de)不(bu)考慮進(jin)行數(shu)據架(jia)構的迭代(dai)和(he)遷移。下文將從 MySQL、MongoDB、HBase 三(san)個(ge) database 維度(du)列舉(ju)企業案例(li)，進(jin)行說明。

MySQL

在(zai)柳工的(de)(de)工業車(che)聯網應用 LiuGong iLink 中(zhong)，由(you)于(yu)應用層(ceng)不合(he)理(li)的(de)(de)復雜查(cha)詢和歷史數(shu)(shu)據的(de)(de)高頻寫入，導致 MySQL 處理(li)速度緩慢，甚至容易宕機，嚴重影響用戶體(ti)驗。在(zai)分(fen)析原因后(hou)，他們得出(chu)了一個(ge)結論：關系型數(shu)(shu)據庫并(bing)不適(shi)用于(yu)存(cun)儲海量的(de)(de)時間(jian)序列數(shu)(shu)據，在(zai)海量數(shu)(shu)據聚合(he)計算、抽稀等業務中(zhong)效率(lv)很(hen)低(di)。從這個(ge)結論出(chu)發，他們開(kai)始針對 Time Series Database 進行選型。

由于其業務場景與 TDengine 的“一個設備采集點一張表”的理念十分吻合，且 TDengine 可以支持對大數據進行聚合和降采樣查詢等操作，能夠經有效改善 MySQL 的數據痛點問題，又經過嚴謹的調研和測試，最終他們決定遷移至 TDengine。
以一(yi)個(ge)真實場景看一(yi)下(xia)遷移效果(guo)：在(zai)(zai)替(ti)換 TDengine 之前(qian)，該(gai)項目每天(tian)都有(you)一(yi)些業務報表需(xu)要(yao)(yao)展示(shi)，每一(yi)小(xiao)時(shi)需(xu)統計(ji)一(yi)次下(xia)一(yi)個(ge)時(shi)區(qu)內所有(you)設備(bei)產生的 時(shi)間序列數據，這(zhe)個(ge)流(liu)(liu)程在(zai)(zai) MySQL 中(zhong)經(jing)常需(xu)要(yao)(yao)耗(hao)時(shi)1小(xiao)時(shi)以上，無法正常執行后續業務。而(er)換到 TDengine 后，整個(ge)出表流(liu)(liu)程只需(xu)要(yao)(yao) 10 秒(miao)左右。

查詢對比如下圖(tu)所示：

參考資料：出表流程從 1 小時到 10 秒，TDengine 在柳工車聯網應用中替換 MySQL

MongoDB & HBase

對于(yu)這(zhe)兩大數據庫的應用坑點，零(ling)跑汽(qi)車可以說是(shi)相當有發言(yan)權(quan)了。作(zuo)為一(yi)家(jia)典型的新能源車企，零(ling)跑汽(qi)車在時間序列數據的存(cun)儲選(xuan)擇上一(yi)直(zhi)都是(shi) MongoDB 和 HBase，隨著業務(wu)的加速擴張，出現了寫入速度太慢、支撐成本過(guo)高等問題(ti)。

用(yong) MongoDB 存(cun)(cun)(cun)儲(chu)時間序(xu)列數(shu)據會全部存(cun)(cun)(cun)儲(chu)在(zai)內存(cun)(cun)(cun)中，過(guo)高的(de)存(cun)(cun)(cun)儲(chu)成(cheng)本導(dao)致只(zhi)能存(cun)(cun)(cun)儲(chu)一(yi)段時間內的(de)數(shu)據，且存(cun)(cun)(cun)儲(chu)的(de)數(shu)據格式需要經(jing)過(guo)業務組織處理，不僅業務變更不靈活(huo)，可以做的(de)業務也非(fei)常有限(xian)，而 HBase 本身就是一(yi)個很(hen)重的(de)數(shu)據庫，搭(da)建 HBase 需要整套 HDFS 做支撐，使用(yong)、運(yun)維、人力等成(cheng)本都很(hen)高。

在(zai)應用 TDengine 進(jin)行架構升(sheng)級后(hou)，壓縮性能(neng)直(zhi)接提升(sheng)了(le)(le) 10 到 20 倍(bei)，降低存儲壓力的(de)同時(shi)解決了(le)(le)時(shi)間(jian)序(xu)列數據(ju)存儲成本高的(de)問題(ti)，也(ye)解決了(le)(le)以前 HBase 入庫不(bu)及時(shi)的(de)問題(ti)，可以用更少的(de)服務器資(zi)源入庫更多(duo)的(de)時(shi)間(jian)序(xu)列數據(ju)，節省更多(duo)成本。同時(shi)業務靈活性也(ye)有了(le)(le)極大提升(sheng)，不(bu)用再像 MongoDB 一樣(yang)，在(zai)查(cha)詢(xun)前還需(xu)(xu)要根據(ju)業務加工出需(xu)(xu)求(qiu)數據(ju)，TDengine 的(de)列式存儲，直(zhi)接以 SQL 計算即可。

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