VictoriaLogs：一款超低占用的 ElasticSearch 替代方案-Toy模板网

这篇具有很好参考价值的文章主要介绍了VictoriaLogs：一款超低占用的 ElasticSearch 替代方案。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

VictoriaLogs：一款超低占用的 ElasticSearch 替代方案,elasticsearch,大数据,搜索引擎,全文检索

image.png

背景

前段时间我们想实现 Pulsar 消息的追踪流程，追踪实现的效果图如下： VictoriaLogs：一款超低占用的 ElasticSearch 替代方案,elasticsearch,大数据,搜索引擎,全文检索

实现其实比较简单，其中最重要的就是如何存储消息。

消息的读取我们是通过 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/

VictoriaLogs：一款超低占用的 ElasticSearch 替代方案,elasticsearch,大数据,搜索引擎,全文检索

image.png

简单来说就是它也是一个日志存储数据库，并且有着极低的资源占有率，相对于 ElasticSearch 来说内存、磁盘、CPU 都是几十倍的下降率。

image.png

通过官方的压测对比图会发现确实在各方面对 ES 都是碾压。 VictoriaLogs：一款超低占用的 ElasticSearch 替代方案,elasticsearch,大数据,搜索引擎,全文检索

官方宣传的第一反应是不能全信，于是我自己压测了一下，果然 CPU 内存磁盘的占用都是极低的。

同时也发现运维部署确实简单，直接一个 helm install 就搞定，就是一个二进制文件，不会依赖第二个组件。

按照刚才同样的数据存储三天，只需要不到 6G 的磁盘空间，我们生产环境已经平稳运行一段时间了。 VictoriaLogs：一款超低占用的 ElasticSearch 替代方案,elasticsearch,大数据,搜索引擎,全文检索因为我们是批量写入数据的，所以在最高峰 20K 的 TPS 下 CPU 使用不到 0.1 核，内存使用最高 120M，这点确实是对 ES 碾压了。