如果大家對時序指標的存儲方案有些了解，那大概率會聽過 VictoriaMetrics，VictoriaMetrics 號稱 Prometheus 的升級版，在性能和成本方面也確實做得很好，如果是夜鶯新用戶，我都是推薦直接使用 VictoriaMetrics 來作為存儲。前幾天 Victoria 發(fā)布了 VictoriaLogs，號稱比 ElasticSearch 大幅節(jié)省成本（成本問題確實是 ElasticSearch 廣受詬病的點），號稱比 Loki 快，號稱比 ClickHouse 易用，這… 牛逼吹的很大，不知道未來是否能獨霸天下。本文翻譯了一下 VictoriaLogs 官方文檔中和其他存儲的對比，大家可以先做一個了解，看看 VictoriaLogs 是憑什么這么說。

和 ElasticSearch(OpenSearch) 的對比

Elasticsearch 和 VictoriaLogs 都允許攝取結構化和非結構化日志，并對攝取的日志執(zhí)行快速全文搜索。 Elasticsearch 和 OpenSearch 被設計為通用數(shù)據庫，用于對大量文檔進行快速全文搜索。它們沒有專門針對日志進行優(yōu)化。這會導致以下問題，VictoriaLogs 已解決這些問題：

• RAM 使用率高
• 磁盤空間使用率高
• 重要但不太好搞的索引設置
• 無法在單個查詢中選擇超過 10K 的匹配日志行

VictoriaLogs 專門針對日志進行了優(yōu)化。因此它提供了以下對日志有用的功能，而 Elasticsearch 中缺少這些功能：

• 易于設置和操作。無需調整配置以獲得最佳性能或為各種日志類型創(chuàng)建任何索引。只需在最合適的硬件上運行 VictoriaLogs - 它就會自動提供最佳性能。
• 對于相同的工作負載，RAM 使用量比 Elasticsearch 低 30 倍。
• 對于相同數(shù)量的存儲日志，磁盤空間使用量比 Elasticsearch 少 15 倍。
• 能夠在單個節(jié)點上處理數(shù)百 TB 的日志。
• 非常易于使用的查詢語言，針對典型日志分析任務進行了優(yōu)化 - LogSQL。
• 開箱即用地對所有日志字段進行快速全文搜索。
• 與傳統(tǒng)的日志分析命令行工具良好集成。

和 Grafana Loki 的對比

Grafana Loki 和 VictoriaLogs 都是為日志管理和處理而設計的。兩個系統(tǒng)都支持 log stream 概念。

VictoriaLogs 和 Grafana Loki 有以下區(qū)別：

• Grafana Loki 不支持高基數(shù)日志字段（也稱為標簽），例如 user_id、trace_id 或 ip。當具有高基數(shù)字段的日志被攝取到其中時，它開始消耗大量的 RAM 并且工作速度非常慢。有關詳細信息，請參閱這些文檔。 VictoriaLogs 支持高基數(shù)日志字段。它自動索引所有攝取的日志字段，并允許對任何字段執(zhí)行快速全文搜索。
• Grafana Loki提供了非常不方便的查詢語言——LogQL。這種查詢語言很難用于典型的日志分析任務。VictoriaLogs 為典型日志分析任務提供了易于使用的查詢語言 - LogSQL。
• VictoriaLogs 執(zhí)行典型全文查詢的速度比 Grafana Loki 快 1000 倍。
• 對于相同數(shù)量的日志，VictoriaLogs 需要的存儲空間比 Grafana Loki 更少。
• VictoriaLogs 比 Grafana Loki 更容易設置和操作。

恰飯時刻：FlashDuty 是一款告警事件 OnCall 中心的產品?？梢詫?Zabbix、Prometheus、Open-Falcon、Nightingale、Influx、Grafana、藍鯨、各類云監(jiān)控，把告警事件統(tǒng)一匯聚到一個中心，做告警聚合收斂降噪、排班認領協(xié)同。適合對穩(wěn)定性有訴求的團隊以及同時使用了多個監(jiān)控系統(tǒng)的團隊，歡迎體驗和試用。

• 產品介紹地址：https://flashcat.cloud/product/flashduty/
• 產品注冊體驗：https://console.flashcat.cloud/

和 ClickHouse 的對比

ClickHouse 是一個極其快速且高效的分析數(shù)據庫?？捎糜谌罩敬鎯?、分析和處理。 VictoriaLogs 專為日志設計。 VictoriaLogs 使用與 ClickHouse 類似的設計思想來實現(xiàn)高性能。

• 如果您事先知道日志字段集，則 ClickHouse 對于日志很有用。然后，您可以創(chuàng)建一個表，每個日志字段有一列，并實現(xiàn)最大可能的查詢性能。如果事先未知日志字段集，或者它可以隨時更改，則仍然可以使用 ClickHouse，但其效率可能會受到顯著影響，具體取決于您如何設計用于日志存儲的數(shù)據庫 Schema。ClickHouse 的效率很大程度上取決于所使用的數(shù)據庫 Schema。它必須針對特定工作負載進行優(yōu)化，以實現(xiàn)高效率和查詢性能。VictoriaLogs 可與任何開箱即用的日志類型（結構化、非結構化和混合）完美配合。它可以與任何日志字段集完美配合，這些字段可以在不同的日志源中以任何方式更改。
• ClickHouse 為 SQL 方言提供了額外的分析功能。它允許對存儲的日志執(zhí)行任意復雜的分析查詢。VictoriaLogs 提供易于使用的查詢語言和專門針對日志分析進行優(yōu)化的全文搜索 - LogSQL。對于典型的日志分析任務，LogSQL 通常比 SQL 更容易使用，而一些重要的分析可能需要 SQL 功能。
• VictoriaLogs 開箱即支持業(yè)內常用的日志采集中轉器。ClickHouse 需要一個中間應用程序來將攝取的日志轉換為特定數(shù)據庫模式的 INSERT SQL 語句。這可能會增加系統(tǒng)的復雜性，并隨后增加其維護成本。

VictoriaLogs 是如何工作的？

VictoriaLogs 接收 JSON 條目形式的日志。然后它將每個字段值存儲到不同的數(shù)據塊中。例如，多個日志條目中同一字段的值存儲在單個數(shù)據塊中。這允許在查詢期間僅讀取所需字段的數(shù)據塊。數(shù)據塊在保存到持久存儲之前會被壓縮。當受磁盤讀取 IO 帶寬限制時，這可以節(jié)省磁盤空間并提高查詢性能。較小的數(shù)據塊在后臺合并為較大的塊。數(shù)據塊的大小是有限的。如果數(shù)據塊的大小超過限制，則將其分割成多個較小大小的塊。

在查詢期間以原子方式處理每個數(shù)據塊。例如，如果數(shù)據塊至少包含需要處理的單個值，則立即解包并讀取整個數(shù)據塊。查詢期間，數(shù)據塊在所有可用的 CPU 內核上并行處理。這允許通過可用 CPU 核心的數(shù)量來擴展查詢性能。

該架構的靈感來自 ClickHouse 架構。

除此之外，VictoriaLogs 采用額外的優(yōu)化來實現(xiàn)高查詢性能：

• 它使用布隆過濾器來跳過沒有給定單詞或短語的塊。
• 它對不同數(shù)據類型的字段使用自定義編碼和壓縮。例如，它將 IP 地址編碼為 4 字節(jié)元組。自定義字段的編碼可減少磁盤上的數(shù)據大小并提高查詢性能。
• 它在物理上將同一 log stream 的日志分組為彼此靠近。這提高了壓縮率，有助于減少磁盤空間的使用。當使用流過濾器時，這還可以通過跳過不需要的流的塊來提高查詢性能。
• 它維護日志時間戳的稀疏索引，這可以在使用時間過濾器時提高查詢性能。