小 T 導讀：興盛優(yōu)選需要通過實時產生的數據來判斷設備是否工作、檢測通訊是否延時、觀測 SNMP OID 流量是否正常等，從而保障運維與網絡人員及時發(fā)現問題并修復。為高效處理各類時序數據，保障服務的穩(wěn)定運行，在對比了 Elasticsearch、InfluxDB 和 TDengine 三款產品之后，他們選擇并落地了 TDengine。

企業(yè)介紹

湖南興盛優(yōu)選電子商務有限公司（簡稱興盛優(yōu)選），總部位于湖南長沙，是一家關注民生的互聯網“新零售”平臺，主要定位是解決家庭消費者的日常需求，提供包括蔬菜水果、肉禽水產、米面糧油、日用百貨等全品類精選商品。興盛優(yōu)選依托社區(qū)實體便利店，通過“預售+自提”的模式為用戶提供服務，是社區(qū)電商中唯一一家估值超過 150 億美金的“獨角獸”。

業(yè)務背景

為了保證互聯網服務的高效和穩(wěn)定，我們需要監(jiān)控公司所有的節(jié)點服務器（包括云服務器）、交換機及路由器。我們需要通過實時產生的數據來判斷設備是否工作、檢測通訊是否延時、觀測 SNMP OID 流量是否正常等，從而保障運維與網絡人員及時發(fā)現問題并修復。

這類數據是非常典型的時序數據，應該如何高效地處理呢？現在市面上有幾款非常流行的時序數據庫（Time Series Database）產品。應該如何評估并選擇適合我們業(yè)務場景的技術平臺呢？

產品調研

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

Elasticsearch

• 優(yōu)點：可以分布式部署，可以無障礙插入，支持任意的字段類型，查詢速度快。
• 缺點：只適合記錄日志且并發(fā)數據量不大的情況，對于海量設備的時序數據寫入有性能問題。

InfluxDB

• 優(yōu)點：支持無模式（Schemaless 寫入），限制較少。
• 缺點：當面對大批量的數據同時插入或讀取時，內存容易被占滿，導致死機。尤其是其中的輪詢機制，在檢驗過期數據時，內存占用特別大。此外，在讀取數據時，讀出來的是列表，可讀性差，解析比較麻煩。

TDengine

• 優(yōu)點：列式存儲以及“一個設備一張表”的模型與我們業(yè)務場景十分契合。此外，還可以兼容我們以前使用 InfluxDB 時所習慣的插入方式，代碼可讀性強，支持強綁定參數。在執(zhí)行海量數據的查詢時，響應速度比 InfluxDB 更快。
• 缺點：Schemeless 的支持還在持續(xù)完善之中。

由于該項目未來需要監(jiān)控我們公司的所有服務器，平均每臺對應的 OID 會有幾百個，如果每 1-5 秒采集存儲一次，并發(fā)數據量會非常大。因此，我們從候選中淘汰了 Elasticsearch。

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

系統(tǒng)架構

在引入 TDengine 之后，我們的系統(tǒng)架構如下圖所示。

在該架構下，前端制定好規(guī)則下發(fā)（例如：流量閾值，延時閾值），后端看是否需要存儲規(guī)則，或檢查規(guī)則是否發(fā)生變化，然后把規(guī)則下發(fā)給 ETCD 來做定時任務調度。我們共有三個程序任務，通過 ETCD 管理，定時和各類設備通信，根據不同規(guī)則分別抓取各自需要的數據：

• SNMP 引擎通過 OID 監(jiān)控網絡設備各項指標
• TCPing 引擎用于監(jiān)控服務器 TCP 端口狀態(tài)
• ICMP 引擎重點采集接收或返回數據的時間

這三大類數據采集之后，會經過統(tǒng)一處理，再寫入 TDengine。

我們使用 5 個節(jié)點搭建了一套 TDengine 集群：

我們選擇了無模式寫入，在寫入時自動建表，具體寫入方式可參考官網。這樣一來，每一臺服務器對應的類型都是一張超級表，我們選擇盡量地分表 ，提升查詢速度。

對于 SNMP 類型的超級表來說，每一個子表就是一個 OID。

對于 TCPing 類型，我們按照 TCP 端口來區(qū)分子表。

對于 ICMP 類型的超級表，我們以 task_id 和 task_type 作為區(qū)分子表的依據：

目前我們已經存儲了 500 萬張子表，平均算下來設備上報頻率大概為 3 秒 1 行，總數據量達到了百億級別，而占用的存儲空間只有 70GB 左右。這應該得益于 TDengine 針對性地使用了列式壓縮，存儲資源占用很小，壓縮率大概為 8% 左右。TDengine 可以很好地頂住寫入和存儲壓力。而查詢方面，我們會批量查詢部分表的特定時間的值，大部分數據用于實時的監(jiān)控報警。

經驗總結

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

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

除此之外，我們也遇到過一個問題，目前 Go 連接器的查詢 API 暫時不支持將多條 SQL 拼接在一起統(tǒng)一執(zhí)行。因此我們采取了并發(fā)讀取，但性能可能會受到一點影響，期待后續(xù)的版本能夠解決。

最后，TDengine 的支持團隊相當負責，配合積極，讓我們快速上手了這款輕便易用、性能超高的時序數據庫。目前我們只接入了一部分服務器及設備，后續(xù)我們計劃把公司全國范圍內所有的服務器都接入進來，也會推薦公司更多部門使用。一切順利的話，我們也會考慮包括倉庫運貨機器人，物流線設備等更多應用場景。