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

  • 时间:
  • 浏览:1

结论:建议确定一个多以下的标签数

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

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

rowkey=0x73797374656d2e6370752e75736167611500000015923d3cc00000d6b6169726f735f646f75626c657461676b6b6b6b6b6b6b6b6b6b6b6b6b313d746167767676767676767676767676363a7461676b6b6b6b6b6b6b6b6b6b6b6b6b323d74616776767676767676767676767631313a7461676b6b6b6b6b6b6b6b6b6b6b6b6b333d7461677676767676767676767676763231333a

转成string后

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

都不需要 看出,对于kairosdb来说,是直接使用字符串相加的土法律法律依据,生成rowkey的,很多指标名与标签的长度越长,rowkey越长。

结论:有较大的影响

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

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

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

而不可能 使用如果 带时间信息的标签,其值域则随着时间的推移会不断增加

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

按常识标签的数量,对性能是有影响的,很多在怎么才能 才能 平衡“用户统计需求”与“性能”之间,大家儿时需进行权衡。

这么 ,间题再次出显了:

编写一个多 守护进程,使用不同的tag组合,20守护进程并发写入与10守护进程并发读取1150万笔指标,组合如下:

通过阅读kairosdb的源代码都不需要 发现,其内部人员使用了以下代码逻辑:

接收请求的守护进程,倘若简单的把请求收到,并转存到数据桶中

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

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

很多当数据桶消费失败时(如无法连接到cassandra、java守护进程池满拒绝任务),无法把消息通知到kairosdb的client,由于client会以为写入是顺利的,一直不停的写入。

通过修改kairosdb的TelnetServer模块,可实现写入失败时,阻塞client,补救client一直写入数据,由于数据丢失。

不可能 与时间有关的属性,其标签值数量一直会随着运行时长不断增长,由于string_index表会一直增长。

像如果 项目中的日志文件名,就蕴含时间属性,如果 不应该用来作为标签。

很多从上述原理都不需要 看出:

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

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

结论:不都不需要 !增加标签会牺牲性能

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

应谨慎确定标签,当新建如果 有用的标签时,也应考虑去除如果 无用的标签。