如果大家对时序指标的存储方案有些了解，那大概率会听过 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 更容易设置和操作。

VictoriaLogs 要凭什么革了各家日志存储的命_VictoriaLogs

恰饭时刻：FlashDuty 是一款告警事件 OnCall 中心的产品。可以对接 Zabbix、Prometheus、Open-Falcon、Nightingale、Influx、Grafana、蓝鲸、各类云监控，把告警事件统一汇聚到一个中心，做告警聚合收敛降噪、排班认领协同。适合对稳定性有诉求的团队以及同时使用了多个监控系统的团队，欢迎体验和试用。 

和 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 的日志分组为彼此靠近。这提高了压缩率，有助于减少磁盘空间的使用。当使用流过滤器时，这还可以通过跳过不需要的流的块来提高查询性能。
  • 它维护日志时间戳的稀疏索引，这可以在使用时间过滤器时提高查询性能。

扩展阅读：