VictoriaLogs:一款超低占用的 ElasticSearch 替代方案
image.png 背景
前段時(shí)間我們想實(shí)現(xiàn) Pulsar 消息的追蹤流程，追蹤實(shí)現(xiàn)的效果圖如下：
實(shí)現(xiàn)其實(shí)比較簡(jiǎn)單，其中最重要的就是如何存儲(chǔ)消息。
消息的讀取我們是通過(guò) Pulsar 自帶的 BrokerInterceptor 實(shí)現(xiàn)的，對(duì)這個(gè)感興趣的朋友后面會(huì)單獨(dú)做一個(gè)分享。
根據(jù)這里的顯示內(nèi)容我們大概需要存儲(chǔ)這些信息：
- 客戶端地址
- 消息發(fā)布時(shí)間
- 分發(fā)消費(fèi)者、訂閱者名稱
- ACK 消費(fèi)者、訂閱者名稱
- 消息 ID 最終捋了下：
都以兩個(gè) consumer 計(jì)算：
一條消息占用內(nèi)存：140+ 535*2 + 536*2 =2282byte存儲(chǔ)三天：TPS * 86400 * 3=TPS*259200 條
總存儲(chǔ)：2282*TPS*259200≈ 百GB
根據(jù)我們的 TPS 計(jì)算，三天的大概會(huì)使用到 上百 G 的存儲(chǔ)，這樣首先就排除了 Redis 這種內(nèi)存型數(shù)據(jù)庫(kù)。
同樣的換成 MySQL 存儲(chǔ)也不劃算，因?yàn)槠鋵?shí)這些數(shù)據(jù)并不算那么重要。
做了幾個(gè)技術(shù)選型都不太滿意，不是資源開(kāi)銷太大就是沒(méi)有相關(guān)的運(yùn)維經(jīng)驗(yàn)。
后面在領(lǐng)導(dǎo)的提醒下，我們使用的 VictoriaMetrics 開(kāi)源了一個(gè) VictoriaLogs，雖然當(dāng)時(shí)的版本還是 0.1.0，使用過(guò)他們家 Metrics 的應(yīng)該都會(huì)比較信任他們的技術(shù)能力，所以就調(diào)研了一下。
具體的信息可以查看官方文檔：https://docs.victoriametrics.com/VictoriaLogs/
image.png
簡(jiǎn)單來(lái)說(shuō)就是它也是一個(gè)日志存儲(chǔ)數(shù)據(jù)庫(kù)，并且有著極低的資源占有率，相對(duì)于 ElasticSearch 來(lái)說(shuō)內(nèi)存、磁盤(pán)、CPU 都是幾十倍的下降率。
image.png
通過(guò)官方的壓測(cè)對(duì)比圖會(huì)發(fā)現(xiàn)確實(shí)在各方面對(duì) ES 都是碾壓。
官方宣傳的第一反應(yīng)是不能全信，于是我自己壓測(cè)了一下，果然 CPU 內(nèi)存 磁盤(pán)的占用都是極低的。
同時(shí)也發(fā)現(xiàn)運(yùn)維部署確實(shí)簡(jiǎn)單，直接一個(gè) helm install 就搞定，就是一個(gè)二進(jìn)制文件，不會(huì)依賴第二個(gè)組件。
按照剛才同樣的數(shù)據(jù)存儲(chǔ)三天，只需要不到 6G 的磁盤(pán)空間，我們生產(chǎn)環(huán)境已經(jīng)平穩(wěn)運(yùn)行一段時(shí)間了。
因?yàn)槲覀兪桥繉?xiě)入數(shù)據(jù)的，所以在最高峰 20K 的 TPS 下 CPU 使用不到 0.1 核，內(nèi)存使用最高 120M，這點(diǎn)確實(shí)是對(duì) ES 碾壓了。
磁盤(pán)占用也是非常少。
這些有點(diǎn)得歸功于它有些的壓縮、編解碼算法，以及 Golang 帶來(lái)的相對(duì)于 Java 的極低資源占用。
如果一切都這么完美的話那 VictoriaLogs 確實(shí)也太變態(tài)了， 自然他也有一些不太完美的地方。
分詞功能有限
首先第一個(gè)是分詞功能有限，只能做簡(jiǎn)單的搜索，無(wú)法做到類似于 ES 的各種分詞，插件當(dāng)然也別想了。
不支持集群
當(dāng)前版本不支持集群部署，也就是無(wú)法橫向擴(kuò)展了；不過(guò)幸好他的的單機(jī)性能已經(jīng)非常強(qiáng)了。
這也是目前階段部署簡(jiǎn)單的原因。
過(guò)期時(shí)間無(wú)法混用
VictoriaLogs 支持為數(shù)據(jù)配置過(guò)期時(shí)間自動(dòng)刪除，有點(diǎn)類似于 Redis，它會(huì)在后臺(tái)啟動(dòng)一個(gè)協(xié)程定期判斷數(shù)據(jù)是否過(guò)期，但只能對(duì)所有數(shù)據(jù)統(tǒng)一設(shè)置。
比如我想在 VictoriaLogs 中存放兩種不同類型的數(shù)據(jù)，同時(shí)他們的過(guò)期刪除時(shí)間也不相同；比如一個(gè)是三天刪除，一個(gè)是三月后刪除。
這樣的需求目前是無(wú)法實(shí)現(xiàn)的，只能部署兩個(gè) VictoriaLogs.
默認(rèn)無(wú)法查詢所有字段
image.png
由于 VictoriaLogs 可以存儲(chǔ)非結(jié)構(gòu)化數(shù)據(jù)，默認(rèn)情況下只能查詢內(nèi)置的三個(gè)字段，我們自定義的字段目前沒(méi)法自動(dòng)查詢，需要我們手動(dòng)指定。
這個(gè)倒不是致命問(wèn)題，只是使用起來(lái)稍微麻煩一些；社區(qū)也有一些反饋，相信不久就會(huì)優(yōu)化該功能。
- https://github.com/VictoriaMetrics/VictoriaMetrics/issues/4780
- https://github.com/VictoriaMetrics/VictoriaMetrics/issues/4513
沒(méi)有官方 SDK
image.png
這也是個(gè)有了更好的一個(gè)功能，目前只能根據(jù) REST API 自己編寫(xiě)。
總結(jié)當(dāng)前我們只用來(lái)存儲(chǔ) Pulsar 鏈路追蹤數(shù)據(jù)，目前看來(lái)非常穩(wěn)定，各方面資源占用極少；所以后續(xù)我們會(huì)陸續(xù)講一些日志類型的數(shù)據(jù)遷移過(guò)來(lái)，比如審計(jì)日志啥的。
之后再逐步完善功能后，甚至可以將所有應(yīng)用存放在 ElasticSeach 中的日志也遷移過(guò)來(lái)，這樣確實(shí)能省下不少資源。
總得來(lái)說(shuō) VictoriaLogs 資源占用極少，如果只是拿來(lái)存儲(chǔ)日志相關(guān)的數(shù)據(jù)，沒(méi)有很強(qiáng)的分詞需求那它將非常合適。
截止到目前最新版也才 0.3.0 還有很大的進(jìn)步空間，有類似需求的可以持續(xù)關(guān)注。
往期推薦
從 Pulsar Client 的原理到它的監(jiān)控面板
點(diǎn)分享
點(diǎn)收藏
點(diǎn)點(diǎn)贊
點(diǎn)在看