OpenTSDB 寫入數據

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