OpenTSDB是可擴展的分布式時序數(shù)據(jù)庫,底層依賴HBase。作為基于通用存儲開發(fā)的時序數(shù)據(jù)庫典型代表,起步比較早,在時序市場的認可度相對較高。阿里云智能TSDB高度兼容OpenTSDB協(xié)議,采用自研的索引,數(shù)據(jù)模型,流式聚合等技術手段提供更強大的時序能力。本文從運維管控,功能,成本,性能等方面對比阿里云智能TSDB和OpenTSDB的優(yōu)勢。
背景信息
類別 | 子類別 | OpenTSDB | TSDB |
---|---|---|---|
運維管控 | 服務可用性 | 需自行保障,自行搭建集群,自建組件依賴。 | 99.9% |
數(shù)據(jù)可靠性 | 需自行保障,自行搭建集群,自建組件依賴。 | 99.9999% | |
軟硬件投入 | 數(shù)據(jù)庫服務器成本相對較高。 | 無軟硬件投入,按需付費。 | |
維護成本 | 需招聘專職TSDB DBA人員來維護,花費大量人力成本。 | 托管服務。 | |
部署擴容 | 需硬件采購、機房托管、機器部署等工作,周期較長。 | 即時開通,快速部署,彈性擴容。 | |
依賴組件繁重 | 依賴AysncHBase,HBase等運維成本高。 | 0運維。 | |
配置調優(yōu)參數(shù)繁多 | SALT、連接數(shù),同步刷盤參數(shù),Compaction等等。 | 默認參數(shù)采用最佳實踐。 | |
建表語句 | 需要運維靜態(tài)建表語句。 | 建表語句托管,用戶透明。 | |
監(jiān)控報警體系 | 依賴外部搭建。 | 完整的自監(jiān)控鏈路。 | |
功能 | 數(shù)據(jù)模型 | 單值模型。 | 同時支持多值模型和單值模型。 |
SDK | 開源SDK不支持查詢。 | 健壯穩(wěn)定的Java SDK。 | |
數(shù)據(jù)類型多樣性 | 數(shù)值類型。 | 支持數(shù)值,布爾,字符串等多種數(shù)據(jù)類型。 | |
SQL查詢能力 | 不具備。 | 支持SQL的分析查詢。 | |
管理控制臺 | 內置簡單的圖形展示。 | 支持豐富的詳情展示,數(shù)據(jù)管理等。 | |
中文支持 | 僅支持英文字符。 | 支持英文字符和中文字符。 | |
單一維度(tags 可選擇) | tags是必選參數(shù)。 | tags是可選參數(shù)。 | |
TagKey個數(shù) | 最多8個。 | 可支持16個。 | |
集成能力 | 開源產(chǎn)品,與云產(chǎn)品集成能力弱。 | 同F(xiàn)link,物聯(lián)網(wǎng)平臺無縫對接,生態(tài)豐富。 | |
成本 | 數(shù)據(jù)壓縮 | 通用壓縮,壓縮率低。 | 時序領域專用壓縮,壓縮率高。 |
穩(wěn)定性 | 數(shù)據(jù)讀取 | 讀寫耦合,容易造成連接數(shù)耗盡,讀寫失敗概率大。 | 讀寫線程池分離,易于管理連接,讀寫穩(wěn)健。 |
聚合器 | 內存物化聚合,容易造內存OOM。 | 流式聚合,內存管理粒度細,可控性強。 |
OpenTSDB協(xié)議兼容性
由于阿里云TSDB底層技術架構同OpenTSDB的實現(xiàn)區(qū)別巨大,對于OpenTSDB的一些運維接口不會兼容。比如OpenTSDB的元數(shù)據(jù)管理接口/api/tree, /api/uid等等。根據(jù)OpenTSDB的官網(wǎng)API Endpoints(HTTP API) ,下表列舉了TSDB的兼容程度。
OpenTSDB 協(xié)議API | TSDB是否兼容 |
---|---|
/s | 否 |
/api/aggregators | 是 |
/api/annotation | 否 |
/api/config | 是 |
/api/dropcaches | 否 |
/api/put | 是 |
/api/rollup | 否 |
/api/histogram | 否 |
/api/query | 是 |
/api/query/last | 是 |
/api/search/lookup | 是 |
/api/serializers | 是 |
/api/stats | 是 |
/api/suggest | 是 |
/api/tree | 否 |
/api/uid | 否 |
/api/version | 是 |
除此之外,TSDB提供了一些面向時序更友好的接口。包括
TSDB 自定義協(xié)議API | 描述 |
---|---|
/api/mput | 多值寫入 |
/api/mquery | 多值查詢 |
/api/query/mlast | 多值查詢最新數(shù)據(jù)點 |
/api/dump_meta | 查詢 Tagk 下的 Tagv |
/api/ttl | 設置數(shù)據(jù)時效 |
/api/delete_data | 清理數(shù)據(jù) |
/api/delete_meta | 清理時間線 |
性能對比
測試數(shù)據(jù)說明
這里介紹的是用作測試查詢性能的數(shù)據(jù)集。下面將從Metric、時間線、Value和采集周期四個方面來描述:
metric
固定指定一個metric為m
。
tagkv
前四個tagkv全排列,形成10 * 20 * 100 * 100 = 2000000
條時間線,最后IP對應2000000條時間線從1開始自增。
tag_k | tag_v |
---|---|
zone | z1~z10 |
cluster | c1~c20 |
group | g1~100 |
app | a1~a100 |
ip | ip1~ip2000000 |
value
度量值為[1, 100]區(qū)間內的隨機值
interval
采集周期為 10 秒,持續(xù)攝入 3 小時,總數(shù)據(jù)量為3 * 60 * 60 / 10 * 2000000 = 2,160,000,000
個數(shù)據(jù)點。
統(tǒng)計結果說明
壓測模式如下:
壓測參數(shù) | 參數(shù)值 | 說明 |
---|---|---|
壓測持續(xù)分鐘數(shù) | 3 | |
壓力模式 | 固定 | 不同于階梯和脈沖模式,固定模式不會調節(jié)壓測的并發(fā)量。 |
施壓機數(shù)量 | 5 | |
單臺施壓機 TPS 值 | 1000 | |
獲取 Connection 超時時間(毫秒) | 600000 | |
連接建立超時時間(毫秒) | 600000 | |
請求獲取數(shù)據(jù)超時時間(毫秒) | 600000 | 考慮到大查詢會很耗時,一旦 timeout 可能會導致 TPS 統(tǒng)計誤差。 |
調用方式 | 同步 |
每次測試進行之前均重啟數(shù)據(jù)庫服務,避免之前的測試操作可能還占用資源。同時對測試操作進行預熱,避免未預熱情況下,首次請求的耗時過長,而影響到RT統(tǒng)計的準確性。
測試環(huán)境說明
機型配置
寫入機型:2C8G
查詢機型:64C256G
HBase機型:8C16G * 5
數(shù)據(jù)庫版本
OpenTSDB:2.3.2+HBase 1.5.0.1
TSDB:2.4.2
寫入性能對比
寫入場景列表
數(shù)據(jù)點寫入的壓力由上述壓測配置可得知,5臺壓測機,每臺壓測機設置目標TPS為1000,則可以提供5000 TPS的寫入壓力。同時,為了確保測試的公平性,TSDB和OpenTSDB均使用同步寫入,并開啟落盤功能。其中,為了體現(xiàn)出不同的采集周期(interval),各個場景寫入數(shù)據(jù)點的時間戳(timestamp),都基于某一時刻(base_time),隨著調用次數(shù)(N)的增加而遞增,即可用公式表示為
timestamp = base_time + interval * N
采集周期(秒) | Metric | Tag | |
---|---|---|---|
場景一 | 10 | 一個 | 4tagk * 2500tagv |
場景二 | 10 | 十個 | 4tagk * 2500tagv |
場景三 | 60 | 一個 | 4tagk * 2500tagv |
場景四 | 60 | 十個 | 4tagk * 2500tagv |
TSDB 結果
場景 | TPS | RT(ms) | MinRT | MaxRT | 80%RT | 95%RT | 99%RT |
---|---|---|---|---|---|---|---|
場景一 | 4194.23 | 149.91 | 36.9 | 1808.0 | 210.42 | 239.11 | 250.38 |
場景二 | 4223.09 | 148.4 | 37.2 | 474.22 | 209.74 | 238.32 | 248.52 |
場景三 | 4225.24 | 150.37 | 37.09 | 645.57 | 211.22 | 239.01 | 249.88 |
場景四 | 4227.01 | 148.61 | 37.4 | 888.72 | 209.93 | 238.68 | 249.38 |
OpenTSDB 結果
場景 | TPS | RT(ms) | MinRT | MaxRT | 80%RT | 95%RT | 99%RT |
---|---|---|---|---|---|---|---|
場景一 | 1008.12 | 832.68 | 47.19 | 1310.56 | 1158.44 | 1255.66 | 1283.67 |
場景二 | 1094.4 | 770.82 | 43.64 | 1469.04 | 1078.78 | 1238.06 | 1281.69 |
場景三 | 804.82 | 1047.59 | 132.18 | 1297.71 | 1188.12 | 1269.82 | 1281.32 |
場景四 | 1039.72 | 807.29 | 44.43 | 1421.03 | 1110.46 | 1242.02 | 1281.76 |
性能對比分析
TPS
RT
查詢性能對比
查詢場景列表
數(shù)據(jù)點查詢的壓力,同樣可由上述壓測配置可得知,5 臺壓測機,每臺壓測機設置目標 QPS 為 1000,則可以提供 5000 QPS 的查詢壓力。和寫入不同的是,因為查詢的目標數(shù)據(jù)集相對而言更龐大,如果直接使用 5000 的 QPS 進行壓測,可能會因為查詢隊列滿,出現(xiàn)空跑的情況。因此,為了測試的準確性,這里的 5000 實際上是 QPS 的上限,所有的查詢壓測開始之前,都通過觀察數(shù)據(jù)庫服務端日志和資源消耗情況,確保數(shù)據(jù)庫能正常運作的情況下,進行壓測的。而針對場景五到場景八,這四種涵蓋整個數(shù)據(jù)集的查詢場景,即便將壓測并發(fā)量從 5000 降低到 500、50、5、1 之后,仍然會導致 OpenTSDB 不可用,我們這里使用 N/A 來表示 Not Available 狀態(tài),并在后續(xù)分析圖表中,使用 0 替代表示。
Metric | Tag(tagk,tagv組合) | 時間范圍 | |
---|---|---|---|
場景一 | 一個 | 1個Tag | 5min |
場景二 | 一個 | 10個Tag | 5min |
場景三 | 一個 | 100個Tag | 5min |
場景四 | 一個 | 1000個Tag | 5min |
場景五 | 一個 | 1個Tag | 3hour |
場景六 | 一個 | 10個Tag | 3hour |
場景七 | 一個 | 100個Tag | 3hour |
場景八 | 一個 | 1000個Tag | 3hour |
對應查詢語句
# 5min
{"start":1546272000,"end":1546272300,"queries":[{"aggregator":"count","metric":"m","tags":{"ip":"i1"}}]}
{"start":1546272000,"end":1546272300,"queries":[{"aggregator":"count","metric":"m","tags":{"cluster":"c1","group":"h1","app":"a1"}}]}
{"start":1546272000,"end":1546272300,"queries":[{"aggregator":"count","metric":"m","tags":{"zone":"z1","cluster":"c1","group":"h1"}}]}
{"start":1546272000,"end":1546272300,"queries":[{"aggregator":"count","metric":"m","tags":{"cluster":"c1","group":"h1"}}]}
# 3hour
{"start":1546272000,"end":1546282800,"queries":[{"aggregator":"count","metric":"m","tags":{"ip":"i1"}}]}
{"start":1546272000,"end":1546282800,"queries":[{"aggregator":"count","metric":"m","tags":{"cluster":"c1","group":"h1","app":"a1"}}]}
{"start":1546272000,"end":1546282800,"queries":[{"aggregator":"count","metric":"m","tags":{"zone":"z1","cluster":"c1","group":"h1"}}]}
{"start":1546272000,"end":1546282800,"queries":[{"aggregator":"count","metric":"m","tags":{"cluster":"c1","group":"h1"}}]}
TSDB 結果
場景 | TPS | RT(ms) | MinRT | MaxRT | 80%RT | 95%RT | 99%RT |
---|---|---|---|---|---|---|---|
場景一 | 3831.8 | 44.14 | 36.94 | 416.98 | 44.51 | 46.73 | 75.5 |
場景二 | 1148.22 | 657.77 | 105.96 | 1054.96 | 715.5 | 745.87 | 796.8 |
場景三 | 215.96 | 3522.96 | 557.81 | 4067.14 | 3679.5 | 3786.29 | 3854.57 |
場景四 | 39.37 | 19692.53 | 1784.93 | 22370.1 | - | - | - |
場景五 | 2856.1 | 262.76 | 41.29 | 847.01 | 296.99 | 443.52 | 489.4 |
場景六 | 446.54 | 1684.15 | 67.75 | 2161.85 | 1802.8 | 1898.0 | 1959.02 |
場景七 | 69.25 | 11237.9 | 1873.55 | 12776.56 | 11917.05 | 12133.61 | 12316.79 |
場景八 | 11.76 | 65615.45 | 5742.12 | 86952.76 | - | - | - |
OpenTSDB 結果
場景 | TPS | RT(ms) | MinRT | MaxRT | 80%RT | 95%RT | 99%RT |
---|---|---|---|---|---|---|---|
場景一 | 1.97 | 77842.67 | 10486.16 | 109650.51 | - | - | - |
場景二 | 1.95 | 78062.6 | 12723.96 | 119911.53 | - | - | - |
場景三 | 1.96 | 78865.02 | 15942.89 | 141365.75 | - | - | - |
場景四 | 1.97 | 77331.91 | 7780.02 | 113582.65 | - | - | - |
場景五 | N/A | N/A | N/A | N/A | N/A | N/A | N/A |
場景六 | N/A | N/A | N/A | N/A | N/A | N/A | N/A |
場景七 | N/A | N/A | N/A | N/A | N/A | N/A | N/A |
場景八 | N/A | N/A | N/A | N/A | N/A | N/A | N/A |
性能對比分析
QPS
RT
在高并發(fā)情況下(>500),OpenTSDB幾乎處于不可用狀態(tài),而TSDB仍然可以穩(wěn)定運行。