查詢效能

查詢效能對任何資料庫系統都至關重要。此頁面列出了一些常見的OpenTSDB問題以及提高效能的方法。

快取記憶體

此時，OpenTSDB沒有內建快取（除了內建GUI，將快取PNG影象檔案60秒）。因此，我們依賴於底層資料庫的快取。在HBase（最常見的OpenTSDB後端）中，存在塊快取記憶體的概念，其將在寫入和讀取時在儲存器中儲存行和列的塊。Nick Dimiduck‘s Block Cache 101是一個很好的入門讀物。設定快取的一個好方法是使用BucketCache，設定儘量大的L1快取，以便它充當寫快取並將大部分最近的資料儲存在記憶體中。然後，當用戶執行查詢時，L2快取可以將經常查詢的資料儲存在記憶體中。

仔細觀察region server的GC暫停時間。使用者通常在堆外記憶體的模式執行bucket cache，但在Java和JNI之間訪問堆外記憶體，進行序列化時仍然需要付出代價。

此外，請確保在HBase表上啟用了壓縮。塊使用表中指定的壓縮演算法儲存在記憶體中，因此您可以在快取中容納比未壓縮更多的壓縮塊。

高於一切的查詢

如果您通常在查詢中查詢具有不同的基數高（即許多標記值）的metric中的一個或兩個時間序列，請確保使用版本2.3或更高版本，並且啟用explicitTags。查詢必須列出與要查詢的資料相關聯的所有tag key，它將在HBase上會啟用特殊過濾器，這將有助於減少掃描的行數。

或者，如果在metric中放置高基數tag，這將大大減少在查詢時掃描的資料量並提高效能。

高基數查詢

對於將多個時間序列聚合在一起的查詢，提高效能的最佳方法是使用OpenTSDB 2.2或更高版本，啟用了salting，並在HBase叢集中執行多個region server。這將並行執行查詢，從每個region server獲取查詢結果子集並最終合併結果。例如，對於單個region server，查詢可能需要10秒才能完成。當啟用salting將相同資料寫入5個region server時，相同的查詢花費大約2秒，即最慢region server響應所花費的時間。合併結果所花費的時間通常無關緊要。

大時間跨度查詢

對於大時間跨度的查詢（一個月或者一年），如果效能的瓶頸在TSD和應用之間，那麼取樣會有效提高效能。使用下采樣，將減少TSD傳送給使用者的資料量。

但是，如果瓶頸在儲存（HBase）和TSD之間，那麼最好的解決方案是使用OpenTSDB 2.4或更高版本，並啟用寫掛起。這需要外部系統來計算基於時間的彙總並將其寫入儲存。或者，UI或API客戶端可以針對較小的時間跨度對多個TSD執行多個查詢，並將結果合併在一起。在未來，我們計劃直接向TSD新增此類功能。

一般改進

需要考慮的其他事項：

多個讀TSD
執行專用於讀取資料的多個TSD，並在其前面放置負載平衡器。這是執行OpenTSDB時最常見設定，允許在不關閉整個系統的情況下輪換TSD升級。

調整儲存
HBase有許多可以調整的引數，一般來說，OpenTSDB的大部分瓶頸都來自HBase。確保監視伺服器，尤其是佇列，快取，響應時間，CPU和GC。

教育使用者
沒有哪個資料庫系統可以免受長時間執行或資源佔用查詢的影響。要求使用者以較小的時間範圍（例如1小時）開始，逐步增加其時間範圍。還可以幫助使用者理解高基數查詢 high_cardinality_tag_key=*可能是一個壞主意。