TSDB之KairosDB:Tag对性能的影响测试

  • 时间:
  • 浏览:0
  • 来源:5分3D官方_极速5分排列5

原应kairosdb与opentsdb不同,以下是其生成的真实rowkey:

rowkey=0x73797374656d2e6370752e75736167660 00000015923d3cc00000d6b6169726f735f646f75626c657461676b6b6b6b6b6b6b6b6b6b6b6b6b313d746167767676767676767676767676363a7461676b6b6b6b6b6b6b6b6b6b6b6b6b323d74616776767676767676767676767631313a7461676b6b6b6b6b6b6b6b6b6b6b6b6b333d7461677676767676767676767676763231333a

转成string后

system.cpu.usage____Y#ÓÌ___kairos_doubletagkkkkkkkkkkkkk1=tagvvvvvvvvvvvv6:tagkkkkkkkkkkkkk2=tagvvvvvvvvvvvv11:tagkkkkkkkkkkkkk3=tagvvvvvvvvvvvv213:

还时需看出,对于kairosdb来说,是直接使用字符串相加的方式,生成rowkey的,可是指标名与标签的长度越长,rowkey越长。

结论:建议选则五个以下的标签数

比如地理位置从前的标签,值域是很窄的,不要上千。

但host从前的标签,会随着用户的设备规模增加。

而原应使用某些带时间信息的标签,其值域则随着时间的推移会不断增加

在测试过程中搭建了多个环境,发现cassandra与kairosdb无法在windows平台上充分利用机器性能,通过某些配置,都无法把CPU使用率与RAM提高。

但在linux下无此问题图片,虚拟机里的性能甚至好于windows宿主机。

结论:不还时需!增加标签会牺牲性能

标签个数从3到6,写入性能下降20%,读出性能下降40%。

应谨慎选则标签,当新建某些有用的标签时,也应考虑去除某些无用的标签。

编写有两个 进程,使用不同的tag组合,20进程并发写入与10进程并发读取60 0万笔指标,组合如下:

可是从上述原理还时需看出:

通过阅读kairosdb的源代码还时需发现,其内部内部结构使用了以下代码逻辑:

接收请求的进程,可是简单的把请求收到,并转存到数据桶中

数据桶有个数配置,使用配置项kairosdb.datastore.cassandra.write_buffer_job_queue_size来设置

使用独立的进程,消费数据桶。

可是当数据桶消费失败时(如无法连接到cassandra、java进程池满拒绝任务),无法把消息通知到kairosdb的client,原应client会以为写入是顺利的,老会 不停的写入。

通过修改kairosdb的TelnetServer模块,可实现写入失败时,阻塞client,防止client老会 写入数据,原应数据丢失。

在使用TSDB时,在进行数据建模与项目实施时,都时需考虑怎样设置标签?

按常识标签的数量,对性能是有影响的,可是在怎样平衡“用户统计需求”与“性能”之间,当我们歌词 当我们歌词 当我们歌词 时需进行权衡。

越来越 ,问题图片再次老会 出现了:

kairosdb在防止写入或查询操作时,其过程如下:

结论:有较大的影响

标签值域从60 0做到60 00(扩大60 倍),写入性能下降14%,读出性能下降60 %。

原应与时间有关的属性,其标签值数量老会 会随着运行时长不断增长,原应string_index表会老会 增长。

像某些项目中的日志文件名,就中有 时间属性,因此不应该用来作为标签。