数据库测试｜Elasticsearch 和 ClickHouse 的对决

前言

数据库作为产品架构的重要组成部分，一直是技术人员做产品选型的考虑因素之一。

ClkLog会经常遇到小伙伴问支持兼容哪几种数据库？为什么是选择 ClickHouse 而不是这个或那个。

由于目前市场上主流的数据库有许多，这次我们选择其中一个比较典型的 Elasticsearch 来和 ClickHouse 做一次实战测试，让大家更直观地看到真实的比对数据，从而对这两个数据库有更深入的了解，也就能理解为什么我们会选择 ClickHouse。

比较 Elasticsearch 和 ClickHouse，就像比较苹果和香蕉。两者都是很好的东西，有相似的功效，很多情况下都可以相互替代，同时各有特点，无法给出简单谁强谁弱的结论。

ClickHouse 是为 OLAP 而生的，而 Elasticsearch 更早面世，也经常被用于生成统计报表。所以，我们将在这个交叉领域做实际测试，以便更好地做出决策。

先看测试结果

省流版测试比对结果，见下图。

如果你有兴趣了解详细的测试过程与结论，那就接着往下看吧。

概述

Web 访问日志是最常见的日志之一，有基本统一的共识，比较适合作为测试数据。

测试将从 CPU、内存、存储、延迟等方面对比，服务器采用单节点部署形式，减少变量。

测试环境

●  硬件配置（最低要求配置）

CPU：4 核心

内存：16GB

磁盘：100GB SSD

● 数据集：模拟生成的 Web 访问日志，共计 1 千万条记录

● 网络环境：局域网

采用 Docker Compose 创建服务器环境

使用以下 Python 脚本生成日志文件：

日志文件参考大小为 2.8G。

数据导入速度

测试数据集将包含大量的 Web 访问日志，以模拟实际应用场景中的数据流入情况。我们将比较在相同硬件环境 下，Elasticsearch 和 ClickHouse 在数据导入速度上的表现。

使用 vector 读取日志文件，解析并发送到 Elasticsearch 和 ClickHouse，配置如下：

注意，测试时 sinks 部分应该只保留当前的测试对象，避免互相干扰。

✓ Elasticsearch 导入速度如下图所示：

导入 1 千万条访问日志，花费 12 分钟 18 秒，平均 13550 条每秒。

在导入过程中，Vector 没有告警信息。已对导入结果检查，日志数量没有问题。

✓ 测试 ClickHouse 导入前，需要预先创建表：

ClickHouse 导入速度如下图所示：

导入 1 千万条访问日志，花费 8 分 10 秒，平均 20408 条每秒。

在导入过程中，Vector 有告警信息。已对导入结果检查，日志数量没有问题。

资源占用（CPU 和内存）

资源占用是评价系统性能的重要指标。我们将监控在数据导入过程中，Elasticsearch 和 ClickHouse 的 CPU 和内存使用情况。

✓ Elasticsearch 在导入过程中，CPU 占用约 70%，内存占用 8GB，导入结束后内存维持占用。

✓ ClickHouse 在导入过程中，CPU 占用 100%，导入过程中及导入结束后内存占用均维持在 2GB 左右。缓存占用， 导入前为 3GB，导入过程中缓存占用逐步上升，导入结束时达到最大值 12GB 左右，之后逐步下降，最终恢复为 3GB。

存储需求

存储需求直接影响系统的扩展性和成本。我们将比较 Elasticsearch 和 ClickHouse 在存储相同数据集时的存储占用情况，以及两者在数据压缩和存储优化方面的表现。

导入 1 千万条 Web 访问日志后：

✓ Elasticsearch 数据占用存储空间约为 3.1GB。在导入过程中占用存储空间逐渐稳定上升。

✓ ClickHouse 数据占用存储空间约为 1.1GB。注意，在导入过程中占用存储空间一度观察到达到 19GB 左右（导入结束时），在之后花费约 10 分钟逐步收缩到最终大小。

查询延迟

查询延迟是用户体验的重要指标。我们将测试 Elasticsearch 和 ClickHouse 在处理不同复杂度查询时的延迟表现，包括简单查询和复杂聚合查询。

● 场景 1

对这 1 千万条 Web 访问日志，按天统计，状态码大于等于 400 的次数前 10 名的路径。

✓ Elasticsearch 花费 1700 毫秒，使用以下查询：

✓ ClickHouse 花费 500 毫秒，使用以下 SQL 脚本：

● 场景 2

对这 1 千万条 Web 访问日志，查询耗时>=1 秒的次数前 10 的路径，包含路径、总次数、最⼤耗时、平均耗时、超 1 秒的次数。

✓ Elasticsearch 花费 7000 毫秒，使用以下查询：

✓ ClickHouse 花费 300 毫秒，使用以下 SQL 脚本：

总结

通过以上几个方面的测试，我们将全面对比 Elasticsearch 和 ClickHouse 在 Web 访问日志统计分析应用中的表现。希望通过这次对比，能够为大家在选择合适的日志分析系统时提供有价值的参考。

总体而言，Elasticsearch 开箱即用，特别是应对种类繁杂的日志时，非常灵活。甚至 web 访问日志这个单一领域，查询参数有很多变化，在写入时建模，省时省力。Elasticsearch 使用一种名为 Query DSL（Domain Specific Language）的查询语言，与大多数工程师、数据分析师熟悉的技术栈差异比较大，设置了较高的学习和使用门槛，并需要学习大量的多新的概念和语法，即使学会之后还需要经常查阅手册才能写出正确的 DSL 语句。ClickHouse 在写入、查询、存储、内存节省方面有明显优势，但需要实现定义表结构，应对字段经常变化的场景维护繁琐。ClickHouse 的查询语言是基于 SQL 的，称为 ClickHouse SQL，工程师和数据分析师对于 SQL 非常熟悉，经验可以复用，不需要学习新的技术栈即可快速上手。

写在最后

从两方面因素考虑。其一，ClkLog 作为用户行为分析系统，需要能够进行大规模的数据存储、繁琐的数据统计与聚合查询，对数据库的性能有比较高的要求。其二，ClkLog 作为开源产品，更多的用户是具有开发能力的个人与公司，可以进行较为复杂的表结构维护。

综上，ClickHouse 更符合 ClkLog 的产品需求与定位。

在数据库选型方面，4 月我们完成了对火山引擎ByConity的兼容性测试，我们将持续进行对 OLAP 类型的数据库测试，类似 Apache Doris、Apache Druid、Amazon Redshift 等。如果你有想看的数据库测试，也可以私信我们（扫描下方二维码，添加好友）。