日志（Log）在监控运维和数据分析的场景中发挥着关键作用。在线系统的问题诊断、用户的行为分析、广告的点击统计和边缘 IoT 设备的监控等都高度依赖日志数据，日志通常包括服务器日志、应用程序日志和安全记录等。然而，日志的数据量相对庞大，一个中大型客户每天的日志规模可达 TB 至 PB 级别。如何高效、实时地处理日志，已成为 IT 系统中一个亟需解决的问题。
ClickHouse 是国内外企业日志系统存储的主要选择之一，同时涵盖 Traces（即链路数据）这样“特殊”的日志。在海量日志场景中，其压缩率与高性能均可较好地取代 ELK（Elasticsearch）生态。GreptimeDB 自 2024 年起着手日志处理引擎的研发，近期于 ClickHouse 官方评测 JSONBench 中获得 Cold Run 第一、Hot Run 第四的卓越成绩。本文将对两个系统在日志场景下的功能/性能差异进行剖析，为用户的日志系统选型提供参考。
核心差异：通用 OLAP 和专为可观测设计
ClickHouse 是一款通用的 OLAP 数据库，能够高效地处理多种分析查询。在日志分析、金融处理以及物联网场景中，它凭借灵活的设计和成熟的 SQL 生态系统表现亮眼。
另一方面，GreptimeDB 是一款针对可观测性数据设计的云原生数据库，非常适用于可观测性数据、指标记录和实时监控工作负载，其架构针对高频率、时间戳数据（例如指标和事件）的摄入和查询进行了优化。
核心特性对比
| 产品 | ClickHouse | GreptimeDB |
|---|---|---|
| 数据模型 | ||
| 性能 | ||
| 可扩展性 | ||
| 功能 | ||
| 成本效率 | 存算分离，基于对象存储提效 | |
| 生态兼容 | ||
| 社区支持 |
日志系统特性对比
以上是核心的特性对比，日志场景下我们还关注以下维度的对比：
| 产品 | ClickHouse | GreptimeDB |
|---|---|---|
| 可视化 | ||
| Elasticsearch API 兼容性 | ||
| 日志 ETL | ||
| 日志转指标 | ||
| 结构化与非结构化日志 | 开启后写入性能影响较大，存储空间占用较大 | |
| Traces 写入和查询 |
性能分析
两者之间的性能差异可以参见下图，更详细的数据请参考：《写入性能跃升 67.5%，存储成本锐减 50%｜GreptimeDB v0.12 日志场景性能测试发布》。
| 产品 | GreptimeDB | ClickHouse |
|---|---|---|
| 版本 | ||
| 数据模型 | ||
| 写入性能（TPS） | ||
| 写入吞吐比例（HTTP 协议） | ||
| 查询性能（结构化数据） | ||
| 查询性能（非结构化数据） | ||
| 存储压缩率 | ||
| 资源占用（CPU %） | ||
| 资源占用（内存 MB） | ||
| 对象存储支持（S3） |
简而言之，GreptimeDB 的读写性能与 ClickHouse 表现相当，在压缩率和资源占用上略有优势。尤其值得强调的是在使用对象存储下，性能几乎不下降。
与其同时，GreptimeDB 在 ClickHouse 官方推出的 JSONBench[1]中的表现验证了其处理海量数据集的竞争力，性能与 ClickHouse 和 VictoriaLogs 处于同一梯队。10 亿级别的 Cold Run 斩获第一，Hot Run 前四：
可扩展性对比
可扩展性往往是用户决定数据库选择的关键因素，而 ClickHouse 与 GreptimeDB 在这方面的处理方法大不相同。
配置复杂的扩展能力：ClickHouse
ClickHouse 支持通过分片和复制进行水平扩展，也支持垂直扩展。然而，水平扩展的实现需要手动配置，包括添加节点和重新平衡数据，这在集群规模扩大时可能变得复杂。尽管 ClickHouse Cloud 的自动扩展选项在一定程度上减少了维护成本，但与 GreptimeDB 已开源的弹性扩展相比仍显局限。
无缝弹性扩展：GreptimeDB
作为云原生数据库，GreptimeDB 采用了计算与存储分离的架构。它基于 Kubernetes 进行部署，可实现无缝的弹性扩展，非常适合云环境。资源独立扩展支持更高的成本效率和灵活性，确保高需求场景下性能稳定；无需手动干预的设计是 GreptimeDB 在观测性和物联网特定场景中的显著优势。
存算分离架构
针对存算分离架构，我们再做一些额外讨论（更多 GreptimeDB 存算分离相关，请阅读这篇文章：《GreptimeDB 存储架构深度剖析：JSONBench 榜单第一背后的秘密》）。
ClickHouse 尽管也可以将数据放在 S3 这样的对象存储上[2]，但是这套架构存在一些问题：
首先，扩容仍然需要复制（数据既然已经放在 S3 上，复制完全是多此一举的行为）导致扩容较为繁琐和困难，也造成了存储资源浪费。尽管有 Zero-copy replication[3]，但是当前仍然存在较多 Bug[4]，不推荐使用。事实上 ClickHouse 官方推荐的是不开源的 SharedMergeTree[5]。
其次，ClickHouse 仅仅是将数据放在了对象存储上，文件目录、表结构等元信息还是基于本地存储和 Zookeeper 做复制，这就导致元信息在对象存储和本地存储之间难以保持同步的问题，也存在较多的 Bug 和元信息存储的扩展性问题。相反， GreptimeDB 仅将表的元信息存储在 Metasrv，而数据文件的元信息则放在了对象存储上。
| 产品 | ClickHouse | GreptimeDB |
|---|---|---|
| 扩展方式 | ||
| 云端支持 | ||
| 存算分离架构 | ||
| 元信息管理 | ||
| 适用场景 |
决策指导
选择 ClickHouse 或 GreptimeDB 主要取决于具体的工作负载需求：
适合选择 ClickHouse 的场景👇
多领域的广泛分析查询； 需要成熟的社区支持和丰富文档； 通用 OLAP 工作负载与监控数据分析结合的场景。
适合选择 GreptimeDB 的场景👇
高频率、带时间戳的数据（例如指标、日志等可观测性数据）； 云原生架构中需要弹性扩展及成本优先的场景； 工作负载需要 PromQL 集成及与 Prometheus 等监控工具配合使用。
结论
ClickHouse 是一款强大的通用 OLAP 数据库，具备多功能性、出色的性能以及庞大的社区生态。与此同时，GreptimeDB 在可观测性场景中更具优势，能够提供高效的数据存储、优化的摄取速度以及特别针对监控和 IoT 工作负载的可扩展解决方案。两者均为开源解决方案，为用户提供灵活性，但数据库选型需根据数据特性、扩展需求和预算约束来决定。
Reference
[1] https://jsonbench.com/
[2] https://altinity.com/blog/clickhouse-mergetree-on-s3-intro-and-architecture
[3] https://clickhouse.com/docs/operations/storing-data#zero-copy
[4] https://github.com/ClickHouse/ClickHouse/labels/comp-s3
[5] https://clickhouse.com/blog/clickhouse-cloud-boosts-performance-with-sharedmergetree-and-lightweight-updates#zero-copy-replication-does-not-address-the-challenges
关于 Greptime
Greptime 格睿科技专注于为可观测、物联网及车联网等领域提供实时、高效的数据存储和分析服务，帮助客户挖掘数据的深层价值。目前基于云原生的时序数据库 GreptimeDB 已经衍生出多款适合不同用户的解决方案，更多信息或 demo 展示请联系下方小助手（微信号：greptime）。
欢迎对开源感兴趣的朋友们参与贡献和讨论，从带有 good first issue 标签的 issue 开始你的开源之旅吧～期待在开源社群里遇见你！添加小助手微信即可加入“技术交流群”与志同道合的朋友们面对面交流哦～
Star us on GitHub Now: https://github.com/GreptimeTeam/greptimedb
官网：https://greptime.cn/
文档：https://docs.greptime.cn/
Twitter: https://twitter.com/Greptime
Slack: https://greptime.com/slack
LinkedIn: https://www.linkedin.com/company/greptime/
往期精彩文章：
点击「阅读原文」，立即体验 GreptimeDB！
