添加链接
link管理
链接快照平台
  • 输入网页链接,自动生成快照
  • 标签化管理网页链接

欢迎参与 8 月 1 日中午 11 点的线上分享,了解 GreptimeDB 联合处理指标和日志的最新方案! 👉🏻 点击加入

Skip to content
On this page
报告
2024-8-21

GreptimeDB vs. ClickHouse vs. ElasticSearch 日志引擎性能对比报告

GreptimeDB 近期引入了日志存储和检索功能,用户可以使用同样数据模型和查询语言来统一处理指标和日志。本报告测试了 v0.9 首次引入的日志存储和检索的单机性能,并与业内主流方案进行对比。

本报告将初步给出 v0.9 首次引入的日志存储和检索的单机性能,包括写入和查询性能、资源占用和压缩率等。在可观测性领域中,常用的日志系统包括经典的 ELK 组合(ElasticSearch)以及在国内广泛使用的 ClickHouse。我们选择这两个系统进行横向对比,以供参考。GreptimeDB 面向云原生环境设计,因此我们也测试了基于 S3 对象存储的读写性能。

先来看结论:

  1. GreptimeDB 在写入性能、资源占用(CPU、内存和磁盘)方面都表现最优或次优, 并且在本地磁盘和 S3 对象存储模式下,性能表现没有下降 。单机在 8C16G 机器规格下达到 12 万行日志每秒写入,是 ES 的 3 倍,压缩率 13% 最优,内存占用仅为 ES 的 1/32;
  2. ElasticSearch 的资源消耗最大,写入最慢,但是换来的查询性能最优;
  3. GreptimeDB 大部分查询性能和 ClickHouse 接近,能满足日志使用场景。

以上结论跟三个产品面向的场景有关,我们在总结部分展开,下面是详细的测试报告。

测试场景

测试数据和流程

我们选用 nginx access log 作为写入数据,一行数据的样例如下:

我们使用 vector 这个开源可观测数据 pipeline 来生成并写入上面的数据。整体测试的流程如图:

测试流程图

数据写入后,我们分别使用 SQL(GreptimeDB 和 ClickHouse)和 ElasticSearch HTTP 协议进行查询测试。

写入方式

写入方式我们也做了区分:

  • 切分模式(Structured model) :将每行日志,切分出多个字段,比如上面这行日志,可以切分出 http_version ip method path status 等字段。我们同样使用 vector 进行日志的解析和切分;

  • 全文模式(Unstructured model) :将该条日志,除了时间戳以外,完整存储为一个 message 的文本字段,并启用全文索引。

我们也将比较两种模式带来的差异。

软硬件说明

硬件环境

机器规格 操作系统
aws c5d.2xlarge, 8 CPU 16 Gib memory ubuntu 24.04 LTS

软件版本及设置

GreptimeDB v0.9.2
ClickHouse(下文统称 CH) 24.9.1.219
ElasticSearch(下文统称 ES) 8.15.0

如无特殊说明,三个存储都采用 默认配置

GreptimeDB S3 配置,开启了对象存储的读写 Buffer/Cache:

切分模式设置

Vector 解析配置:

GreptimeDB 建表语句:

ClickHouse 建表语句:

ElasticSearch 建表语句 (mapping):

全文模式设置

GreptimeDB 建表语句:

ClickHouse 建表语句:

ElasticSearch: