本篇提問

• Prometheus 的效能瓶頸，相關產品如何解決？
• Prometheus 的特色與其他時間序列資料庫的異同？

query_range 的效能問題

PromQL 使用上難免會遇到效能問題。從本系列的介紹中，我們知道 query_range 的計算過程所需的資源和以下因素有關：

• 時間範圍
  • 計算需時正比於時間範圍
  • 讀寫資料量正比於時間範圍（以 Chunks 的時長為精度）
• 樣本密度
  • 讀取的資料量正比於時間序列的樣本密度
• 取樣密度
  • 計算過程中的中間值資料量正比於 query_range 指定的取樣密度
• 時間序列數量
  • 計算需時正比於計算的時間序列數量
  • 計算所需的記憶體正比於計算的時間序列數量
• PromQL 語句複雜度
  • 計算需時大致正比於 PromQL 語句的語法樹大小

在需要提升 query_range 效能的情況下（通常是因為監控面版無法即時顯示資料），一般來說最有操作空間的是時間序列數量。（取樣密度方面 Grafana 監控面版會自動依時間範圍設定）
這是 recording rule 的一個重要用法。簡化 query_range 所傳入的 PromQL 語法樹之外，將能合併的時間序列依標籤預先合併，可以大幅減少 query_range 的計算時間和記憶體使用量。

然而，工作團隊中有負責優化的人，當然也就有負責使壞的人。總是會有人寫入過多的時間序列（例如不小心把訂單編號放進標籤值 endpoint=/query_order/?order_id=314）。這時該怎麼人工處理髒掉的資料呢？

本節提問

• 如何處理過多的時間序列？
• 效能更好的 Thanos 和 OpenTSDB 是怎麼做到的？
• Native histogram 能解決 histogram bucket 過多造成時間序列數過多的問題嗎？

Prometheus 做為時間序列資料庫的特色

為了效能和複雜度考量，Prometheus 在設計時做了很多決定，使得它不被當作泛用的時間序列資料庫。
一些 Prometheus 可泛用於時間序列資料庫的性質：

• OOO（Out of Order）有寫入限制（相對於關聯式資料庫各有不同 ACID 特性）
• 以標籤識別時間序列。
• 以時間序列為單位的資料壓縮

一些 Prometheus 獨特之處：

• OOO 寫入的例外處理（Chunk 合併）
• 資料型態的單一性（數值只有 float）
• PromQL 讀數值是用抽樣的（指定時間戳）。而不是直接讀出資料庫裡的的樣本時間戳。

本節提問

• Prometheus 的特色與其他時間序列資料庫的異同？