在車聯(lián)網場景中，智能車輛會通過各類傳感器定時采集車身狀態(tài)信息，比如行駛速度、發(fā)動機轉速、輪胎壓力值、里程數等，此外，還會由某個事件觸發(fā)產生車輛事件數據，比如門鎖上防、撤防、車輛碰撞、異常移動等，在每次上報數據時都會帶有時間戳，這是非常典型的時序數據場景。在這類場景下，高寫入、高壓縮率、快速查詢是對于數據處理最基本的要求。

但一直以來，在應對車聯(lián)網場景下時序數據的存儲時，企業(yè)大多選擇的都是 MongoDB 或 Apache HBase，這兩大數據庫技術相對更加成熟，在業(yè)務規(guī)模尚未擴張之前，因為設備不多、數據量不大，加上查詢場景單一，尚且可以滿足業(yè)務需求。隨著業(yè)務的加速擴張，寫入速度太慢、支撐成本過高等問題也逐漸顯現。本文將會從四個典型的車聯(lián)網案例出發(fā)，給到你數據架構升級思路。

TDengine x 大疆車載

“在大疆車載當前的云端平臺中，TDengine 的應用不僅節(jié)約了存儲成本和開發(fā)學習成本，同時也表現出了很好的寫入讀取性能，滿足了智能駕駛云端平臺海量時序數據的處理需求。在查詢方面，不管是選擇特定數據的查詢還是輕量的查詢，都是毫秒級返回數據。”

業(yè)務背景

由于當前的智能駕駛業(yè)務還是新的業(yè)務場景，所以大疆車載在選型上的歷史負擔相對較輕。在數據庫選型要求上，從業(yè)務需求出發(fā)，主要聚焦在兩點：首先，結合當下的業(yè)務場景，需要滿足單臺車輛的高頻消息上報頻率；其次，支持在數據量大的時候，通過聚合函數，或選擇函數來快速篩選出需要的數據。此外，對數據庫要求支持集群部署的同時，也要求更低的查詢語句編寫上手難度；而且需支持單表千萬量級，在海量數據并發(fā)場景下，需要有較高的統(tǒng)計報表能力和較好的查詢 SQL 效率。

架構圖

點擊案例查看更多技術細節(jié)

TDengine x 蔚來汽車能源

“在實際效果上，改造完成后，查詢速度提升明顯，從使用 HBase 查詢單設備 24 小時數據的秒級返回，到使用 TDengine 查詢查詢相同數據的毫秒級返回；每天增量數據占用的存儲空間相當于原來使用 HBase 時的 50%；集群計算資源成本相比使用 HBase 節(jié)省超過 60%?！?/p>

業(yè)務背景

為了給用戶提供更好的補能體驗，蔚來能源在加電基礎設施上進行了大量的投入，需要對設備進行更高效的管理——將設備采集數據上報至云端進行存儲，并提供實時數據查詢、歷史數據查詢等業(yè)務服務，用來做設備監(jiān)控和分析。在業(yè)務誕生之初，其用作數據存儲的選型是 MySQL + HBase，MySQL 存儲設備最新實時數據，HBase 存儲設備原始數據。隨著換電站和超充站等設備在全國的快速布局，設備數量持續(xù)增長，積累的數據量越來越多，長時間跨度數據查詢效率出現瓶頸，再加上查詢場景不斷豐富，HBase 已經無法滿足當前業(yè)務需要（具體痛點問題見下方案例鏈接）。

測試結論

采用批量寫入數據方式，調整合適的單批次數據量大小，使用單機部署（8 核 32 GB，500 GB 存儲）默認配置的 TDengine 服務，RESTful API寫入方式，在 4k 并發(fā)流量下寫入沒有問題，同時消費積壓數據時峰值達到 7 k/s，因為單條消息包含信息量太大，實際處理中會拆分為 30 條寫入 TDengine，所以實際寫入 QPS 為 210 k/s，比滿足同樣數據流量的 HBase 集群規(guī)模要小不少，可以節(jié)省成本，再加上 TDengine 本身部署不依賴其他三方軟件，也可以同時節(jié)省運維成本。

架構圖

點擊案例查看更多技術細節(jié)

TDengine x 零跑汽車

“在應用 TDengine 后，不用再像 MongoDB 一樣，在查詢前需要根據業(yè)務加工出需求數據；入庫性能高，解決了以前HBase入庫不及時的問題，可以用更少的服務器資源入庫更多的數據，節(jié)省更多成本。同時，TDengine高壓縮的算法能提升 10 到 20 倍的壓縮性能，降低了存儲壓力和成本?！?/p>

業(yè)務背景

一直以來，在數據存儲上零跑汽車的選擇都是 MongoDB 和 HBase，但是隨著業(yè)務的加速擴張，寫入速度太慢、支撐成本過高等問題也逐漸顯現（具體痛點問題見下方案例鏈接）。從降本增效的角度考慮，零跑決定在 C11 新車型上試用下其他的數據庫，在分析數據特點后，最終確定采用時序數據庫（Time Series Database）。

架構圖

點擊案例查看更多技術細節(jié)

TDengine x 理想汽車

“通過跟濤思官方人員進行深入業(yè)務封閉式測試，TDengine 的功能超出預期，性能比 InfluxDB 要強出許多，兩級存儲架構設計（行存與列存）很棒，TTL 和標簽機制對業(yè)務透明，具備極其優(yōu)秀的高并發(fā)寫入和數據壓縮能力，極大降低了業(yè)務成本和業(yè)務壓力。因此我們決定從 TiDB 遷移至 TDengine。”

業(yè)務背景

在理想汽車的信號上報業(yè)務中，需要將標記時間戳和采集點的信息，通過云端寫入到后端數據庫中，有一定的聚合查詢需求。這是典型的高并發(fā)插入場景，寫多讀少，之前的系統(tǒng)用的是 MongoDB，后來因為 MongoDB 的局限性，其將業(yè)務遷移到了 TiDB，方便進行擴縮容。但在遷移到 TiDB 之后，在目前使用百度云 SSD 虛擬機的情況下，TiDB 集群純寫入性能并不能達到業(yè)務期望預期（HTAP 場景數據庫對純高并發(fā)寫入支持不好，與該業(yè)務場景的適配性不高），需要不斷的資源擴容（具體痛點問題見下方案例鏈接）。

使用成本對照表

點擊案例查看更多技術細節(jié)

寫在最后

隨著業(yè)務的不斷發(fā)展，車聯(lián)網場景下數據量之大難以想象，如果沒有一款能夠實現高效存儲的數據庫，服務器成本會非常的高。術業(yè)有專攻，在合適的時候選擇合適的數據庫是支持業(yè)務發(fā)展的關鍵，從數據處理需求和特點出發(fā)，時序數據庫無疑是最佳選擇。

添加 TDengine 小助手小T，找專業(yè)的解決方案架構師聊一聊