背景

前段時間我們想實現 Pulsar 消息的追蹤流程，追蹤實現的效果圖如下：

實現其實比較簡單，其中最重要的就是如何存儲消息。

消息的讀取我們是通過 Pulsar 自帶的 BrokerInterceptor 實現的，對這個感興趣的朋友后面會單獨做一個分享。

根據這里的顯示內容我們大概需要存儲這些信息：

• 客戶端地址
• 消息發布時間
• 分發消費者、訂閱者名稱
• ACK 消費者、訂閱者名稱
• 消息 ID 最終捋了下：

圖片

都以兩個 consumer 計算：一條消息占用內存：140+ 535*2 + 536*2 =2282byte存儲三天：TPS * 86400 * 3=TPS*259200 條總存儲：2282*TPS*259200≈ 百GB

根據我們的 TPS 計算，三天的大概會使用到 上百 G 的存儲，這樣首先就排除了 Redis 這種內存型數據庫。

同樣的換成 MySQL 存儲也不劃算，因為其實這些數據并不算那么重要。

做了幾個技術選型都不太滿意，不是資源開銷太大就是沒有相關的運維經驗。

后面在領導的提醒下，我們使用的 VictoriaMetrics 開源了一個 VictoriaLogs，雖然當時的版本還是 0.1.0，使用過他們家 Metrics 的應該都會比較信任他們的技術能力，所以就調研了一下。

具體的信息可以查看官方文檔：https://docs.victoriametrics.com/VictoriaLogs/

圖片

簡單來說就是它也是一個日志存儲數據庫，并且有著極低的資源占有率，相對于 ElasticSearch 來說內存、磁盤、CPU 都是幾十倍的下降率。

圖片

通過官方的壓測對比圖會發現確實在各方面對 ES 都是碾壓。

圖片

官方宣傳的第一反應是不能全信，于是我自己壓測了一下，果然 CPU 內存 磁盤的占用都是極低的。

同時也發現運維部署確實簡單，直接一個 helm install 就搞定，就是一個二進制文件，不會依賴第二個組件。

按照剛才同樣的數據存儲三天，只需要不到 6G 的磁盤空間，我們生產環境已經平穩運行一段時間了。

圖片

因為我們是批量寫入數據的，所以在最高峰 20K 的 TPS 下 CPU 使用不到 0.1 核，內存使用最高 120M，這點確實是對 ES 碾壓了。

圖片

磁盤占用也是非常少。

這些有點得歸功于它有些的壓縮、編解碼算法，以及 Golang  帶來的相對于 Java 的極低資源占用。

還存在的問題

如果一切都這么完美的話那 VictoriaLogs  確實也太變態了， 自然他也有一些不太完美的地方。

分詞功能有限

首先第一個是分詞功能有限，只能做簡單的搜索，無法做到類似于 ES 的各種分詞，插件當然也別想了。

不支持集群

當前版本不支持集群部署，也就是無法橫向擴展了；不過幸好他的的單機性能已經非常強了。

這也是目前階段部署簡單的原因。

過期時間無法混用

VictoriaLogs 支持為數據配置過期時間自動刪除，有點類似于 Redis，它會在后臺啟動一個協程定期判斷數據是否過期，但只能對所有數據統一設置。

比如我想在 VictoriaLogs 中存放兩種不同類型的數據，同時他們的過期刪除時間也不相同；比如一個是三天刪除，一個是三月后刪除。

這樣的需求目前是無法實現的，只能部署兩個 VictoriaLogs.

默認無法查詢所有字段

圖片

由于 VictoriaLogs  可以存儲非結構化數據，默認情況下只能查詢內置的三個字段，我們自定義的字段目前沒法自動查詢，需要我們手動指定。

這個倒不是致命問題，只是使用起來稍微麻煩一些；社區也有一些反饋，相信不久就會優化該功能。

圖片

圖片

• https://github.com/VictoriaMetrics/VictoriaMetrics/issues/4780
• https://github.com/VictoriaMetrics/VictoriaMetrics/issues/4513

沒有官方 SDK

圖片

這也是個有了更好的一個功能，目前只能根據 REST API 自己編寫。

總結

當前我們只用來存儲 Pulsar 鏈路追蹤數據，目前看來非常穩定，各方面資源占用極少；所以后續我們會陸續講一些日志類型的數據遷移過來，比如審計日志啥的。

之后再逐步完善功能后，甚至可以將所有應用存放在 ElasticSeach 中的日志也遷移過來，這樣確實能省下不少資源。

總得來說 VictoriaLogs  資源占用極少，如果只是拿來存儲日志相關的數據，沒有很強的分詞需求那它將非常合適。

截止到目前最新版也才 0.3.0 還有很大的進步空間，有類似需求的可以持續關注。