共计 1778 个字符,预计需要花费 5 分钟才能阅读完成。
背景
前段时间咱们想实现 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
还有很大的提高空间,有相似需要的能够继续关注。