TSDB - VictoriaMetrics 技術原理淺析

mikevictor發表於2023-04-02

版權說明: 本文章版權歸本人及部落格園共同所有,轉載請在文章前標明原文出處( https://www.cnblogs.com/mikevictor07/p/17258452.html ),以下內容為個人理解,僅供參考。

 

一、前言

     在監控領域,通常需要指標儲存元件TSDB,目前開源的TSDB元件比較多,各個元件效能、高可用性、維護成本等等各有差異。本文不分析選型問題,重點講解VictoriaMetrics(後面簡稱為vm)。

     有興趣的朋友建議結合原始碼進行分析,由於原始碼不斷變更,此分析基於 v1.80.0,後續版本變化理論上不會很大。

 

二、架構與能力

   vm開源版本分為single-server(all in one)的單節點模式和cluster模式,單點模式合適本地除錯或測試使用,生產使用的cluster模式分為vmselect、vminsert、vmstorage三個主要模組:  

    (1)vmselect:查詢模組,可無狀態部署,客戶端傳送請求到查詢模組後,查詢模組會把請求分發到所有storage模組(由於沒有後設資料中心節點,固資料儲存在哪無法感知,類似clickhouse的設計模式),得到原始的block資料後在select模組進行合併,再得到一個總結果。

    (2)vminsert:寫入模組,可無狀態部署,寫入資料的請求發到此模組後,根據labels透過一定的hash計算出一個值,根據這個值確定此條資料發往哪個storage節點。因此相同的時間線會往同一個點節點傳送,如果有某個時間線資料量特別大則會出現資料傾斜問題後某個storage寫入和查詢壓力都會增大。在擴容貨縮容後,由於節點的列表變更,固計算出的hash發往的storage節點也會變更。

    (3)vmstorage:儲存模組,有狀態,儲存模組的移除須先從select和insert的配置中移除才不會有異常,此模組壓力最大,非常消耗記憶體和IO,固推薦使用SSD和比較大的記憶體,寧願用大規格的機器也不用量多但規格較小的機器(快取不命中則會造成較多的IO,效能下降嚴重)。

 

 

 

 

三、vmstorage 儲存模組

  本文重點講難度最高的 storage 模組,也只是屬於個人理解,如有錯誤或偏差,望指正

1、儲存目錄結構

 

/data 資料目錄的邏輯結構如下:

 (1)每個block只包括一個時間線,內部根據時間排序。

   (2) 每個block最大容納8000個sample,不同block可併發處理。

 

 

 

2、 寫入流程與風險點

 

 

3、查詢流程與風險點

 

 

 

 

4、資料過期機制

    開源的cluster版本只能針對租戶使用全域性的統一過期時間,收費的企業版才能支援租戶單獨設定過期時間

 

 

 

 

 

 

 

5、資料安全性保障

  (1)VictoriaMetrics 並未使用WAL,而是直接寫入類似SSTable的記憶體結構中,定時刷寫磁碟,這是此模組能表現出極高的寫入效能的一個原因,如果是單副本則當機時有可能照成最近的少量資料丟失,如果是資料安全性要求極高的場景,則建議開啟雙副本模式。

  (2)雙副本狀態下,寫入效能有一定的下降。即使在雙副本模式下,不能同時下線兩臺主機,如果同時下掉兩臺主機則資料會丟失,為保證資料安全,建議對儲存層配置RAID1、RAID5或RAID10保證資料安全性,遷移時將資料從data目錄直接遷移走即可在另一主機執行。

 

 

四、運維&監控能力、Downsample

  (1)vm配置有grafana的監控模板,安裝即可觀測各個模組的效能,需要結合程式碼才能比較深入的瞭解各個指標的作用含義(不過最前面部分的CPU/記憶體總量的計算貌似不正確,未深究,有興趣可以看看什麼問題)。

  (2)vm寫入由於沒有WAL,如果出現大量快取失效則容易出現慢寫入,甚至大量超時,所以寫入建議前置一個MQ(如kafka)緩解寫入異常放大,寫入模組做一定的異常限流防止查詢也出現大量超時。

  (3)vm很吃記憶體和磁碟,磁碟隨機IO很多,建議配置SSD。

  (4)vm開源版不支援儲存層的downsample(企業版才支援),故會查詢原始資料後透過promQL配置取樣減少輸出點,但總的來說不是儲存層的downsample查詢時間範圍過大時會有很大的壓力(比如一個月以上),建議上報的資料1分鐘一個點位減少資料量。

 

五、效能見解與總結

  官方寫了一些英文博文對比influxdb的效能,vm的表現優異,但建議實測(官方提供的總有一些趨向性)。從個人的測試資料上看錶現確實很不錯,資料不方便公開,建議自測。

  總之,此款基於golang的開源TSDB效能表現很好,要能駕馭這元件需要比較多的功力,不能單純從表層去把它當做一個黑盒來運維,以免後續出現慢寫入慢查詢會變得手足無措

  原始碼層面的分析可以搜尋下其他文章,在此就不再分析程式碼段。

 

相關文章