乐趣区

关于pulsar:VictoriaLogs一款超低占用的-ElasticSearch-替代方案

背景

前段时间咱们想实现 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 的 TPSCPU 应用不到 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 还有很大的提高空间,有相似需要的能够继续关注。

退出移动版