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

  • 时间:
  • 浏览:2
  • 来源:uu快3app赚钱_uu快3大小计划注册

好多好多 从上述原理不都可不能能 看出:

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

按常识标签的数量,对性能是有影响的,好多好多 在怎样才能平衡“用户统计需求”与“性能”之间,其他人 不都可不能能 进行权衡。

必须 ,问题图片报告 再次再次出现了:

通过阅读kairosdb的源代码不都可不能能 发现,其组织组织结构使用了以下代码逻辑:

接收请求的系统进程,好多好多 简单的把请求收到,并转存到数据桶中

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

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

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

通过修改kairosdb的TelnetServer模块,可实现写入失败时,阻塞client,避免client一直写入数据,原因分析分析数据丢失。

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

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

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

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

像其他项目中的日志文件名,就暗含时间属性,好多好多 不应该用来作为标签。

结论:必须否!增加标签会牺牲性能

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

应谨慎选取标签,当新建其他有用的标签时,也应考虑去除其他无用的标签。

结论:有较大的影响

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

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

rowkey=0x73797374656d2e6370752e7573616761000000015923d3cc00000d6b6169726f735f646f75626c657461676b6b6b6b6b6b6b6b6b6b6b6b6b313d746167767676767676767676767676363a7461676b6b6b6b6b6b6b6b6b6b6b6b6b323d74616776767676767676767676767631313a7461676b6b6b6b6b6b6b6b6b6b6b6b6b333d7461677676767676767676767676763231333a

转成string后

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

不都可不能能 看出,对于kairosdb来说,是直接使用字符串相加的方法,生成rowkey的,好多好多 指标名与标签的长度越长,rowkey越长。

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

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

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

结论:建议选取十个 以下的标签数

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