1. 關於metric, tag name和tag value

    1) opentsdb的每個時間序列必須有一個metric和一個或多個(tag name, tag value)對，每個時間序列每小時的資料儲存為一行。

    2) Opentsdb的metric, tag name和tag value各自的UID數量上限為2^24個，該值可以通過改變原始碼重新編譯後進行修改，最多可以擴充套件到8位元組，即2^64個。不建議修改。

    3) tag name和tag value的UID分配是完全獨立的，例如，如果tag value的取值為整數2，那麼這個值完全可以被多個tag name所使用，例如cpu=2, interface=2, hdd=2等。

    4) 在設計系統時應該確保metric, tag name和tag value的可能取值在較小的範圍內，因為它們的數量影響到查詢速度。

    5) 注意事項：

           a. 減少它們的數量。

           b. 為每個metric使用同類的tag name

           c. 考慮系統常用的查詢方式，選擇合適的時間序列metric和tag

           d. 每個metric的tag數量維持在5個以內，最多不超過8個。

    6) 儲存時間序列資料的時候，每個資料點要包含以下內容：metric，至少一對tag，時間戳（自1970年起的秒或毫秒），一個數值（整數或浮點數）。

    7) 時間戳：一定是整數，且不超過13位。如果是13位表示毫秒，10位則表示秒。在一個序列中應該採用同樣單位的時間戳（都是秒或者都是毫秒），混合不同單位的時間戳會引起查詢緩慢，如無必要，應該用秒為單位，降低儲存空間的消耗。

    8) metric和tag的命名規則：大小寫敏感，不允許空格，只允許以下字元：字母，數字，減號，下劃線，點號，斜槓(/)，長度不限，但是儘量短一些。

2. 資料點：

      1) 只能由數字和小數點組成，如果沒有小數點，則認為是整數，否則認為是浮點數。整數使用可變長度編碼方式，最少1位元組，最多8位元組。浮點數為4位元組單精度浮點數。由於浮點數是單精度型別，因此不支援需要精確值得浮點數，例如15.2會被儲存為15.199999809265137

      2) 寫入資料時不必按照時間順序寫入，時間戳在後的資料可以先寫入，再寫入時間戳在前的資料。

      3) 資料重複寫入的問題：

            a. 在同一小時內多次寫入相同的資料不會有問題。

            b. 如果設定和compaction操作，那麼如果前後兩次寫入的資料型別不同，則在查詢時一定會丟擲異常。如果兩次寫入的資料型別相同，那麼在該行還沒有進行compaction操作之前，前面的資料將被覆蓋掉。

       4) 資料寫入方式：

              資料有三種寫入方式：telnet, http post，用資料檔案批量匯入。

3. HBase的組建方式：

        1) 測試或容量較低時可以採用單機模式，這時HBase使用本地檔案系統作為儲存。              

        2) 大資料量的生產環境應該採用正式的多機叢集模式：Namenode雙機備份，3臺Zookeeper，HDFS節點採用JBOD儲存，HBase的Region節點和HDFS資料節點共用。

            各個節點之間採用千兆或萬兆網路連線，叢集位於一個數據中心。

4. 效能考慮：

       1) 每個TSD程序的處理能力大約為每秒幾千次寫，可以使用多個TSD程序實現更高寫入能力，前端採用DNS輪詢或Varnish快取實現負載均衡。當叢集專用於opentsdb時，TSD程序可以和HBase的Region server位於同一臺機器。

       2) 可以將TSD程序配置為持久連線，這就可以阻止每次寫入資料都經歷建立和關閉連線的過程。

       3) 關閉元資料和實時釋出功能，因為它們極大地影響到系統性能。