更新时间:2022-09-13 08:03:27
在使用TSDB时,在进行数据建模与项目实施时,都需要考虑如何设置标签?
按常识标签的数量,对性能是有影响的,所以在如何平衡“用户统计需求”与“性能”之间,我们需要进行权衡。
那么,问题出现了:
结论:不可以!增加标签会牺牲性能
标签个数从3到6,写入性能下降20%,读出性能下降40%。
应谨慎选择标签,当新建一些有用的标签时,也应考虑去除一些无用的标签。
比如地理位置这样的标签,值域是很窄的,不会上千。
但host这样的标签,会随着用户的设备规模增加。
而如果使用一些带时间信息的标签,其值域则随着时间的推移会不断增加
结论:有较大的影响
标签值域从1000做到30000(扩大30倍),写入性能下降14%,读出性能下降30%。
结论:建议选择5个以下的标签数
由于kairosdb与opentsdb不同,以下是其生成的真实rowkey:
rowkey=0x73797374656d2e6370752e7573616765000000015923d3cc00000d6b6169726f735f646f75626c657461676b6b6b6b6b6b6b6b6b6b6b6b6b313d746167767676767676767676767676363a7461676b6b6b6b6b6b6b6b6b6b6b6b6b323d74616776767676767676767676767631313a7461676b6b6b6b6b6b6b6b6b6b6b6b6b333d7461677676767676767676767676763231333a
转成string后
system.cpu.usage____Y#ÓÌ___kairos_doubletagkkkkkkkkkkkkk1=tagvvvvvvvvvvvv6:tagkkkkkkkkkkkkk2=tagvvvvvvvvvvvv11:tagkkkkkkkkkkkkk3=tagvvvvvvvvvvvv213:
可以看出,对于kairosdb来说,是直接使用字符串相加的方式,生成rowkey的,所以指标名与标签的长度越长,rowkey越长。
因为与时间有关的属性,其标签值数量总是会随着运行时长不断增长,导致string_index表会一直增长。
像一些项目中的日志文件名,就含有时间属性,因此不应该用来作为标签。
通过阅读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在处理写入或查询操作时,其过程如下:
所以从上述原理可以看出:
编写一个程序,使用不同的tag组合,20线程并发写入与10线程并发读取3000万笔指标,组合如下:
序号 | 标签数 | 标签组合 | 测试次数 | 写入TPS | 读取TPS | rowkey长度 |
---|---|---|---|---|---|---|
1 | 3 | 1. TagPolicy{key='tagkkkkkkkkkkkkk1', value='tagvvvvvvvvvvvv0~10'} 2. TagPolicy{key='tagkkkkkkkkkkkkk2', value='tagvvvvvvvvvvvv0~30'} 3. TagPolicy{key='tagkkkkkkkkkkkkk3', value='tagvvvvvvvvvvvv0~1000'} |
3 | 33406 | 1.55 | 148 |
2 | 6 | 1. TagPolicy{key='tagkkkkkkkkkkkkk1', value='tagvvvvvvvvvvvv0~10'} 2. TagPolicy{key='tagkkkkkkkkkkkkk2', value='tagvvvvvvvvvvvv0~30'} 3. TagPolicy{key='tagkkkkkkkkkkkkk3', value='tagvvvvvvvvvvvv0~1000'} 4. TagPolicy{key='tagkkkkkkkkkkkkk4', value='tagvvvvvvvvvvvv0~10'} 5. TagPolicy{key='tagkkkkkkkkkkkkk5', value='tagvvvvvvvvvvvv0~10'} 6. TagPolicy{key='tagkkkkkkkkkkkkk6', value='tagvvvvvvvvvvvv0~10'} |
2 | 26860 | 0.95 | 无 |
3 | 9 | 1. TagPolicy{key='tagkkkkkkkkkkkkk1', value='tagvvvvvvvvvvvv0~10'} 2. TagPolicy{key='tagkkkkkkkkkkkkk2', value='tagvvvvvvvvvvvv0~30'} 3. TagPolicy{key='tagkkkkkkkkkkkkk3', value='tagvvvvvvvvvvvv0~1000'} 4. TagPolicy{key='tagkkkkkkkkkkkkk4', value='tagvvvvvvvvvvvv0~10'} 5. TagPolicy{key='tagkkkkkkkkkkkkk5', value='tagvvvvvvvvvvvv0~10'} 6. TagPolicy{key='tagkkkkkkkkkkkkk6', value='tagvvvvvvvvvvvv0~10'} 7. TagPolicy{key='tagkkkkkkkkkkkkk7', value='tagvvvvvvvvvvvv0~10'} 8. TagPolicy{key='tagkkkkkkkkkkkkk8', value='tagvvvvvvvvvvvv0~10'} 9. TagPolicy{key='tagkkkkkkkkkkkkk9', value='tagvvvvvvvvvvvv0~10'} |
1 | 23610 | 0.8 | 364 |
4 | 4 | 1. TagPolicy{key='tagkkkkkkkkkkkkk1', value='tagvvvvvvvvvvvv0~10', uniqure=true} 2. TagPolicy{key='tagkkkkkkkkkkkkk2', value='tagvvvvvvvvvvvv0~30', uniqure=true} 3. TagPolicy{key='tagkkkkkkkkkkkkk3', value='tagvvvvvvvvvvvv0~1000', uniqure=true} 4. TagPolicy{key='tagkkkkkkkkkkkkk4', value='tagvvvvvvvvvvvv0~300000', uniqure=false} |
1 | 26065 | 无 | 无 |
5 | 3 | 1. TagPolicy{key='tagkkkkkkkkkkkkk1', value='tagvvvvvvvvvvvv0~1000', uniqure=true} 2. TagPolicy{key='tagkkkkkkkkkkkkk3', value='tagvvvvvvvvvvvv0~30000', uniqure=false} 3. TagPolicy{key='tagkkkkkkkkkkkkk2', value='tagvvvvvvvvvvvv0~300', uniqure=true} |
1 | 28841 | 1.1 | 154 |