ClickHouse 填平 Elasticsearch 护城河？日志分析新选择！

ClickHouse 现已推出专为分析和可观测性构建的全新全文搜索功能，在一个引擎中结合了快速多词条搜索和大规模聚合。这使得它成为 Elasticsearch 在日志分析领域一个极具吸引力的替代方案。本基准测试将揭示其原因。 最后一块“护城河”被填平 多年来，人们的选择很简单：Elasticsearch 用于文本搜索，ClickHouse 用于分析。 现在 ClickHouse 二者兼具。 ClickHouse 现已 集成了一个 重新设计的、由倒排索引 (inverted indexes) 驱动的全文搜索功能。但与传统搜索引擎不同的是，匹配的文档会直接送入其原有的向量化分析引擎 (vectorized analytical engine)，该引擎在过滤、聚合和大规模扫描方面已 表现出色。 这种结合在搜索仅仅是第一步时显得尤为重要。在 可观测性领域，尤其是在日志分析中，搜索很少仅仅是为了查找文本。用户通常会先搜索某个错误模式，然后统计其出现次数、按服务分组、深入更小的时间范围，或者隔离受影响的主机。 换句话说：日志是恰好包含文本的分析数据。 在本次基准测试中，我们将在真实的 OpenTelemetry 日志工作负载下，对比 ClickHouse 和 Elasticsearch 的开源版本 (OSS versions) 在高达 500 亿行的数据集上的表现。 抢先看：在所有测试的数据集规模上，ClickHouse 执行全文分析工作负载的速度比 Elasticsearch 快 2-6 倍。此外，ClickHouse 存储 OpenTelemetry 日志数据集的效率也远高于 Elasticsearch。 完整的基准测试是端到端可复现的：源数据、Schema、查询、数据摄入脚本和测量结果均已发布在我们的 公共 GitHub 仓库中(https://github.com/ClickHouse/TextBench/tree/main) 。 接下来，我们将阐述基准测试的设置和方法，然后探讨这两个系统如何在磁盘上存储 OpenTelemetry 日志，最后比较它们的存储占用和查询执行时间。 基准测试设置 在揭晓结果之前，以下是完整的基准测试设置：数据集、查询、硬件和系统配置。 如果您更关注结果，可以直接跳转至存储占用和查询执行时间部分。 Dataset 该基准测试采用由我们的 OpenTelemetry 演示应用程序生成的真实 OpenTelemetry日志数据集，该数据集产生的结构化服务日志与现代可观测性管道中常见的日志类似。 为确保基准测试完全可重现，所有源数据均以Parquet 文件的形式发布在一个公共 Amazon S3 存储桶中。 区域：eu-west-3 (欧洲 — 巴黎)；公共存储桶：s3://public-pme/text_bench；直接 URL：https://public-pme.s3.eu-west-3.amazonaws.com/text_bench/part_{000..009}.parquet；文件结构：每个 Parquet 文件包含 10 亿条日志记录，并按时间戳排序；提示：建议在 eu-west-3 区域运行 EC2 基准测试实例，以避免跨区域数据摄取延迟和出口费用。 基于这些源数据，我们以三种不同的规模，将相同的基准数据集加载到 ClickHouse 和 Elasticsearch 中： 通过这种方式，我们能够评估这两个系统从十亿行级别的部署到应对大规模生产可观测性工作负载时的表现。 查询 为了评估实际的全文分析搜索性能，我们使用了一套包含九个 OpenTelemetry 日志查询的集合。每个查询均基于单词或多词的全文搜索构建，并常常伴随过滤、计数、分组、排序或基于时间的聚合操作。 这些查询均使用各系统原生的查询语言实现（ClickHouse 使用 SQL；Elasticsearch 使用 Query DSL 和 ES|QL）。 这套查询旨在反映 Kibana 等工具中典型的日志分析工作流程，即用户搜索错误消息后，立即对其进行过滤、计数、分组、排序或随时间进行分析。 查询组合涵盖了四种常见的调查模式： Q1–Q3：事件深入分析与日志检索 定位匹配给定术语的日志行，应用过滤器，并查看相关事件。 Q4–Q5：总体错误和匹配计数 计算匹配记录，或比较各子集之间的匹配量。 Q6–Q7：服务级别细分 根据服务名称、主机或严重性等维度对匹配日志进行分组，以识别问题集中之处。 Q8–Q9: 基于时间的趋势分析 将匹配项按时间段聚合，以揭示峰值、回落或重复模式。 综合来看，这些查询全面模拟了日志分析中的典型任务，涵盖从选择性日志检索到大规模分析搜索。 硬件和系统版本 两个系统都在相同且独立的单节点环境中进行了基准测试，以确保进行公平的同类比较。每个引擎都在其各自的专用 EC2 实例上运行，并采用相同的 CPU、内存和存储配置。 系统配置 ClickHouse ClickHouse 使用了一个标准的 MergeTree 表，其 OpenTelemetry 日志 模式 包含了时间戳、数值、字符串和映射的原生数据类型。该表按以下方式 排序： (ServiceName, Timestamp) 此排序键提高了针对按服务和时间范围过滤的常见日志分析查询的数据局部性，同时还改进了压缩。 在 Body 列上 创建了一个 全文索引。 Elasticsearch Elasticsearch 使用了一个等效的 索引映射，具有相同的逻辑模式和匹配的 物理排序顺序： index.sort = (ServiceName ASC, Timestamp ASC) 主要映射选择： Body映射为 text 类型并使用标准分析器（支持全文搜索）；结构化字符串维度映射为 keyword 类型；类 Map 的属性字段映射为 flattened 类型；TraceFlags 和 SeverityNumber 映射为 byte 类型；启用 codec: best_compression 以最小化磁盘占用。 在 Elasticsearch 允许的最大范围内，此配置尽可能地复刻了 ClickHouse 的语义，同时遵循了存储最佳实践。 为了确保稳定的单节点性能，我们使用了这些 JVM和 OS 设置： 堆内存固定为 30 GiB (-Xms30g -Xmx30g) 以保留 CompressedOops；bootstrap.memory_lock: true；vm.max_map_count=262144。 分片布局 该基准测试使用了单节点存储优化布局，两个系统中均无副本。 针对每个数据集，ClickHouse 使用了单个分片（即单表），而 Elasticsearch 则采用了多个分片，这遵循了实现最佳分片大小的行业最佳实践（每个分片 50GB）。 在测量之前，所有 Elasticsearch 分片都依照最佳实践被强制合并，使每个分片只包含一个段。这不仅提升了存储效率，也不会阻碍并行搜索的执行，因为 Lucene 在查询时仍能逻辑上对单个段进行分区。 数据加载 ClickHouse 通过其原生的 Parquet 摄入能力直接加载了 Pa