作者介紹： 薛超，中移物聯網數據庫運維高級工程師，10年數據庫運維經歷，2017年加入中移物聯網，負責數字化產品部數據庫相關工作，專注于數據庫優化和推動架構演進；近年來主要研究國產新型數據庫，目前所在部門全部業務已經去”O”，在此過程中，積累了大量新型數據庫的運維經驗。

關于中移物聯網

中移物聯網有限公司是中國移動通信集團有限公司出資成立的全資子公司。公司按照中國移動整體戰略布局，圍繞“物聯網業務服務的支撐者、專用模組和芯片的提供者、物聯網專用產品的推動者”的戰略定位，專業化運營物聯網專用網絡，設計生產物聯網專用模組和芯片，打造車聯網、智能家居、智能穿戴等特色產品，開發運營物聯網連接管理平臺OneLink和物聯網開放平臺OneNET，推廣物聯網解決方案，形成了五大方向業務布局和物聯網“云-網-邊-端 ”全方位的體系架構。

業務背景

車聯網是中移物聯網的一個非常典型的場景。在這種場景下，我們需要存儲車聯網設備的軌跡點，還要支持對軌跡進行查詢。

軌跡數據有幾個典型的特點：

• 高頻寫入，每天寫入約兩億條軌跡數據；
• 低頻查詢，通常是由用戶觸發，查詢最近幾天的軌跡；
• 企業用戶有定制軌跡存儲周期的需求；
• 需要考慮雙活容災場景；
• 不針對OLAP需求，數據價值密度低。

存儲系統演進過程

我們的存儲系統也經歷了幾個階段的演進。

最初我們使用Oracle小型機單表分區存儲數據，建立了366個分區，因此也只有一年的存儲容量（按分區來刪除數據）。使用Oracle時，我們按日期分區，查詢的時候帶入1-366的分區數字進行查詢，如果不清理歷史數據，2020.7.21和2021.7.21會在一個分區內，不便于管理。

2017年響應集團去IOE的要求，軌跡數據不能再使用高性能的Oracle，經過研發和運維團隊的調研，決定使用Mycat來搭建MySQL集群。

2019年產品對各個子業務提出了不同存儲周期的要求，面向行業的業務存儲時間要求更長。因此我們按子業務做了拆分，每個子業務使用自己的獨立庫。但是，這個時候Mycat配置復雜、難以管理的問題就開始浮現了。

到了2020年，運維團隊開始調研國產數據庫TiDB，為了驗證TiDB的寫入性能和穩定性，我們開始將軌跡數據同時寫入到TiDB。

2020年10月，我們開始重新考慮軌跡存儲方案。

原有方案的痛點

軌跡服務的Mycat集群方案自2017年上線后已經穩定運行2年多，但是在實際商用過程中，我們還是發現了很多問題：

• 首先是擴容風險，Mycat本身是一個構建在MySQL之上的比較簡單的中間件，并不支持自動擴容；
• 數據刪除比較麻煩，如果每個客戶都要定制自己的存儲年限，很難設計；
• Mycat中間件配置復雜，每個邏輯庫都會有大量復雜的配置；
• 整體方案已經被業內淘汰。

之后我們配合運維團隊在軌跡存儲上嘗試了TiDB，經過幾個月的寫入測試，驗證了TiDB的寫入性能和運行穩定性。

優點：

• 寫入性能強，擴容簡單；
• 支持高可用，災備完善；
• 支持兩地多中心。

問題：

• 要求使用SSD，存儲成本過高，不適合軌跡存儲這種低價值的數據；
• 不能解決行業客戶軌跡數據存儲周期定制化的需要。

我們不妨再來看一下軌跡數據存儲的典型特點：首先是軌跡數據寫入量大，每天約2億條軌跡，峰值寫入8000條/秒；其次是企業對數據存儲周期有定制化需求（比如1年、3年或者5年等）；最后還要支持多中心雙活特性。而傳統關系型數據庫很難滿足這些需求。

軌跡數據本身也很有特點：

• 數據只查詢不修改；
• 海量數據寫入；
• 查詢時間主要集中在最近一段時間；
• 無需事務支持；
• 查詢方式簡單，設備之間無關聯，不需要join查詢；
• 客戶希望軌跡存儲時間足夠長。

我們發現，這個特點天然適合時序數據庫。

時序數據庫選型

我們研究了業界比較有代表性的幾款時序數據庫產品。

• InfluxDB：在成都的資源池團隊有實踐，在使用社區版的時候遇到了一些問題，而且該版本不支持集群和高可用。

• Prometheus：雖然也是主流時序數據庫，但是其獨特的拉數據方式并不適合我們的場景，而且其“聯邦”集群的機制高可用存疑。

• TDengine：國產開源的物聯網大數據平臺。

在參考DB-Ranking上的排名數據和部門運維專家的意見后，我們進行了部分調研。發現市場上雖然時序數據庫百花齊放，但是都沒有完美的選擇。在評審會議結束后，大家決定把重點放到TDengine上，發現這款產品意外的很不錯。運維團隊主動出擊，還得到了濤思數據官方的免費技術支持。

TDengine試用初體驗

TDengine部署非常簡單，而且寫入速度極高，接近硬盤的連續寫入性能。TDengine的高效壓縮算法，可以節省大量存儲空間。SQL語法，使用非常簡單。

數據存儲周期的定制化需求，也很容易通過TDengine滿足。

TDengine的存儲效率也非常高，在選型過程中，我們進行了2000萬條數據的模擬測試。下面是MySQL表結構，一共22個字段和一個聯合索引。

下圖是插入2000萬條數據之后，MySQL和TDengine占用的磁盤空間對比情況。

可以發現，在節省存儲空間方面，TDengine的優勢極為明顯。

因此，我們決定將軌跡數據的存儲遷移到TDengine。

庫表設計

在庫表設計上，我們運用了TDengine自動建表的特性，每個終端設備產生的軌跡點位數據在第一次入庫的時候自動創建子表，我們只需要建一個database和一個存儲軌跡的STable就萬事大吉了。

我們使用的STable結構如下：

create stable device_statushis (    pos_time TIMESTAMP,    sample_time TIMESTAMP,    record_time TIMESTAMP,    online_status SMALLINT,    alarm_status SMALLINT,    pos_method SMALLINT,    pos_precision SMALLINT,    pos_longitude DOUBLE,    pos_latitude DOUBLE,    pos_altitude DOUBLE,    pos_speed FLOAT,    pos_direction FLOAT,    acc_forward FLOAT,    acc_side FLOAT,    acc_verticle FLOAT,    rollover_level SMALLINT,    power_voltage FLOAT,    acc_status SMALLINT,    satellite_num SMALLINT    )    tags(        device_id BINARY(32)    ) ;

建表完成之后，我們還要將歷史數據遷移到TDengine中。

我們大約有30T的數據需要從Mycat集群遷移到TDengine，因此我們寫了一個小工具來完成這項任務，只用了2天左右的時間完成了全部遷移。

系統的整體架構如圖所示：

整體性能

在遷移到TDengine之后，性能表現非常不錯：寫入峰值1.2-1.3w/s ;存儲大約只有MySQL的 1/7，查詢性能也很突出，單設備單日查詢在0.1s以內可以返回結果。

未來展望

目前TDengine能夠很好地解決我們的需求。未來我們會嘗試在更多場景下嘗試TDengine，進一步挖掘其潛力。