在使用TSDB时，在进行数据建模与项目实施时，都需要考虑如何设置标签？
按常识标签的数量，对性能是有影响的，所以在如何平衡“用户统计需求”与“性能”之间，我们需要进行权衡。
那么，问题出现了：

命题1：是否可以不断增加标签？

结论：不可以！增加标签会牺牲性能
标签个数从3到6，写入性能下降20%，读出性能下降40%。
应谨慎选择标签，当新建一些有用的标签时，也应考虑去除一些无用的标签。

命题2：标签值的值域对KairosDB的性能有多大影响？

比如地理位置这样的标签，值域是很窄的，不会上千。
但host这样的标签，会随着用户的设备规模增加。
而如果使用一些带时间信息的标签，其值域则随着时间的推移会不断增加

结论：有较大的影响
标签值域从1000做到30000（扩大30倍），写入性能下降14%，读出性能下降30%。

命题3：应该选择多少标签较为合适？

结论：建议选择5个以下的标签数

其它总结

总结1：每增加一个标签，rowkey增加标签key=value的字符串长度

由于kairosdb与opentsdb不同，以下是其生成的真实rowkey：
rowkey=0x73797374656d2e6370752e7573616765000000015923d3cc00000d6b6169726f735f646f75626c657461676b6b6b6b6b6b6b6b6b6b6b6b6b313d746167767676767676767676767676363a7461676b6b6b6b6b6b6b6b6b6b6b6b6b323d74616776767676767676767676767631313a7461676b6b6b6b6b6b6b6b6b6b6b6b6b333d7461677676767676767676767676763231333a
转成string后
system.cpu.usage____Y#ÓÌ___kairos_doubletagkkkkkkkkkkkkk1=tagvvvvvvvvvvvv6:tagkkkkkkkkkkkkk2=tagvvvvvvvvvvvv11:tagkkkkkkkkkkkkk3=tagvvvvvvvvvvvv213:
可以看出，对于kairosdb来说，是直接使用字符串相加的方式，生成rowkey的，所以指标名与标签的长度越长，rowkey越长。

总结2：标签与值，应当选择与时间无关的属性

因为与时间有关的属性，其标签值数量总是会随着运行时长不断增长，导致string_index表会一直增长。
像一些项目中的日志文件名，就含有时间属性，因此不应该用来作为标签。

总结3：kairosdb应进行改进，避免write failed无返回值

通过阅读kairosdb的源代码可以发现，其内部使用了以下代码逻辑：
接收请求的线程，只是简单的把请求收到，并转存到数据桶中
数据桶有个数配置，使用配置项kairosdb.datastore.cassandra.write_buffer_job_queue_size来设置
使用独立的线程，消费数据桶。
所以当数据桶消费失败时（如无法连接到cassandra、java线程池满拒绝任务），无法把消息通知到kairosdb的client，导致client会以为写入是顺利的，一直不停的写入。
通过修改kairosdb的TelnetServer模块，可实现写入失败时，阻塞client，避免client一直写入数据，导致数据丢失。

总结4：cassandra与kairosdb在windows平台无法充分利用机器性能

在测试过程中搭建了多个环境，发现cassandra与kairosdb无法在windows平台上充分利用机器性能，通过一些配置，都无法把CPU使用率与RAM提高。
但在linux下无此问题，虚拟机里的性能甚至好于windows宿主机。

总结5：rowkey的查询原理及租户或指标间的影响性

kairosdb在处理写入或查询操作时，其过程如下：
1. 接收查询参数：指标、时间范围、标签范围、汇聚参数
2. 根据“指标与时间范围”，生成rowkey_range_start与rowkey_range_end
3. 向cassandra查询rowkey_range_start与rowkey_range_end间的所有rowkey，生成match1_rowkeys
4. 针对match1_rowkeys进行计算，分析是否包含了“标签范围”中指定的标签，将包含的rowkeys，生成match2_rowkeys
5. 根据match2_rowkeys查询数据，并根据“汇聚参数”进行汇聚与返回
由于上述step3 cassandra可以快速的利用集群能力查询出所在范围段内的rowkey，所以这里的成本很低，最大的成本在于step 4，这里需要大量的数据contains计算。

所以从上述原理可以看出：
1. 指标数量增加，影响非常小，因为step3的成本很低
2. 时间的增加，影响非常小，因为step3的成本很低
3. 标签组合出来的值域越大，性能越低。因为导致step4的成本较高
测试方案与数据

编写一个程序，使用不同的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 |