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

企業(yè)介紹

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

業(yè)務(wù)背景

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

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

產(chǎn)品調(diào)研

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

Elasticsearch

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

InfluxDB

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

TDengine

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

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

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

系統(tǒng)架構(gòu)

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

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

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

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

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

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

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

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

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

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

經(jīng)驗總結(jié)

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

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

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

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