如果大家对时序指标的存储方案有些了解,那大概率会听过 VictoriaMetrics,VictoriaMetrics 号称 Prometheus 的升级版,在性能和成本方面也确实做得很好,如果是夜莺新用户,我都是推荐直接使用 VictoriaMetrics 来作为存储。前几天 Victoria 发布了 VictoriaLogs,号称比 ElasticSearch 大幅节省成本(成本问题确实是 ElasticSearch 广受诟病的点),号称比 Loki 快,号称比 ClickHouse 易用,这… 牛吹得很大,不知道未来是否能独霸天下。
本文翻译了一下 VictoriaLogs 官方文档中和其他存储的对比,大家可以先做一个了解,看看 VictoriaLogs 是凭什么这么说。
一、和 ElasticSearch(OpenSearch) 的对比
Elasticsearch 和 VictoriaLogs 都允许摄取结构化和非结构化日志,并对摄取的日志执行快速全文搜索。Elasticsearch 和 OpenSearch 被设计为通用数据库,用于对大量文档进行快速全文搜索。它们没有专门针对日志进行优化。这会导致以下问题,VictoriaLogs 已解决这些问题:
RAM 使用率高
磁盘空间使用率高
重要但不太好搞的索引设置
无法在单个查询中选择超过 10K 的匹配日志行
VictoriaLogs 专门针对日志进行了优化。因此它提供了以下对日志有用的功能,而 Elasticsearch 中缺少这些功能:
易于设置和操作。无需调整配置以获得最佳性能或为各种日志类型创建任何索引。只需在最合适的硬件上运行 VictoriaLogs - 它就会自动提供最佳性能。
对于相同的工作负载,RAM 使用量比 Elasticsearch 低 30 倍。
对于相同数量的存储日志,磁盘空间使用量比 Elasticsearch 少 15 倍。
能够在单个节点上处理数百 TB 的日志。
非常易于使用的查询语言,针对典型日志分析任务进行了优化 - LogSQL。
开箱即用地对所有日志字段进行快速全文搜索。
与传统的日志分析命令行工具良好集成。
二、和 Grafana Loki 的对比
Grafana Loki 和 VictoriaLogs 都是为日志管理和处理而设计的。两个系统都支持 log stream 概念。
VictoriaLogs 和 Grafana Loki 有以下区别:
Grafana Loki 不支持高基数日志字段(也称为标签),例如 user_id、trace_id 或 ip。当具有高基数字段的日志被摄取到其中时,它开始消耗大量的 RAM 并且工作速度非常慢。有关详细信息,请参阅这些文档。VictoriaLogs 支持高基数日志字段。它自动索引所有摄取的日志字段,并允许对任何字段执行快速全文搜索。
Grafana Loki提供了非常不方便的查询语言——LogQL。这种查询语言很难用于典型的日志分析任务。VictoriaLogs 为典型日志分析任务提供了易于使用的查询语言 - LogSQL。
VictoriaLogs 执行典型全文查询的速度比 Grafana Loki 快 1000 倍。
对于相同数量的日志,VictoriaLogs 需要的存储空间比 Grafana Loki 更少。
VictoriaLogs 比 Grafana Loki 更容易设置和操作。
三、和 ClickHouse 的对比
ClickHouse 是一个极其快速且高效的分析数据库。可用于日志存储、分析和处理。
VictoriaLogs 专为日志设计。VictoriaLogs 使用与 ClickHouse 类似的设计思想来实现高性能。
如果您事先知道日志字段集,则 ClickHouse 对于日志很有用。然后,您可以创建一个表,每个日志字段有一列,并实现最大可能的查询性能。如果事先未知日志字段集,或者它可以随时更改,则仍然可以使用 ClickHouse,但其效率可能会受到显着影响,具体取决于您如何设计用于日志存储的数据库 Schema。ClickHouse 的效率很大程度上取决于所使用的数据库 Schema。它必须针对特定工作负载进行优化,以实现高效率和查询性能。VictoriaLogs 可与任何开箱即用的日志类型(结构化、非结构化和混合)完美配合。它可以与任何日志字段集完美配合,这些字段可以在不同的日志源中以任何方式更改。
ClickHouse 为 SQL 方言提供了额外的分析功能。它允许对存储的日志执行任意复杂的分析查询。VictoriaLogs 提供易于使用的查询语言和专门针对日志分析进行优化的全文搜索 - LogSQL。对于典型的日志分析任务,LogSQL 通常比 SQL 更容易使用,而一些重要的分析可能需要 SQL 功能。
VictoriaLogs 开箱即支持业内常用的日志采集中转器。ClickHouse 需要一个中间应用程序来将摄取的日志转换为特定数据库模式的 INSERT SQL 语句。这可能会增加系统的复杂性,并随后增加其维护成本。
四、VictoriaLogs 是如何工作的?
VictoriaLogs 接收 JSON 条目形式的日志。然后它将每个字段值存储到不同的数据块中。例如,多个日志条目中同一字段的值存储在单个数据块中。这允许在查询期间仅读取所需字段的数据块。数据块在保存到持久存储之前会被压缩。当受磁盘读取 IO 带宽限制时,这可以节省磁盘空间并提高查询性能。较小的数据块在后台合并为较大的块。数据块的大小是有限的。如果数据块的大小超过限制,则将其分割成多个较小大小的块。
在查询期间以原子方式处理每个数据块。例如,如果数据块至少包含需要处理的单个值,则立即解包并读取整个数据块。查询期间,数据块在所有可用的 CPU 内核上并行处理。这允许通过可用 CPU 核心的数量来扩展查询性能。
该架构的灵感来自 ClickHouse 架构。
除此之外,VictoriaLogs 采用额外的优化来实现高查询性能:
它使用布隆过滤器来跳过没有给定单词或短语的块。
它对不同数据类型的字段使用自定义编码和压缩。例如,它将 IP 地址编码为 4 字节元组。自定义字段的编码可减少磁盘上的数据大小并提高查询性能。
它在物理上将同一 log stream 的日志分组为彼此靠近。这提高了压缩率,有助于减少磁盘空间的使用。当使用流过滤器时,这还可以通过跳过不需要的流的块来提高查询性能。
它维护日志时间戳的稀疏索引,这可以在使用时间过滤器时提高查询性能。
如果字段的最大可能长度超过255字节,那么长度值可能…
只能说作者太用心了,优秀
感谢详解
一般干个7-8年(即30岁左右),能做到年入40w-50w;有…
230721