OpentTsdb官方文檔中文版----查詢性能

緩存

  此時OpenTSDB沒有內置緩存（除了將緩存PNG圖像文件60秒的內置GUI）。因此只能依靠底層數據庫的緩存。在HBase（最常見的OpenTSDB后端）中，有一個塊緩存的概念，它可以在寫入 和/或 讀取時在內存中存儲行和列的塊。Nick Dimiduck的Block Cache 101是一個很好的入門書。設置緩存的一個好方法是使用BucketCache緩存并將L1緩存大小設置得相當大，這樣它就可以充當寫緩存并將大部分最新數據保存在內存中。然后，當用戶運行查詢時，L2緩存可以將經常查詢的數據保存在內存中。
  仔細觀察region server的GC暫停。用戶通常在堆外模式下運行bucket cache，但在堆外緩存命中和寫入操作中，Java和JNI之間的序列化操作仍有一定的代價。
  另外，請確保HBase表已啟用壓縮。塊使用表中指定的壓縮算法存儲在內存中，因此與未壓縮的塊相比可以將更多壓縮塊放入緩存中。

One Out of Many Queries

  如果通常在某個指標中查找一個或兩個時間序列的查詢（即多個標簽值不同），請確保使用了2.3或更高版本且在查詢中啟用了explicitTags。查詢必須列出與正在查找的數據相關聯的所有標簽key，但它會啟用HBase上的特殊過濾器，這將有助于減少掃描的行數。詳情請參閱查詢過濾器。
  或者，如果在指標名稱中放置高基數的標簽，這將大大減少查詢時掃描的數據量并提高性能。請參閱編寫數據以獲取更多信息

高基數查詢

  對于將許多時間序列聚合在一起的查詢，提高性能的最佳方法是在啟用salting的情況下運行OpenTSDB 2.2或更高版本，并在HBase集群中運行多個regionserver。這將并行執行查詢，從每個regionserver獲取數據子集并合并結果。例如，對于單個regionserver，查詢可能需要10秒才能完成。使用salting將相同的數據寫入5個regionserver時，相同的查詢大約花費2秒，它是由最慢的regionserver響應所需的時間決定的。合并集合通常是微不足道的。

寬時間范圍查詢

  如果在TSD和消費應用程序（例如UI或API客戶端）之間觀察到瓶頸，那么查看寬時間范圍（例如幾個月或幾年）的查詢可以使用降采樣，并從中受益。使用降采樣器將減少由TSD序列化并發送給用戶的數據量。
但是，如果存儲（HBase）和TSD之間存在瓶頸，那么最好的解決方案是使用OpenTSDB 2.4或更高版本開始寫入上卷數據。這需要外部系統計算基于時間的上卷并將其寫入存儲。或者，UI或API客戶端可針對較小時間范圍跨度的多個TSD執行多個查詢并將結果合并在一起。未來我們計劃直接向TSD添加這些功能。

通用優化

  需要考慮的其他事項：

多個可讀TSD

  運行多個專用于讀取數據的TSD，并在它們的前面放置負載均衡器。這是運行OpenTSDB時觀察到的最常見的設置，允許在不關閉整個系統的情況下輪換升級TSD。

調優存儲

  HBase有許多可以調整的參數，一般而言，大多數OpenTSDB的瓶頸都來自HBase。確保監視服務器，特別是隊列，緩存，響應時間，CPU和GC。

教育用戶

  沒有數據庫系統可以避免長時間運行或資源浪費查詢。要求用戶從較小的時間范圍開始，如1小時，并逐漸增加時間范圍。還有幫助用戶了解基數，以及如何請求high_cardinality_tag_key=*可能是一個壞主意。