導語：得物許多系統和場景都需要做流量的監控和防護，一天就能夠產生數億數據，寫入速度達到萬 TPS ，該數據量級無法用傳統的關系型數據庫處理。在對比了 InfluxDB , OpenTSDB , Cassandra 等時序數據庫（Time-Series Database）的性能后(hou)，最終選擇 TDengine 。

背景

作(zuo)為一家(jia)互聯(lian)網電商公司，得物有(you)許(xu)多系統和場景(jing)都需要做流量的(de)(de)監控和防(fang)護(hu)，所以(yi)在深度定制化(hua)開源流控防(fang)護(hu)組件(jian) Sentinel 時我們加入了許(xu)多功能，幫助(zhu)提升各業務(wu)系統的(de)(de)流控防(fang)護(hu)。

備注：Sentinel組件地址(zhi)：

在開發過程(cheng)中(zhong)，我(wo)(wo)們發現開源版本的(de)(de) Sentinel 不支持流控數據(ju)持久(jiu)化，而(er)我(wo)(wo)們非常(chang)需(xu)要這樣(yang)的(de)(de)功能(neng)：我(wo)(wo)們需(xu)要一款數據(ju)庫(ku)，它能(neng)夠承載大量的(de)(de)流量監控數據(ju)，并能(neng)對數據(ju)進行存儲和高效(xiao)查詢。

目前在(zai)生產(chan)環境中，我們(men)有數百個(ge)業務(wu)系統、數千(qian)臺服務(wu)器接入(ru)了 Sentinel ，如此產(chan)生的(de)(de)流控數據無(wu)(wu)疑非常(chang)龐大(da)。那么(me)對于這個(ge)需(xu)求來說，選(xuan)擇一(yi)款適(shi)合的(de)(de)數據庫無(wu)(wu)疑極(ji)為重要，一(yi)個(ge)好的(de)(de)選(xuan)擇就(jiu)能夠達到事(shi)半功(gong)倍(bei)的(de)(de)效果(guo)。

一、數據庫選型

首先粗略(lve)估(gu)算一下當前數據(ju)量(liang)的理論上限(xian)：

目前生產環境擁有數千 Sentinel Resources ，而 Sentinel 的監控數據時間粒度按照秒來統計，那么一天理論上就能夠產生數億的數據，理論寫入數據的速度也將達到萬 TPS ，而(er)且業務還在快速發展，可以預見(jian)的(de)是(shi)數(shu)據量將會(hui)進(jin)一步爆(bao)炸(zha)，顯(xian)而(er)易(yi)見(jian)這個(ge)數(shu)據量級(ji)是(shi)無法使用傳(chuan)統關系數(shu)據庫的(de)。

因為(wei)(wei)內部有一(yi)(yi)些應用(yong)在使(shi)(shi)用(yong) TiDB ，所以(yi)首先看了(le)一(yi)(yi)下(xia)使(shi)(shi)用(yong) TiDB 的可行性，但很快就放棄(qi)了(le)，畢竟(jing)它作(zuo)為(wei)(wei)一(yi)(yi)款(kuan)分(fen)布式數據(ju)庫，瞄準的完全不是監控數據(ju)這種時序特點非常強的場景。

排除之后(hou)我們就將調研(yan)重心放在了時(shi)序數據庫（Time-Series Database）上。

主流時序數據(ju)庫里面都各(ge)有優(you)缺(que)點(dian)：

• InfluxDB ，可能是應用范圍最廣的時序數據庫，場景也合適；但集群功能需要商業版。
• OpenTSDB ，基于 HBase ，對于目前簡單的需求來說太重了。
• Cassandra ，從找到的幾份對比報告來看性能不太滿足要求。

當準備繼續了解 ClickHouse 時，被同事安利了一款國產物聯網大數據平臺—— TDengine 。

簡單在網(wang)(wang)上了解了一下，發(fa)現風評不(bu)錯(cuo)，社區活躍度也高，后來就到官(guan)網(wang)(wang)上查閱(yue)了 TDengine 和其它數據庫的，發(fa)現從上看也非常優秀。

于是我(wo)們(men)就寫了一個 demo ，簡(jian)單使用(yong)了一下 TDengine Database，整個過程中(zhong)，在清晰的(de)文檔(dang)的(de)幫助之(zhi)下，學習成(cheng)本尚可(ke)，所以我(wo)們(men)最終(zhong)決定使用(yong) TDengine 。

二、數據結構與建模方式數據結構

2.1 數據結構

首先我們看一下 Sentinel 的流(liu)量數據是如何(he)呈現的。

從上圖中(zhong)可以看出，左側是應(ying)用(yong)列表，在每(mei)個(ge)應(ying)用(yong)的(de)(de)菜(cai)單中(zhong)有(you)獨立的(de)(de)監控面板(ban)，在監控面板(ban)中(zhong)又以資源(yuan)的(de)(de)粒度，統計(ji)了所有(you)資源(yuan)的(de)(de)流量數(shu)據(ju)，例如通(tong)過 QPS 、拒(ju)絕 QPS 、響(xiang)應(ying)時間(jian)等。

所以從前端呈現的角度(du)來(lai)看(kan)，數據的唯一(yi)鍵應當(dang)是應用-資源。

然后我(wo)們(men)在(zai)從內部實現(xian)角(jiao)度看(kan)看(kan)數據的(de)結構是怎么樣的(de)。

Sentinel 客戶端(duan)在每臺服務器上統計了所有資源的流量數據(ju)，以(yi)秒的維(wei)度進(jin)行聚(ju)合(he)，再記(ji)錄到本地日(ri)志中(zhong)(zhong)。控(kong)制臺通(tong)過調用客戶端(duan)暴(bao)露的接口，獲取(qu)采集(ji)的流量數據(ju)，再以(yi)服務的維(wei)度，將所有單機的流量數據(ju)進(jin)行聚(ju)合(he)，存(cun)儲在內存(cun)中(zhong)(zhong)。

所以我們需要存儲的數據即是(shi)以應用-資源為唯一屬性落入數據庫中(zhong)的。

2.2 數據建模

TDengine官方文檔中建議的數據建模方式如下：

為充分利用其數據的時序性和其他數據特點，TDengine 要求對每個數據采集點單獨建表。

采用一個數據采集點一張表的方式，能最大程度的保證單個數據采集點的插入和查詢的性能是最優的。

在 TDengine 的設計里，表用來代表一個具體的數據采集點，超級表用來代表一組相同類型的數據采集點集合。當為某個具體數據采集點創建表時，用戶使用超級表的定義做模板，同時指定該具體采集點（表）的標簽值。與傳統的關系型數據庫相比，表（一個數據采集點）是帶有靜態標簽的，而且這些標簽可以事后增加、刪除、修改。

一張超級表包含有多張表，這些表具有相同的時序數據 schema ，但帶有不同的標簽值。

可(ke)以看到(dao)官方(fang)文(wen)檔中(zhong)建(jian)議的(de)(de)(de)數(shu)據(ju)建(jian)模方(fang)式完全契合本(ben)場景的(de)(de)(de)數(shu)據(ju)特點：一(yi)個應(ying)用-資源即(ji)為(wei)一(yi)張(zhang)表(biao)，所(suo)有的(de)(de)(de)應(ying)用-資源放在(zai)一(yi)張(zhang)超級表(biao)中(zhong)以便做聚合查詢。所(suo)以在(zai)表(biao)結構(gou)的(de)(de)(de)設計上(shang)，就(jiu)使用了官方(fang)文(wen)檔推薦的(de)(de)(de)這種方(fang)式。

另外，在標簽的選擇上(shang)，雖然(ran)目前還沒有聚合(he)(he)操作(zuo)的需求(qiu)，但是考慮到(dao)未來的聚合(he)(he)操作(zuo)非常可(ke)能會以應(ying)用的維(wei)度來做，所以我們(men)決定將一些(xie)應(ying)用的信息作(zuo)為標簽記錄在表中。

三、整體架構

目(mu)前的整體(ti)架(jia)構(gou)圖如(ru)上(shang)，各個接入了(le) Sentinel 的業(ye)務系統會向(xiang)控制臺定時發(fa)送心跳請(qing)求維持本機器的健康狀態。

而控制臺會定時輪詢所有機器，拉取 Sentinel 客戶端在業務系統中記錄的監控數據，經過聚合處理后再向 TDengine 集群批量寫入。

由于場景簡(jian)單且(qie)并非作為主要的監(jian)控系(xi)統，且(qie)數(shu)據(ju)目(mu)前是(shi)可以接受少量丟失(shi)，故沒有設計過多的失(shi)敗處理機(ji)制。

四、技術選型

4.1 Connector

在 Connector 選擇上，公司的主要開發語言就是 Java ，相關生態也都更完善，所以很自然地選擇了 JDBC 形式的 Connector 。

另外 JDBC 的性能相較于 HTTP 方式也會更好一些，同時 JDBC 驅動還支持節點不可用時自動切換節點。

唯一不方便的是 JDBC 的方式則會強依賴本地庫函數，需要在(zai)(zai)客戶端(duan)的機器(qi)上(shang)也安(an)裝(zhuang) TDengine ，這樣在(zai)(zai)項目部署階段會稍微麻煩(fan)一些，不過整體來說是利大(da)于弊的。

最近，官方更新了 JDBC-RESTful 的方式，支持了跨平臺功能。由于公(gong)司服務器(qi)的(de)(de)操作系統(tong)都是 Linux ，沒有跨(kua)平臺(tai)的(de)(de)需(xu)求，所以還(huan)是繼續(xu)使用(yong) JDBC-JNI 的(de)(de) Connector 。

4.2 數據庫連接池與 ORM

數據庫連接池及 ORM 框架也選擇了在公司內部主流的 Druid + MyBatis ，根據官網(wang)的 Demo 代碼也能高(gao)效地完(wan)成接入(ru)。不過在(zai) MyBatis 的使(shi)用上，只是在(zai)查詢時(shi)(shi)使(shi)用了 MyBatis ，將 ResultSet 轉為(wei)更方便(bian)處理的實體(ti)，而寫入(ru)數據時(shi)(shi)則沒(mei)有使(shi)用 MyBatis ，為(wei)了方便(bian)所以直(zhi)接在(zai)內存(cun)中(zhong)拼接好 SQL 后進(jin)行執行。

總體來說， TDengine 在適配主流框架方面很友好了，支持了 HikariCP 、 Druid 、 Spring JdbcTemplate 、 MyBatis 等(deng)，并且(qie)根據官網提供的 Demo 能夠很快地實現接入，節省了大量時間，一(yi)些注(zhu)意事項(xiang)文檔中都(dou)有(you)清晰(xi)列出。

4.3 集群搭建

目前(qian) TDengine 集(ji)群(qun)有三個(ge)物理(li)節點，均為 16 核/ 64 G 內(nei)存/ 1 T 存儲。

官方的文檔(dang)寫的還(huan)是非(fei)常詳盡的，直接按(an)照(zhao)文檔(dang)進行傻瓜式操作就可以搭建起(qi) TDengine 集群。

4.4 建庫

在(zai)前期調研(yan)時發(fa)現，假定集(ji)群(qun)只有三(san)臺機器，如(ru)果數(shu)(shu)(shu)據量(liang)(liang)過大(da)，副(fu)(fu)本數(shu)(shu)(shu)為 3 ，相當(dang)于在(zai)每臺機器上都(dou)存(cun)儲了一(yi)份完整數(shu)(shu)(shu)據，以可能的(de)(de)數(shu)(shu)(shu)據量(liang)(liang)推測，存(cun)儲和內存(cun)的(de)(de)壓力(li)都(dou)會較大(da)，所以在(zai)建庫時副(fu)(fu)本數(shu)(shu)(shu)選擇設置為1。后續(xu)若集(ji)群(qun)規模擴大(da)， TDengine 也支持動態(tai)修(xiu)改副(fu)(fu)本數(shu)(shu)(shu)，可以很輕松地完成到高可用集(ji)群(qun)的(de)(de)切換(huan)。

另外考慮到查詢性能，將 blocks 設置為 16 ， cache 設置為 64 MB 。

CREATE DATABASE sentinel KEEP 365 DAYS 1 blocks 16 cache 64;

五、性能表現

目前 TDengine 承載了數(shu)百(bai)億(yi)數(shu)據，在生(sheng)產環境運行(xing)平穩， CPU 使(shi)用率日(ri)常不到 1 % ，內存使(shi)用率穩定在 25 % 以下(xia)。

下圖(tu)為集(ji)群中(zhong)的(de)一臺機器(qi)的(de)監(jian)控圖(tu)表：

在使用早期 TDengine 版(ban)本（2.0.7.0）做調(diao)研(yan)時，內存(cun)(cun)方面是存(cun)(cun)在一(yi)些(xie)缺陷的，但是隨著版(ban)本迭代，目前看(kan)內存(cun)(cun)問(wen)題已經得到了(le)較好的解決。

5.1 寫入性能

控制(zhi)臺的(de)(de)(de)機器配置為(wei)(wei) 4 核(he)(he) 16 G ，批(pi)量寫入線程池(chi)設(she)置的(de)(de)(de)最大核(he)(he)心(xin)線程數(shu)為(wei)(wei) 16 ，數(shu)據庫連接(jie)池(chi)的(de)(de)(de)最大線程數(shu)為(wei)(wei)20，實際(ji)使用(yong)約(yue)14。

寫入流程如下：

對批量寫(xie)入設置的最大寫(xie)入條數(shu)為 400 ，寫(xie)入耗(hao)時(shi)如下：

可以看到，大批量的(de)寫入，耗(hao)時(shi)基本也(ye)能(neng)保持在(zai) 10 ms，屬(shu)于比較理(li)想的(de)范圍。目前還沒(mei)有調整 SQL 語(yu)(yu)句最(zui)大長度(du)，后續(xu)可能(neng)通(tong)過增(zeng)加 SQL 語(yu)(yu)句長度(du)的(de)方式進一步優化寫入性能(neng)。

5.2 查詢性能

以下的耗時均未(wei)包含網絡開(kai)銷等(deng)，數(shu)據來自(zi)在客戶端上進行指定 SQL 語句的查詢(xun)。查詢(xun)的超級(ji)表數(shu)據量級(ji)在百億，以下給出(chu)了幾個典型場景的耗時情況：

• last_row函數：8.6ms 8.8ms 5.6ms

select last_row(*) from stable;

• 查詢單個應用 + 資源某五分鐘的所有數據：3.4ms 3.3ms 3.3ms

select * from table where ts >= '2021-01-01 19:00:00' and ts < '2021-01-01 19:05:00';

• 查詢單個應用 + 資源某三小時內每兩分鐘的平均通過 qps ：1.4ms 1.3ms 1.4ms

select avg(pass_qps) from table where ts >= '2021-01-01 19:00:00' and ts < '2021-01-01 22:00:00' interval (2m);

• 以服務維度分組查詢一天內每兩分鐘的平均通過 qps ：2.34s 2.34s 2.35s

select avg(pass_qps) from stable where ts >= '2021-01-01 00:00:00' and ts < '2021-01-02 00:00:00' interval (2m) group by appid;

值得(de)一(yi)提(ti)的(de)(de)是(shi)，在 2.0.7.0 版本(ben)的(de)(de) TDengine 中進行該查(cha)詢效(xiao)率在十幾秒左右(you)，當時認為是(shi)不(bu)可接受的(de)(de)，經過幾個版本(ben)后優化效(xiao)果顯著；

• 以服務維度分組查詢三天內每一小時的平均通過 qps ：2.17s 2.16s 2.17s

select avg(pass_qps) from stable where ts >= '2021-01-01 00:00:00' and ts < '2021-01-03 00:00:00' interval (60m) group by appid;

不管是在大數據量范圍的聚合查詢，還是指定查(cha)詢(xun)某一小區(qu)間內的(de)全部數(shu)據，查(cha)詢(xun)效率還是非常(chang)優異(yi)的(de)。

并且與(yu)前(qian)期調研(yan)時的數據(ju)相(xiang)比(bi)，新版本的查(cha)詢性能優化了非常多，相(xiang)信(xin)在未來(lai)的版本迭代中，會更(geng)進一步。

5.3 存儲容量

目前 Sentinel 的數(shu)(shu)據(ju)沒有使用副本，全量數(shu)(shu)據(ju)分散在(zai)三(san)臺(tai)機(ji)器中，根據(ju)計(ji)算得知 TDengine 對(dui)于 Sentinel 監控(kong)數(shu)(shu)據(ju)的壓縮率達(da) 10 %，相當可(ke)觀。

六、總結

目前 TDengine 在得物暫時(shi)只(zhi)是作為(wei)一款時(shi)序數據庫(ku)小范圍試點來使用，沒(mei)有用到如(ru)流計算(suan)、內置查詢(xun)函數等一些(xie)高級功能，其(qi)作為(wei)時(shi)序數據庫(ku)的讀寫(xie)性能、存(cun)儲表現都是令人滿意(yi)的。

除此之外在(zai)運維難度和學(xue)習(xi)成本上也是(shi)(shi)意想不到的(de)(de)低，很輕(qing)松(song)就(jiu)能搭(da)好一(yi)套可用的(de)(de)集群，這也是(shi)(shi)非(fei)常(chang)巨大的(de)(de)一(yi)個優(you)勢。另外 TDengine 的(de)(de)版本迭代(dai)非(fei)常(chang)快，一(yi)些在(zai)舊版本遇到的(de)(de)問題很快就(jiu)得到了修復，并且在(zai)性能優(you)化方面效果也是(shi)(shi)十分(fen)顯著。

在調研、使用 TDengine 的這段時間，還有一個很重要的感受就是官方文檔真的非常詳盡，技術部分的文章深入淺出地講解了 TDengine 的技術架構、技術設計等，能夠學(xue)習到(dao)非常多東(dong)西；指南類的文章則步驟清(qing)晰簡單，極(ji)大地降低了學(xue)習成本，讓開發人員能夠很快地完成框架適(shi)配、集群(qun)搭建、SQL編(bian)寫(xie)等。

后續(xu)我們也會持續(xu)跟進(jin) TDengine 的 release notes ，了解(jie)有(you)哪些新 featrue 、優化點、bug fix 等(deng)，在有(you)必要的時候會進(jin)行版本升(sheng)級。

期待(dai) TDengine 的(de)性(xing)能表現和(he)穩(wen)定性(xing)能夠不斷提升，未來也會在其(qi)他合適的(de)業務場(chang)景(jing)中(zhong)作為技術(shu)選型(xing)的(de)備選項之一(yi)，例如(ru)未來可(ke)能不僅需(xu)要(yao)存儲聚合后(hou)的(de)數據(ju)，可(ke)能還需(xu)要(yao)存儲單機維度的(de)流控數據(ju)。

注：本(ben)文數據(ju)基(ji)于 2.0.7.0 和(he) 2.0.12.1 版本(ben)的(de) TDengine 。