共计 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 还有很大的提高空间，有相似需要的能够继续关注。