版權說明： 本文章版權歸本人及部落格園共同所有，轉載請在文章前標明原文出處( 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效能表現很好，要能駕馭這元件需要比較多的功力，不能單純從表層去把它當做一個黑盒來運維，以免後續出現慢寫入慢查詢會變得手足無措。
原始碼層面的分析可以搜尋下其他文章，在此就不再分析程式碼段。