数据库对比

概述

参考：

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

原文: https://mp.weixin.qq.com/s/eITHYdw8Qoa0xYozqJZuOw

GreptimeDB 在 v0.9 版本引入了日志存储和检索功能，使得用户可以使用同样数据模型和查询语言（SQL）来统一处理指标、日志（和事件）。

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

测试场景

测试数据和流程

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

129.37.245.88 - meln1ks [01/Aug/2024:14:22:47 +0800] "PATCH /observability/metrics/production HTTP/1.0" 501 33085

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

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

写入方式

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

• 切分模式：将每行日志，切分出多个字段，比如上面这行日志，可以切分出 http_version、ip、method、path、status 等字段。我们同样使用 vector 进行日志的解析和切分；
• 全文模式：将该条日志，除了时间戳以外，完整存储为一个 message 的文本字段，并启用全文索引。

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

软硬件说明

硬件环境

软件版本及设置

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

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

[storage]type = "S3"bucket = "ap-southeast-1-test-bucket"root = "logitem_data"access_key_id = "xxx"secret_access_key = "xxx"endpoint = "endpoint"region = "ap-southeast-1"cache_path = "/home/ubuntu/s3cache"cache_capacity = "20G"[[region_engine]][region_engine.mito]enable_experimental_write_cache = trueexperimental_write_cache_size = "20G"

切分模式设置

Vector 解析配置：

[transforms.parse_logs]type = "remap"inputs = ["demo_logs"]source = '''. = parse_regex!(.message, r'^(?P<ip>\S+) - (?P<user>\S+) \[(?P<timestamp>[^\]]+)\] "(?P<method>\S+) (?P<path>\S+) (?P<http_version>\S+)" (?P<status>\d+) (?P<bytes>\d+)$')# Convert timestamp to a standard format.timestamp = parse_timestamp!(.timestamp, format: "%d/%b/%Y:%H:%M:%S %z")# Convert status and bytes to integers.status = to_int!(.status).bytes = to_int!(.bytes)'''

GreptimeDB 建表语句：

--启用了 append 模式，并且将 user、path 和 status 设置为 Tag 类型（即主键）CREATE TABLE IF NOT EXISTS `test_table` (    `bytes` Int64 NULL,    `http_version` STRING NULL,    `ip` STRING NULL,    `method` STRING NULL,    `path` STRING NULL,    `status` SMALLINT UNSIGNED NULL,    `user` STRING NULL,    `timestamp` TIMESTAMP(3) NOT NULL,    PRIMARY KEY (`user`, `path`, `status`),    TIME INDEX (`timestamp`))ENGINE=mitoWITH(    append_mode = 'true');

ClickHouse 建表语句：

--使用默认 MergeTree 引擎，定义同样的 sorting key。CREATE TABLE IF NOT EXISTS test_table(    bytes UInt64 NOT NULL,    http_version String NOT NULL,    ip String NOT NULL,    method String NOT NULL,    path String NOT NULL,    status UInt8 NOT NULL,    user String NOT NULL,    timestamp String NOT NULL,)ENGINE = MergeTree()ORDER BY (user, path, status);

ElasticSearch 建表语句 (mapping)：

{  "vector-2024.08.19": {    "mappings": {      "properties": {        "bytes": {          "type": "long"        },        "http_version": {          "type": "text",          "fields": {            "keyword": {              "type": "keyword",              "ignore_above": 256            }          }        },        "ip": {          "type": "text",          "fields": {            "keyword": {              "type": "keyword",              "ignore_above": 256            }          }        },        "method": {          "type": "text",          "fields": {            "keyword": {              "type": "keyword",              "ignore_above": 256            }          }        },        "path": {          "type": "text",          "fields": {            "keyword": {              "type": "keyword",              "ignore_above": 256            }          }        },        "status": {          "type": "long"        },        "timestamp": {          "type": "date"        },        "user": {          "type": "text",          "fields": {            "keyword": {              "type": "keyword",              "ignore_above": 256            }          }        }      }    }  }}

全文模式设置

GreptimeDB 建表语句：

--message 列启用 FULLTEXT 选项，开启全文索引CREATE TABLE IF NOT EXISTS `test_table` (    `message` STRING NULL     FULLTEXT WITH(        analyzer = 'English',         case_sensitive = 'false'    ),    `timestamp` TIMESTAMP(3) NOT NULL,    TIME INDEX (`timestamp`))ENGINE=mitoWITH(    append_mode = 'true');

ClickHouse 建表语句：

--同样指定 message 列建立全文索引CREATE TABLE IF NOT EXISTS `test_table` (    `message` STRING NULL     FULLTEXT WITH(        analyzer = 'English',         case_sensitive = 'false'),    `timestamp` TIMESTAMP(3) NOT NULL,    TIME INDEX (`timestamp`))ENGINE=mitoWITH(    append_mode = 'true');

ElasticSearch：

{  "vector-2024.08.19": {    "mappings": {      "properties": {        "message": {          "type": "text",          "fields": {            "keyword": {              "type": "keyword",              "ignore_above": 256            }          }        },        "service": {          "type": "text",          "fields": {            "keyword": {              "type": "keyword",              "ignore_above": 256            }          }        },        "source_type": {          "type": "text",          "fields": {            "keyword": {              "type": "keyword",              "ignore_above": 256            }          }        },        "timestamp": {          "type": "date"        }      }    }  }}

写入性能

不限速写入 1 亿条数据：

• 切分模式下，写入性能上 CH 最佳， GreptimeDB 本地磁盘模式和 S3 模式写入性能相当，都在 12~13 万行每秒左右， ES 最差，并且差距较大，仅为 GreptimeDB 的 1/3， ClickHouse 的 1/4；
• 全文模式下，整体横向对比结论不变，但是写入性能都有所下降，GreptimeDB 下降 25%，ClickHouse 下降 18%，ES 下降 29%，可见全文索引对写入的影响不小。

资源占用和压缩率

资源占用

为了观察写入过程中的资源占用，我们将写入速度限速为 2 万行每秒，然后采集 CPU 和内存占用情况：

可以看到：

• 切分模式下，ClickHouse 的 CPU 消耗最低，GreptimeDB 其次， ES 消耗较高，是 CH 的 6 倍， GreptimeDB 的 1.7 倍，内存上 GreptimeDB 消耗最低， ClickHouse 其次，而 ES 的内存占用超过了 12 G，是 CH 的 21 倍， GrptimeDB 的 32 倍；
• 全文模式下，无论是 CPU 还是内存，都是 GreptimeDB 最优，其次 ClickHouse，ES 仍然是消耗最高的，尤其是内存；
• 测试过程中发现 ClickHouse 的 CPU 波动最大，最高可以到 139%。

这个结果其实跟三者的架构，以及针对优化的场景有关，我们最后再分析。

压缩率

原始 10 亿条数据在 10 GB 大小左右，我们再来看下三者的压缩率：

由于 ClickHouse 和 ES 在写入完成后会持续对数据进行压缩，我们这里同时记录刚写入完成和数据大小不再变化后的数据大小。可以看到：

• 任何模式下， GreptimeDB 的压缩率都是最好的，切分模式下是原始数据的 13%，全文模式下是原始数据的 33%。 ClickHouse 其次，也都比原始数据更小，而 ES 最差，由于索引构建的开销，整体数据都比原始数据更大；
• 切分模式下的压缩率都好于全文模式。 切分模式下，更多的列被提取出来，而 GreptimeDB 存储引擎是列存，因此压缩率更优。

查询性能

查询场景

我们将查询场景区分为 6 个，覆盖比较典型的日志使用场景：

1. Count 统计查询：统计全表数据行数；
2. 关键词匹配查询：匹配日志中的 user、method、endpoint、version、code 分别为特定值；
3. 区间统计查询：使用时间范围统计约一半（5,000 万行）数据量的查询；
4. 中间时间范围查询：取时间中间范围一分钟，并查询 1000 行数据；
5. 最近时间范围查询：取最近时间范围一分钟，并查询 1000 行数据；
6. 关键词匹配 + 区间查询：查询特定时间范围内的字段匹配结果。

GreptimeDB 和 ClickHouse 都使用 SQL 进行查询，前者使用 MySQL 客户端工具，后者使用 CH 自身提供的命令行客户端[2]。

ElasticSearch 我们使用 search 的 REST API[3]。

切分模式查询性能

切分模式下，三者的查询性能大部分都很接近，都可以在 1 秒内完成查询，区间统计查询对于 GreptimeDB 和 ClickHouse 来说都需要扫表，比 ES 差的比较多，我们也在针对这一点做优化。GreptimeDB 在本地磁盘和 S3 模式下的查询性能基本一致。

全文模式查询性能

GreptimeDB 默认的全文索引配置是相对保守的，为了保持稳定的在线写入和查询性能，没有充分利用内存和 CPU。而 ClickHouse 和 ES 都会充分利用内存和索引，因此我们在这个模式下还提供了一个优化配置的结果，我们修改了 GreptimeDB 下列两个配置：

• page_cache_size = “10GB”，增大 SST 的 page cache 大小到 10GB；

• scan_parallelism = 8，扫描 SST 的并行数，默认为 CPU 数的四分之一，调整到 8 以使用所有的 CPU 核心；

• 我们也提供了默认配置下的查询结果:

GreptimeDB 默认配置的查询性能除了最近时间范围查询以外都最差，在修改默认配置后，所有查询耗时都可以在 1.6 秒内完成，部分查询比 CH 更快，比如最常见的关键词匹配+时间区间范围查询。ES 的查询性能最优，较大的内存占用和更优化的索引实现带来来更好的查询性能， CH 表现较为均衡。

GreptimeDB 正在持续优化查询性能，未来预计默认配置将达到与 ClickHouse 相当的水平，敬请期待。

总结

通过测试，我们得出以下结论：

• GreptimeDB 的日志引擎在写入性能、资源占用和压缩率方面表现出色，CH 较为平衡，而 ES 在这些方面表现最差且资源消耗高。
• 查询性能方面，切分模式下 GreptimeDB 与 CH 和 ES 相当。全文模式下，GreptimeDB 表现一般，但优化后可在 1.6 秒内完成大部分查询。ES 查询性能最佳，CH 较为均衡。
• GreptimeDB 在本地磁盘和 S3 对象存储模式下性能基本一致。
• 切分模式（日志结构化）提升了读写性能和压缩率。GreptimeDB 和 ES 都具备 Ingestion Pipeline 功能，可将非结构化文本转换为结构化数据[4][5]。

这个结果其实跟三者面向的场景紧密相关：

1. GreptimeDB 为面向在线的可观测应用而设计，比如智能运维和监控场景，尤其是海量数据，比如车联网或者大规模的监控系统，并且提供了数据直接保存在对象存储的能力。由于在线监控需要持续可用，因此 GreptimeDB 对于资源的使用会相对谨慎和控制，更希望提供稳定 7x24 读写服务，并具备良好的水平扩展能力。
2. ClickHouse 面向离线数仓服务设计，离线数仓很多是 ad hoc 查询或者长时间范围的数据分析，对查询耗时和失败率没有那么敏感，CH 更充分地利用 CPU 和内存等资源。
3. ElasticSearch 专为在线或离线检索业务而设计，具备良好的索引能力和完备的搜索功能（基于优秀的 Apache Lucence 项目），更加激进地使用资源，尤其是内存和磁盘占用，但是相对的，消耗的资源也是最大，写入性能也较差。

简而言之，在海量日志场景下， GreptimeDB 是一个性价比最高的选择，基于云原生架构，可以用更低的资源消耗（CPU、内存和磁盘）来承载大量日志的存储，并且具备优秀的水平扩展能力，但是作为首个版本实现，查询性能相对一般，还需要持续优化。ClickHouse 也是较为优秀的选择，只是 ClickHouse 仍然是传统的分布式架构设计，没有办法充分地利用云的基础设施，尤其是弹性和廉价对象存储。而 ES 则更适合面向在线的搜索业务，对于延时和结果排序更为敏感，日志场景不是合适的选择，资源消耗和写入性能都最差。最后，CH 和 ES 的分布式集群的运维部署都相当繁琐。

GreptimeDB 的日志引擎目前还是第一个版本，我们将持续优化，敬请关注！