1. 关于 Metrics, value, tag name, tag value

opentsdb的每个时间序列必须有一个metric和一个或多个tag对，每个时间序列每小时的数据保存一行。
opentsdb的metrics, tag name, tag value的编码长度都是3byte, 所以UID的数量上限为 2^24  个。编码长度可以扩展到 8byte，即2^64 个， 一般不建议修改。
tag name和tag value的UID分配是完全独立的，比如tag value的取值为整数2,那么这个值完全可以被多个tag name所使用， cpu=2, interface=2, hdd=2等。
Time Series Cardinality  
这里的Cardinality指：metric的数量。默认 2^24 = 16 million
在设计系统的时候，确保metric,tag name, tag value的Cardinality取值在较小的范围内，如果他们太多了，会影响到查询速度。
注意点： 
Be consistent with your naming to reduce duplication. Always use the same case for metrics, tag names and values.
对每个metric使用相同数目和相同类型的 tag name & tag value. 不要这样使用my.metric host=foo and my.metric datacenter=lga.
根据常用的查询方式，设计优化的schema. 比如常用的tag，放在rowkey组合的前面(metric后)。
Think about how you may want to drill down when querying。下钻查询，细化查询。
metric的tag不要太多，尽量不要超过5个， 多8个。
metric和tag的命名规则：大小写敏感，不允许空格，只允许一下字符: a to z, A to Z, 0 to 9, -, _, ., / or Unicode letters (as per the specification).   

 

2. 数据点 Data Point

一个Data Point必须包括：metric，至少一个tag, 时间戳, 一个数值(整数或浮点数)
时间戳：一定是整数，13位毫秒，10位秒。在一个序列中尽量使用同样的时间戳，混合不同单位的时间戳会引起查询变缓慢。如果没有必要，使用秒为单位，降低存储空间的消耗。
数值value：只能由数字和小数点组成，如果没有小数点，则认为是整数，否则是浮点数。整数使用可变长编码方式，少一字节，多8字节。浮点数为4字节单精度浮点数。由于浮点数是单精度类型，因此不支持需要值得浮点数，例如15.2会被保存为15.199999809265137
写入数据时，不必按照时间序列写入，时间戳在后的数据可以先写入，在写入时间戳在前的数据。
数据重复写入的问题： 
在同一小时内多次写入相同的数据不会有问题。
如果设置compaction操作，那么如果前后两次写入的数据类型不同，则在查询时一定会抛出异常。如果两次写入的数据类型相同，那么在该行还没有进行compaction操作之前，前面的数据将被覆盖掉。
2.1版本，可以设置tsd.storage.fix_duplicates=true. 近写入的数据会被返回