![](http://img.blog.itpub.net/blog/2022/08/22/2295c9f42c29601f.jpeg?x-oss-process=style/bb)

小 T 導讀：為了更好地支援陽光氫能 PEM 綠電制氫系統，本文作者所在的部門需要尋找一套滿足業務和效能需求、而且具有國產智慧財產權的[時序資料庫]( https://www.taosdata.com/?zh"時序資料庫")，來替代原本使用的 InfluxDB。本文分享了他們將 InfluxDB 替換為 [TDengine]( https://www.taosdata.com/?zh"TDengine") 的具體原因，以及相關的實踐思路。

**企業簡介**
陽光電源成立於 1997 年，專注於逆變器的自主研發與製造。經過二十多年的技術積累，集團逐漸確立在光伏逆變器領域的龍頭地位，打造了風、光、儲、氫的新能源完整格局，做到傳統業務和創新業務雙管齊下、協同發展。

**專案介紹**
在碳中和這個大背景下，氫能是新能源領域中與油氣行業現有業務結合最緊密的一類，也是幫助油氣行業早日實現碳達峰、碳中和的最佳路徑之一。2022 年 7 月 16 日，陽光氫能 200Nm³/h PEM 綠電制氫系統啟運發貨。該套系統採用國內領先的 PEM 電解水制氫技術和 IGBT 制氫電源，工藝複雜，涉及多項國內專利技術。為了更好地監測整體生產流程資料，我們需要尋找一套滿足業務和效能需求，而且具有國產智慧財產權的時序資料庫（[Time Series Database]( https://www.taosdata.com/time-series-database"Time Series Database")），以響應國家信創號召。

**時序資料庫選型之 InfluxDB vs TDengine**
在 InfluxDB 和 TDengine 之間，之所以選擇 TDengine ，其實我很早之前就寫過一篇文章，題目是《[從 InfluxDB 到 TDengine，我們為什麼會做出這個選擇]( https://www.taosdata.com/user-cases/6394.html"從 InfluxDB 到 TDengine，我們為什麼會做出這個選擇")》，在其中表述的比較清楚了。這裡可以再簡單總結一下：

第一，TDengine 超級表和普通表的概念非常契合我們專案的業務場景。此前我們的專案是一個站點一個單元對應多個測點，現在利用超級表-普通表的模型，業務模型會更加清晰。

第二，查詢更具有優勢。在使用老版 InfluxDB 的歷史資料查詢功能時，只要操作稍微頻繁一點（比如選擇一個時間段之後，曲線很久還沒有渲染出來，又去換了一個時間段），就會導致頁面卡死，取不到資料，這時候需要重啟瀏覽器，極度影響客戶體驗。

![](http://img.blog.itpub.net/blog/2022/08/22/783be762066b56df.png?x-oss-process=style/bb)

但是在使用 TDengine 之後，不論是大批次拉取範圍資料，還是使用函式計算，查詢再也沒有出現過瀏覽器卡死的情況。TDengine 拉取單裝置大範圍時間資料查詢的 SQL 以及耗時情況，如以下截圖如下：

![](http://img.blog.itpub.net/blog/2022/08/22/5d2513c963fccd90.png?x-oss-process=style/bb)

![](http://img.blog.itpub.net/blog/2022/08/22/9987b6932d42ef1b.png?x-oss-process=style/bb)

不得不說，這些查詢的效能都十分出色，完全滿足我們的應用場景。

第三，搭建叢集的成本更低廉。眾所周知，InfluxDB 叢集功能是閉源的，如果後續業務發展需要用到叢集時會帶來很大的不便。然而 TDengine 的叢集功能是開源的，且擴充套件方便，因此可以顯著降低運維成本。

最後，從使用者支援的角度來說，選用國外的 Database 有很大的不確定性，但在使用 TDengine 時如果需要支援，就可以直接透過微信/郵箱等工具隨時和技術人員進行交流，更加有效方便。如果對產品效能功能、業務保障要求高的話，就可以隨時升級到企業級的服務。

**TDengine 落地實踐**
在我們的這套系統中應用的 TDengine 版本為 2.4.0.0，主要用於儲存大量裝置產生的時序資料，我們整個專案的智慧化都是基於這些資料展開。採集裝置主要為鹼液迴圈泵、脫氧塔、純水機、電解槽等制氫裝置。

該套制氫系統除 PEM 制氫優勢外，還具有智慧化程度高的特點，採用的智慧控制演算法與可再生能源波動、間歇性特點相契合，兼具高效、經濟、安全、智慧等優勢，適用於制、儲、加一體化制氫專案。在這個過程中，我們會對 TDengine 儲存的裝置資料進行分析計算，最後透過大屏展示以達到實時監控、分析等需求。

![](http://img.blog.itpub.net/blog/2022/08/22/b20a6ebb7a66b8f1.jpeg?x-oss-process=style/bb)

整個業務架構大致如下：以我們自己編寫的 mosbusTCP 驅動，結合數採硬體裝置採集裝置資料，然後透過 JDBC-RESTful 的方式將資料寫入 TDengine。資料採集點總共有 9000 多個，頻率為大概每秒寫入一次。

![](http://img.blog.itpub.net/blog/2022/08/22/1831a836a226ac58.png?x-oss-process=style/bb)

目前單列模型下，最大的超級表已經保留了幾百億行的的資料，當前磁碟佔用 55GB 左右的空間，壓縮比大概在 10-15% 之間。

![](http://img.blog.itpub.net/blog/2022/08/22/a58ee225a537fa3f.png?x-oss-process=style/bb)

![](http://img.blog.itpub.net/blog/2022/08/22/321315c91233c473.png?x-oss-process=style/bb)

**經驗分享**
值得一提的是，TDengine 是根據表來做資料分片的，vnode 就是最小單位，在這種情況下，保證資料量均衡的前提是寫入量均勻，否則如果某些裝置過熱，某些裝置過冷，就會出現某個 vnode 極大，某個 vnode 極小的情況。

這一點在建表之初是需要考慮的，防止時間過久後，資料過於傾斜。具體調整方式可以參考[這篇]( https://www.taosdata.com/engineering/2474.html"這篇")文章。比如，如果初期的裝置熱度比較高的話，就可以調小 minTablesPerVnode，在第一波建表時便把表均勻開到不同 vnode 裡，這樣可以針對性地利用起每個 vnode 有獨立寫入執行緒的特點，充分利用計算資源。（上文中的 vnode 截圖並不是我的寫入不均勻，只是單純的新建表不久還沒有寫入太多資料。）

此外，在我們的使用過程中，也有遇到過一些問題。比如使用超級表的 select * 查詢時，時間跨度比較久的資料返回會有些慢，這跟當前版本的架構有關，一個該類查詢會生成多個子查詢，每個 vnode 的子查詢是在服務端串形處理的，即在一個 vnode 中檢索查詢完畢後再查下一個，最後彙總。解決方案是把時間段拆開成多段，使用多執行緒來查詢。根據 TDengine 的規劃，在後續的 3.x 版本中，此類查詢將會和聚合查詢一樣變成並行處理，查詢效率會大大提升。而其他問題多為配置部署相關，仔細閱讀文件，都可以得到很好的解決。

對於 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)")

從 InfluxDB 到 TDengine，陽光氫能為什麼會做出這個選擇？

相關文章