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

小 T 導讀：興盛優選需要透過實時產生的資料來判斷裝置是否工作、檢測通訊是否延時、觀測 SNMP OID 流量是否正常等，從而保障運維與網路人員及時發現問題並修復。為高效處理各類[時序資料]( https://www.taosdata.com/?zh"時序資料")，保障服務的穩定執行，在對比了 Elasticsearch、InfluxDB 和 [TDengine ]( https://www.taosdata.com/?zh"TDengine ")三款產品之後，他們選擇並落地了 TDengine。

**企業介紹**
湖南興盛優選電子商務有限公司（簡稱興盛優選），總部位於湖南長沙，是一家關注民生的網際網路“新零售”平臺，主要定位是解決家庭消費者的日常需求，提供包括蔬菜水果、肉禽水產、米麵糧油、日用百貨等全品類精選商品。興盛優選依託社群實體便利店，透過“預售+自提”的模式為使用者提供服務，是社群電商中唯一一家估值超過 150 億美金的“獨角獸”。

**業務背景**
為了保證網際網路服務的高效和穩定，我們需要監控公司所有的節點伺服器（包括雲伺服器）、交換機及路由器。我們需要透過實時產生的資料來判斷裝置是否工作、檢測通訊是否延時、觀測 SNMP OID 流量是否正常等，從而保障運維與網路人員及時發現問題並修復。
![](http://img.blog.itpub.net/blog/2022/08/11/5acfdb572cf13227.png?x-oss-process=style/bb)

這類資料是非常典型的時序資料，應該如何高效地處理呢？現在市面上有幾款非常流行的[時序資料庫]( https://www.taosdata.com/?zh"時序資料庫")（Time Series Database）產品。應該如何評估並選擇適合我們業務場景的技術平臺呢？

**產品調研**
針對該業務場景，我們調研瞭如下幾個產品：Elasticsearch、InfluxDB 和 TDengine。具體對比如下。

- Elasticsearch

優點：可以分散式部署，可以無障礙插入，支援任意的欄位型別，查詢速度快。
缺點：只適合記錄日誌且併發資料量不大的情況，對於海量裝置的時序資料寫入有效能問題。

- InfluxDB

優點：支援無模式（Schemaless 寫入），限制較少。
缺點：當面對大批次的資料同時插入或讀取時，記憶體容易被佔滿，導致當機。尤其是其中的輪詢機制，在檢驗過期資料時，記憶體佔用特別大。此外，在讀取資料時，讀出來的是列表，可讀性差，解析比較麻煩。

- TDengine

優點：列式儲存以及“一個裝置一張表”的模型與我們業務場景十分契合。此外，還可以相容我們以前使用 InfluxDB 時所習慣的插入方式，程式碼可讀性強，支援強繫結引數。在執行海量資料的查詢時，響應速度比 InfluxDB 更快。
缺點：Schemeless 的支援還在持續完善之中。
由於該專案未來需要監控我們公司的所有伺服器，平均每臺對應的 OID 會有幾百個，如果每 1-5 秒採集儲存一次，併發資料量會非常大。因此，我們從候選中淘汰了 Elasticsearch。

接下來我們又繼續對比了 InfluxDB 和 TDengine。InfluxDB 單節點效能不足，叢集閉源且效能未知。反觀 TDengine，其叢集功能是開源的，且保留了企業版的部分核心功能。這讓我們可以直接非常深入地瞭解 TDengine 的優劣。從這方面考慮，我們選擇了 TDengine。而且在實際使用中，我們又發現了 TDengine 的一大優勢，其“一個裝置一張表”的模型十分契合我們的實際場景。

**系統架構**
在引入 TDengine 之後，我們的系統架構如下圖所示。
![](http://img.blog.itpub.net/blog/2022/08/11/518e63df8ba8c0d5.png?x-oss-process=style/bb)

在該架構下，前端制定好規則下發（例如：流量閾值，延時閾值），後端看是否需要儲存規則，或檢查規則是否發生變化，然後把規則下發給 ETCD 來做定時任務排程。我們共有三個程式任務，透過 ETCD 管理，定時和各類裝置通訊，根據不同規則分別抓取各自需要的資料：

- SNMP 引擎透過 OID 監控網路裝置各項指標
- TCPing 引擎用於監控伺服器 TCP 埠狀態
- ICMP 引擎重點採集接收或返回資料的時間

這三大類資料採集之後，會經過統一處理，再寫入 TDengine。

我們使用 5 個節點搭建了一套 TDengine 叢集：
![](http://img.blog.itpub.net/blog/2022/08/11/8e077312a11882f4.png?x-oss-process=style/bb)

我們選擇了無模式寫入，在寫入時自動建表，具體寫入方式可參考官網。這樣一來，每一臺伺服器對應的型別都是一張超級表，我們選擇儘量地分表 ，提升查詢速度。圖片
對於 SNMP 型別的超級表來說，每一個子表就是一個 OID。

對於 TCPing 型別，我們按照 TCP 埠來區分子表。

對於 ICMP 型別的超級表，我們以 task_id 和 task_type 作為區分子表的依據：
![](http://img.blog.itpub.net/blog/2022/08/11/bdf549b58d1557e3.jpeg?x-oss-process=style/bb)

目前我們已經儲存了 500 萬張子表，平均算下來裝置上報頻率大概為 3 秒 1 行，總資料量達到了百億級別，而佔用的儲存空間只有 70GB 左右。這應該得益於 TDengine 針對性地使用了列式壓縮，儲存資源佔用很小，壓縮率大概為 8% 左右。TDengine 可以很好地頂住寫入和儲存壓力。而查詢方面，我們會批次查詢部分表的特定時間的值，大部分資料用於實時的監控報警。
![](http://img.blog.itpub.net/blog/2022/08/11/a8b4db44131c0003.jpeg?x-oss-process=style/bb)

**經驗總結**
在使用過程中，花時間相對較多的大概是無模式插入的摸索吧。

對於從 InfluxDB 切換過來的使用者，初期可能會有一些不適應。因為 TDengine 最初並不是按照 Schemaless 來設計的，這個功能是後期加入的，系統最終還是會把無模式轉化成 SQL 再進行寫入，只是簡化了使用者的操作。不過 TDengine 一直在完善相關的生態適配，比如對於大小寫的特殊字元的儲存，完善後設資料管理，收納各種形式的資料型別，也在逐步向 InfluxDB 的自由式寫入靠近。

除此之外，我們也遇到過一個問題，目前 Go 聯結器的查詢 API 暫時不支援將多條 SQL 拼接在一起統一執行。因此我們採取了併發讀取，但效能可能會受到一點影響，期待後續的版本能夠解決。

最後，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)")

興盛優選：時序資料如何高效處理？

相關文章