全部产品
云市场

相比OpenTSDB优势

更新时间:2019-05-05 10:56:44

OpenTSDB是可扩展的分布式时序数据库,底层依赖HBase。作为基于通用存储开发的时序数据库典型代表,起步比较早,在时序市场的认可度相对较高。阿里云智能TSDB高度兼容OpenTSDB协议,采用自研的索引,数据模型,流式聚合等技术手段提供更强大的时序能力。本文从运维管控,功能,成本,性能等方面对比阿里云智能TSDB和OpenTSDB的优势。

分类对比

OpenTSDB TSDB
运维管控 服务可用性 需自行保障,自行搭建集群,自建组件依赖 99.9%
数据可靠性 需自行保障,自行搭建集群,自建组件依赖 99.9999%
软硬件投入 数据库服务器成本相对较高 无软硬件投入,按需付费
维护成本 需招聘专职TSDB DBA人员来维护,花费大量人力成本 托管服务
部署扩容 需硬件采购、机房托管、机器部署等工作,周期较长 即时开通,快速部署,弹性扩容
依赖组件繁重, 依赖AysncHBase,HBase等运维成本高 0运维
配置调优参数繁多 SALT、连接数,同步刷盘参数,Compaction等等 默认参数采用最佳实践
建表语句 需要运维静态建表语句 建表语句托管,用户透明
监控报警体系 依赖外部搭建 完整的自监控链路
功能 数据模型 单值模型 同时支持多值模型和单值模型
SDK 开源SDK不支持查询 健壮稳定的Java SDK
数据类型多样性 数值类型 支持数值,布尔,字符串等多种数据类型
SQL查询能力 不具备 支持SQL的分析查询
管理控制台 内置简单的图形展示 支持丰富的详情展示,数据管理,时序洞察等
中文支持 仅支持英文字符 支持英文字符和中文字符
单一维度(tags 可选择) tags是必选参数 tags是可选参数
TagKey个数 最多8个 可支持16个
集成能力 开源产品,与云产品集成能力弱 同Flink,物联网平台无缝对接,生态丰富
成本 数据压缩 通用压缩,压缩率低 时序领域专用压缩,压缩率高
稳定性 数据读取 读写耦合,容易造成连接数耗尽,读写失败概率大 读写线程池分离,易于管理连接,读写稳健
聚合器 内存物化聚合,容易造内存OOM 流式聚合,内存管理粒度细,可控性强

OpenTSDB协议兼容性

由于阿里云TSDB底层技术架构同OpenTSDB的实现区别巨大,对于OpenTSDB的一些运维接口不会兼容。比如OpenTSDB的元数据管理接口/api/tree, /api/uid等等。根据OpenTSDB的官网API Endpoints(http://opentsdb.net/docs/build/html/api_http/index.html) ,下表列举了TSDB的兼容程度。

OpenTSDB 协议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 自定义协议API 描述
/api/mput 多值写入
/api/mquery 多值查询
/api/query/mlast 多值查询最新数据点
/api/dump_meta 查询 Tagk 下的 Tagv
/api/ttl 设置数据时效
/api/delete_data 清理数据
/api/delete_meta 清理时间线

性能对比

测试数据说明

这里介绍的是用作测试查询性能的数据集。下面将从 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] 区间内的随机值

interval

采集周期为 10 秒,持续摄入 3 小时,总数据量为 3 * 60 * 60 / 10 * 2000000 = 2,160,000,000 个数据点。

统计结果说明

压测模式如下:

压测参数 参数值 说明
压测持续分钟数 3
压力模式 固定 不同于阶梯和脉冲模式,固定模式不会调节压测的并发量
施压机数量 5
单台施压机 TPS 值 1000
获取 Connection 超时时间(毫秒) 600000
连接建立超时时间(毫秒) 600000
请求获取数据超时时间(毫秒) 600000 考虑到大查询会很耗时,一旦 timeout 可能会导致 TPS 统计误差
调用方式 同步

每次测试进行之前均重启数据库服务,避免之前的测试操作可能还占用资源。同时对测试操作进行预热,避免未预热情况下,首次请求的耗时过长,而影响到 RT 统计的准确性。

测试环境说明

机型配置

写入机型: 2C8G

查询机型: 64C256G

HBase机型: 8C16G * 5

数据库版本

OpenTSDB: 2.3.2 + HBase 1.5.0.1

TSDB: 2.4.2

写入性能对比

写入场景列表

数据点写入的压力由上述压测配置可得知,5 台压测机,每台压测机设置目标 TPS 为 1000,则可以提供 5000 TPS 的写入压力。同时,为了确保测试的公平性,TSDB 和 OpenTSDB 均使用同步写入,并开启落盘功能。其中,为了体现出不同的采集周期(interval),各个场景写入数据点的时间戳(timestamp),都基于某一时刻(base_time),随着调用次数(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

wqps

RT

wrt

查询性能对比

查询场景列表

数据点查询的压力,同样可由上述压测配置可得知,5 台压测机,每台压测机设置目标 QPS 为 1000,则可以提供 5000 QPS 的查询压力。和写入不同的是,因为查询的目标数据集相对而言更庞大,如果直接使用 5000 的 QPS 进行压测,可能会因为查询队列满,出现空跑的情况。因此,为了测试的准确性,这里的 5000 实际上是 QPS 的上限,所有的查询压测开始之前,都通过观察数据库服务端日志和资源消耗情况,确保数据库能正常运作的情况下,进行压测的。而针对场景五到场景八,这四种涵盖整个数据集的查询场景,即便将压测并发量从 5000 降低到 500、50、5、1 之后,仍然会导致 OpenTSDB 不可用,我们这里使用 N/A 来表示 Not Available 状态,并在后续分析图表中,使用 0 替代表示。

Metric Tagtagktagv组合) 时间范围
场景一 一个 1 个 Tag 5min
场景二 一个 10 个 Tag 5min
场景三 一个 100 个 Tag 5min
场景四 一个 1000 个 Tag 5min
场景五 一个 1 个 Tag 3hour
场景六 一个 10 个 Tag 3hour
场景七 一个 100 个 Tag 3hour
场景八 一个 1000 个 Tag 3hour

对应查询语句

  1. # 5min
  2. {"start":1546272000,"end":1546272300,"queries":[{"aggregator":"count","metric":"m","tags":{"ip":"i1"}}]}
  3. {"start":1546272000,"end":1546272300,"queries":[{"aggregator":"count","metric":"m","tags":{"cluster":"c1","group":"h1","app":"a1"}}]}
  4. {"start":1546272000,"end":1546272300,"queries":[{"aggregator":"count","metric":"m","tags":{"zone":"z1","cluster":"c1","group":"h1"}}]}
  5. {"start":1546272000,"end":1546272300,"queries":[{"aggregator":"count","metric":"m","tags":{"cluster":"c1","group":"h1"}}]}
  6. # 3hour
  7. {"start":1546272000,"end":1546282800,"queries":[{"aggregator":"count","metric":"m","tags":{"ip":"i1"}}]}
  8. {"start":1546272000,"end":1546282800,"queries":[{"aggregator":"count","metric":"m","tags":{"cluster":"c1","group":"h1","app":"a1"}}]}
  9. {"start":1546272000,"end":1546282800,"queries":[{"aggregator":"count","metric":"m","tags":{"zone":"z1","cluster":"c1","group":"h1"}}]}
  10. {"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

rqps

RT

rrt

在高并发情况下(>500),OpenTSDB 几乎处于不可用状态,而 TSDB 仍然可以稳定运行。