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

企業(yè)介紹

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

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

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

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

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

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

Elasticsearch

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

InfluxDB

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

TDengine

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

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

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

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

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

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

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

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

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

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

對(duì)于 SNMP 類型的超級(jí)表來說，每一個(gè)子表就是一個(gè) OID。

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

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

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

經(jīng)驗(yàn)總結(jié)

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

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

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

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