作者 ｜ 溫金雄、彭濤、周玉峰

> 小 T 導讀：為了解決廣大新能源汽車車主面臨的充電效率問題，協鑫能科打造了以換電為核心業務的移動能源品牌「協鑫電港」，需要對各種資料流進行科學管理、合理運用與智慧排程，在資料庫的選擇上尤為重要。本文分享了他們對於資料庫架構的搭建思考以及 TDengine 的應用心得。

**企業簡介**

協鑫能源科技股份有限公司（證券簡稱：協鑫能科 002015.SZ） 系協鑫（集團）控股有限公司旗下企業，主營業務為清潔能源運營、移動能源運營以及綜合能源服務。公司傾力打造從清潔能源生產、補能服務到儲能的便捷、經濟、綠色的出行生態圈，為電動化出行提供一體化能源解決方案，致力於成為領先的移動數字能源科技運營商。

**1、業務痛點**

隨著新能源汽車的廣泛普及，補能的效率問題逐漸成為了廣大車主面臨的痛點難題。為了解決此難題，作為一家頭部的新能源公司，協鑫能科創新突破，切入能源服務領域，打造了以換電為核心業務的移動能源解決方案品牌「協鑫電港」。

由於這是一個在全新領域中打造的全新專案，想要獲得成功，需要對各種資料流進行科學管理、合理運用與智慧排程，所以針對該場景，我們一開始便把量級最大的物聯網資料處理方案鎖定在了[時序資料庫]( https://www.taosdata.com/"時序資料庫")（Time Series Database）上，重點對比了 InfluxDB、[OpenTSDB]( https://www.taosdata.com/opentsdb"OpenTSDB") 以及 TDengine。

最終，TDengine 以其獨特而科學的設計和優秀的測試表現成為我們選中的時序資料處理引擎，承擔了使用者車輛資料、電池裝置資料以及換電港工作裝置等的海量資料儲存分析任務，為我們解決了該專案上難度最大的一個環節。最終，我們決定使用 TDengine 2.4.0.10 版本，並在電信的天翼雲上落地了該專案。

**2、架構與搭建**

從流量削峰以及資料安全的角度出發，我們會先透過使用某 MQTT 訊息伺服器把這些不同種類的裝置資料先統一轉發給到 Kafka。其中不同型別的資料，將會分別上傳到不同的 Kafka topic，最後再透過 Java 聯結器把資料寫入 TDengine。具體架構如下圖所示：

![](http://img.blog.itpub.net/blog/2022/07/26/6f0a9074cc795890.png?x-oss-process=style/bb)

在整體架構上，除了 TDengine，也有一些其它資料庫共同支援系統服務，其中 MySQL 負責儲存訂單、流水等需要精細查詢的關係型資料，但由於 MySQL 可以承受的資料量比較有限，為了做一些大表的連線查詢，因此我們也接入了 TiDB，負責分析報表類資料的儲存。

目前接入 TDengine 最主要的入庫資料是車輛感測器（如：車輛里程、經緯度等）以及換電站電池相關的感測器（電池的各種指標）資料。當前共有 55 張超級表，子表數量達到 11 萬張。

**我們當前在 TDengine、TiDB、MySQL 中儲存的資料量比例大概為 6:3:1，僅僅使用了三臺 4C+16G 的伺服器，TDengine 便挑起了整個系統資料儲存的大頭，輕鬆支撐起了我們的服務。**在資料庫的選擇上，我們一直認為不同資料庫之間術業有專攻，不得不承認，TDengine 在儲存引擎上的獨特設計，在降低成本方面的效果十分顯著。

![](http://img.blog.itpub.net/blog/2022/07/26/c044670947fbf1f6.png?x-oss-process=style/bb)

對於 TDengine，我們一開始使用的是單節點，在穩定運營了幾個月後，於今年 3 月完成了動態擴容，發展到了 3 節點叢集模式，把資料庫也升級到了三副本（從圖中可以看出來）。

TDengine 的動態擴充套件非常方便，只要確保一些必要的引數保持一致，就可以直接透過 “create dnode”把新的計算資源加進來。加入後，再透過 “alter database iot replica 3” 這個命令，即可直接線上令資料庫變為 3 副本，從而實現資料的備份及高可用。

![](http://img.blog.itpub.net/blog/2022/07/26/c885de39470a877d.png?x-oss-process=style/bb)

![](http://img.blog.itpub.net/blog/2022/07/26/3a14e0fd483227b7.png?x-oss-process=style/bb)

**3、效果分析**

**當前，我們在 TDengine 中一共儲存了數百億級別的資料量（由於表結構各異，不方便統計，不在本篇文章中展示），儲存空間大概佔用 600GB 左右（200GB*3），CPU 日常使用為 15% 左右，記憶體使用在 20% 左右。**

![](http://img.blog.itpub.net/blog/2022/07/26/81412a51210d4e4c.png?x-oss-process=style/bb)

在查詢方面，在此列舉一些我們常用的 SQL，TDengine 的響應速度都很快，完全可以滿足我們的需求：

`select max(pmk)-min(pmk) from aodong_109 where sid='P42100001' and sd=0 and ts>'2021-12-01 00:00:00'`

![](http://img.blog.itpub.net/blog/2022/07/26/047292e341ca145c.png?x-oss-process=style/bb)

![](http://img.blog.itpub.net/blog/2022/07/26/d37eb91f68c7e2da.jpeg?x-oss-process=style/bb)

`select last(sv),last(st) from aodong_112 where bn='001PB0GM000002B3L0300067';`

![](http://img.blog.itpub.net/blog/2022/07/26/39c76653c7789106.png?x-oss-process=style/bb)

![](http://img.blog.itpub.net/blog/2022/07/26/5ecd7dde6dafe2cd.jpeg?x-oss-process=style/bb)

**4、關於 TDengine 的一些思考**

由於我們業務是 24*7 不間斷運轉 ，所以沒有時間做版本升級。我們首先計劃抽出時間把 TDengine 版本升級到比較新的版本，再做一些碎片重組壓縮的工作來加強查詢效率。此外，我們還計劃使用 Flink 從 TDengine 中讀取資料做流式計算（看到了官方釋出了 Flink 適配 TDengine 的文章）。

隨著業務快速增長，TDengine 叢集儲存的資料量也會越來越大，而資料又需要長期保留，大資料量的運維對於 TDengine 來說將是一個巨大的挑戰。伴隨資料量級的增長，備份、遷移、庫、表的運維都會受到影響，也有可能遇到我們之前沒有經歷過的問題，這就需要 TDengine 叢集實現升級、擴充套件、拆分、維護等運維操作。未來我們希望能積累更多的經驗分享給社群，讓更多的人瞭解 TDengine。

對於 TDengine 未來的發展，我們也有自己的期待：
- 希望能增加動態修改引數功能，減少停機維護次數。
- 實現類似慢 SQL 日誌功能，降低高負載、調優事後分析定位、回溯故障原因。
- 進一步權衡 udp 帶來的好處和導致的各種問題。我們經常連線報錯 Ref is not there ，目前來看在客戶端新增 rpcForceTcp 1  應該是有效的。
- 增強報錯資訊可讀性，很多報錯提示不夠明確，無法快速判斷出具體原因。

總而言之，希望 TDengine 後面越來越好，也希望我們的合作能更上一層樓。

------------

想了解更多 TDengine Database的具體細節，歡迎大家在[GitHub]( https://github.com/taosdata/grafanaplugin"GitHub")上檢視相關原始碼。
[![](http://img.blog.itpub.net/blog/2022/05/11/0fd59db1207fc97f.jpeg?x-oss-process=style/bb)](https://www.taosdata.com/?zh "![](http://img.blog.itpub.net/blog/2022/05/11/0fd59db1207fc97f.jpeg?x-oss-process=style/bb)")

TDengine 落地協鑫能科，數百億資料壓縮至 600GB

相關文章