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. 最近寫入的數據會被返回