在上一篇文章《什么是日志聚合？选择优秀日志管理系统的关键要素》中，我们探讨了日志聚合的基础知识，讨论了其重要性以及评估日志聚合解决方案的一些参考标准。
本文将接着上篇，通过对市面上常见日志聚合工具的分析资源利用率、压缩效率、写入与查询性能以及第三方集成等关键指标进行全面的评估，帮助用户选择合适的日志聚合方案。
本文将选取三大主流平台，并基于上述指标进行优劣势对比。
Elasticsearch：全量索引，高效检索 ClickHouse：创新架构，性能均衡 GreptimeDB：统一可观测性平台，成本优化
性能对比
资源利用率
❝GreptimeDB 的资源利用效率最高，而 Elasticsearch 的索引较大，成本最高。GreptimeDB 将对象存储作为核心功能实现了成本优化。
Elasticsearch
Elasticsearch 基于 Lucene 的引擎提供了强大的全文搜索功能，但资源消耗较高。运行于 Java 虚拟机（JVM）上，垃圾回收和内存管理会带来额外开销，从而导致较高的 CPU 和内存使用率。其架构依赖于创建大规模的倒排索引，这不仅占用大量磁盘空间，还增加了 I/O 操作频率。
频繁的索引更新和段合并进一步增加了 CPU 负载，并可能影响性能。与 ClickHouse 和 GreptimeDB 相比，Elasticsearch 对 CPU、内存和磁盘资源的需求更高，通常需要精心调优和强大的硬件支持才能在日志聚合场景中维持最佳性能。
ClickHouse
ClickHouse 的列式存储格式允许查询时仅读取必要的列，从而减少磁盘 I/O 和内存使用。ClickHouse 通过 C++ 实现，受益于底层的内存管理能力，它的内存开销较低，CPU 使用效率高，且无需额外的虚拟机组件。它使用向量化查询处理数据，利用现代 CPU 架构来批量处理数据，增强吞吐量。
GreptimeDB
GreptimeDB 专为处理时间序列数据设计，专注于高效的资源利用，以处理高吞吐量的日志写入和实时查询。GreptimeDB 是用 Rust 编程语言开发的，这带来了多方面的好处。Rust 以高性能和内存安全著称，因此 GreptimeDB 在内存管理和 CPU 使用效率上表现优异。此外，由于 Rust 是一种无虚拟机的语言，也不需要垃圾回收机制，这减少了额外的系统开销，从而进一步提升了整体性能。
使用 GreptimeDB 的另一个显著优势是其专注于将数据保存到对象存储，其存储成本远低于本地 SSD 的成本，这使得系统能够更高效地扩展——允许系统将存储需求与计算需求解耦。
压缩
❝GreptimeDB 具有最佳的压缩比，而 Elasticsearch 的压缩效果最差。
Elasticsearch
Elasticsearch 支持两种类型的压缩：LZ4 和 DEFLATE。压缩按索引进行，而不是按列进行，并且在创建索引时静态设置。索引的刚性和大小导致其相对较差的压缩比。
ClickHouse
ClickHouse 使用列式存储格式，这使其能够按列来有效地应用压缩算法。它支持多种压缩编解码器，包括 LZ4、ZSTD、Delta 和 DoubleDelta。用户可以根据数据类型，所需的压缩比，以及性能权衡来配置最佳的编解码器。ClickHouse 可以实现出色的压缩比，但需要用户了解如何将每种压缩类型与特定数据相匹配，并相应地设计和配置表。
GreptimeDB
GreptimeDB 专为时间序列数据设计，采用动态压缩算法，以适配所存储数据的类型和基数。GreptimeDB 专为时间序列数据设计，可以根据所存储数据的类型和基数，自适应地在诸如字典编码、游程编码以及各种不同的压缩和编码算法中选择最优组合，从而实现开箱即用的最佳压缩效果。
写入性能
❝ClickHouse 提供了最高的写入性能，其次是 GreptimeDB，而 Elasticsearch 在高吞吐量场景下表现较差。
Elasticsearch
Elasticsearch 旨在提供灵活的搜索和分析，但在写入性能方面，日志数据量非常大时会遇到问题。其架构依赖于创建和更新倒排索引，这是资源密集型的操作。该过程涉及到解析传入的日志数据，并在接近实时的情况下更新索引，这在高写入负载下会成为瓶颈。
此外，索引过程中频繁的段合并可能进一步降低写入性能。Elasticsearch 通常能够达到适度的写入速率，但在大规模日志聚合场景中，需要大量的调优和扩展工作，以达到预期的高写入速率。
ClickHouse
ClickHouse 针对高吞吐量的数据写入进行了优化，特别是对于结构化的列式数据。其 MergeTree 架构利用分区、主键索引和后台合并，通过并行化和批量插入来增强写入性能。然而，ClickHouse 需要精细的 schema 设计和数据预处理，才能实现最佳的写入速率。而且在配置数据管道时，需要匹配数据类型、分区键和索引，会引入额外的开销。这种额外的工作包括确保这些元素之间的兼容性和正确性，可能增加配置的复杂性和所需的时间精力。
GreptimeDB
GreptimeDB 在高写入性能方面表现出色，特别是对于时间序列日志数据。GreptimeDB 基于 LSM-Tree 的 Mito 引擎在写入过程中使用高效的编码和压缩技术，而不会牺牲速度。其架构支持水平扩展，即使在数据量增长时，也能保持高写入速率。
此外，GreptimeDB 在写入前需要较少的数据转换，简化了数据管道从而减小延迟。这使得 GreptimeDB 特别适用于日志生成速度快且需要实时写入的场景。
查询性能
❝Elasticsearch 提供了最佳的查询性能，受益于其更高的 CPU 利用率和更重的索引功能；GreptimeDB 的调优实例在某些情况下与 ClickHouse 相当，甚至更好。值得注意的是，即使在查询远程 S3 对象存储的数据时，GreptimeDB 的性能仍然相当。
Elasticsearch
Elasticsearch 在全文检索和实时数据索引方面表现出色。它支持复杂查询，例如术语查询、范围查询、聚合查询和地理空间查询。在搜索操作中，即使面对大规模数据集，Elasticsearch 也能在毫秒级返回结果。
然而，在涉及重度聚合或 Elasticsearch 本身并不原生支持的关联查时，其性能会下降。Elasticsearch 通过文档值（doc values）和倒排索引优化查询速度，但在分析型工作负载上，其性能可能不及列式数据库。
ClickHouse
ClickHouse 的查询处理和存储层表现出色，得益于智能合并操作、矢量化查询执行和并行处理等功能，提供了非常均衡的性能。同时，ClickHouse 的架构在底层操作管理方面非常注重细节，确保了系统的高效性和可靠性。这种精细化的设计进一步增强了它在数据处理中的优势。
GreptimeDB
GreptimeDB 的查询引擎基于 Apache DataFusion 构建。DataFusion 提供了功能完善的查询计划器，以及支持列式、流式、多线程和向量化的高效执行引擎，同时还支持分区数据源。这些组件具备极高的扩展性，GreptimeDB 充分利用这些特性，对时间序列场景进行了深度性能优化。
查询接口
❝GreptimeDB 实现了与 PostgreSQL 和 MySQL 协议兼容的 SQL 接口，而 Elasticsearch 使用的是其独有的基于 JSON 的查询语言，ClickHouse 则采用接近 ANSI-SQL 的 SQL 风格语法。
Elasticsearch
Elasticsearch 使用基于 JSON 的 Query DSL 查询语言。虽然功能强大且表达能力丰富，但对习惯使用 SQL 的用户而言，学习成本较高。编写复杂查询需要深入理解 DSL 的结构和功能。例如，一个简单的术语查询在 DSL 中可能是这样的：
{
"query": {
"term": {
"user": "kimchy"
}
}
}
这种查询语言需要较高的学习门槛，尤其是对不熟悉 JSON 的用户而言可能会减缓其使用速度。
ClickHouse
ClickHouse 使用类似标准 ANSI SQL 的查询接口。这种熟悉的语法降低了学习成本，使用户可以直接利用已有的 SQL 知识。ClickHouse 还提供了一些定制的聚合函数，以支持其 OLAP 场景，例如：
SELECT
year,
month,
day,
count(*)
FROM t GROUP BY ROLLUP(year, month, day);
GreptimeDB
GreptimeDB 提供了几乎完全兼容 SQL 的接口。用户可以直接通过 MySQL 或 PostgreSQL 客户端连接 GreptimeDB。
此外，GreptimeDB 还支持 Apache DataFusion 的窗口、标量和聚合函数以及地理空间函数，例如 H3 索引查询：
-- Select all rows from the system_metrics table and idc_info table where the idc_id matches, and include null values for idc_info without any matching system_metrics
SELECT b.*
FROM system_metrics a
RIGHT JOIN idc_info b
ON a.idc = b.idc_id;
-- Encode coordinate (latitude, longitude) into h3 index at given resolution
SELECT h3_latlng_to_cell(37.76938, -122.3889, 1);
第三方集成
ElasticSearch 和 ClickHouse 拥有最成熟的生态系统，提供了丰富的集成选项。而 Greptime 的独特之处在于支持统一的数据库，可以将日志转化为指标，用于处理可观测性信号。
Elasticsearch
作为该比较中最早的项目，Elasticsearch 拥有丰富的合作伙伴和开发者生态系统，他们在其基础上构建了许多工具和服务。不过，Elasticsearch 的一个缺点是，其与 OpenTelemetry 的集成（通过广为人知的 ELK 堆栈）需要额外配置一个名为 Elastic APM 服务器的服务。这个额外的组件能让你与 OpenTelemetry 生态系统直接集成，但也会使整体部署变得更加复杂。
ClickHouse
ClickHouse 也拥有大量核心、第三方以及社区集成。它完全支持 OpenTelemetry，包括日志功能，允许用户通过 OpenTelemetry 对服务进行检测，将日志直接写入 ClickHouse。此外，ClickHouse Cloud 通过其 ClickPipe 功能，支持与 Kafka Broker 的紧密集成。
GreptimeDB
作为较新的产品，GreptimeDB 的集成能力仍在不断扩展，目前已经支持 Prometheus、Grafana、Vector 和 EMQX 等主流观测工具。GreptimeDB 通过捕获指标和日志，为用户提供一个 OpenTelemetry 后端，可以将所有观测信号统一存储。这种能力能够极大简化监控场景下的技术栈。
如何选择适合的解决方案
选择日志管理工具时，需根据组织的具体需求和优先级进行判断：
需要在非结构化数据的搜索场景中实现最快的检索速度，并愿意为此投入更多基础设施预算，Elasticsearch 是不错的选择； 想针对大规模数据集进行高性能的分析查询，并且拥有专门的工程资源来优化表结构，可以选择 ClickHouse； 如果希望降低成本，或通过统一的日志与指标平台简化观测部署，GreptimeDB 的架构及对对象存储的利用将是一个理想选择。
最适合的日志管理解决方案是能够与技术需求、预算和长期观测目标对齐的产品。
Sources
Elastic Storage Resource Requirements: https://www.elastic.co/blog/elasticsearch-storage-the-true-story-2.0
ElasticSearch has a big index: https://serverfault.com/questions/635014/elasticsearch-is-using-way-too-much-disk-space
ElasticSearch Compression config: https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules.html
Compression in ClickHouse: https://clickhouse.com/docs/en/data-compression/compression-in-clickhouse
Clickhouse Design: https://clickhouse.com/docs/en/concepts/why-clickhouse-is-so-fast https://clickhouse.com/docs/en/engines/table-engines/mergetree-family/mergetree
Greptime Mito Engine: https://www.greptime.com/blogs/2023-10-30-mito-engine
Benchmarks: https://greptime.com/blogs/2024-08-22-log-benchmark
Apache Data Fusion: https://datafusion.apache.org/
