数据库测试|Elasticsearch 和 ClickHouse 的对决
![数据库测试|Elasticsearch和ClickHouse的对决](https://static001.geekbang.org/infoq/59/598ec60d0e338b4258329b93a34836fa.png)
前言
数据库作为产品架构的重要组成部分,一直是技术人员做产品选型的考虑因素之一。
ClkLog会经常遇到小伙伴问支持兼容哪几种数据库?为什么是选择 ClickHouse 而不是这个或那个。
由于目前市场上主流的数据库有许多,这次我们选择其中一个比较典型的 Elasticsearch 来和 ClickHouse 做一次实战测试,让大家更直观地看到真实的比对数据,从而对这两个数据库有更深入的了解,也就能理解为什么我们会选择 ClickHouse。
比较 Elasticsearch 和 ClickHouse,就像比较苹果和香蕉。两者都是很好的东西,有相似的功效,很多情况下都可以相互替代,同时各有特点,无法给出简单谁强谁弱的结论。
ClickHouse 是为 OLAP 而生的,而 Elasticsearch 更早面世,也经常被用于生成统计报表。所以,我们将在这个交叉领域做实际测试,以便更好地做出决策。
先看测试结果
省流版测试比对结果,见下图。
![](https://static001.geekbang.org/infoq/5b/5b87451b4cea03f760061af2e31570e3.png)
如果你有兴趣了解详细的测试过程与结论,那就接着往下看吧。
概述
Web 访问日志是最常见的日志之一,有基本统一的共识,比较适合作为测试数据。
测试将从 CPU、内存、存储、延迟等方面对比,服务器采用单节点部署形式,减少变量。
测试环境
● 硬件配置(最低要求配置)
CPU:4 核心
内存:16GB
磁盘:100GB SSD
● 数据集:模拟生成的 Web 访问日志,共计 1 千万条记录
● 网络环境:局域网
采用 Docker Compose 创建服务器环境
![](https://static001.geekbang.org/infoq/46/46c895e0cd1f2c5e012e70914d4c6745.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
![](https://static001.geekbang.org/infoq/a6/a60a5aa6bf580c98487aa2d58acdf149.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
使用以下 Python 脚本生成日志文件:
![](https://static001.geekbang.org/infoq/e2/e222bc31b50283267c297e687c0c6496.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
![](https://static001.geekbang.org/infoq/5d/5d8245bfcc5ec765bf43a0d0e6cd9ac7.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
![](https://static001.geekbang.org/infoq/e0/e0d025049fd1d73b4d9e105143b7ae64.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
![](https://static001.geekbang.org/infoq/70/70cec7175bae1780edaf9557a0da3295.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
日志文件参考大小为 2.8G。
数据导入速度
测试数据集将包含大量的 Web 访问日志,以模拟实际应用场景中的数据流入情况。我们将比较在相同硬件环境 下,Elasticsearch 和 ClickHouse 在数据导入速度上的表现。
使用 vector 读取日志文件,解析并发送到 Elasticsearch 和 ClickHouse,配置如下:
![](https://static001.geekbang.org/infoq/05/05edfbb79b2161bf657e0ee5e1a6a5c8.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
![](https://static001.geekbang.org/infoq/f8/f8969e3f1b20787e44f62db826b799cc.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
注意,测试时 sinks 部分应该只保留当前的测试对象,避免互相干扰。
✓ Elasticsearch 导入速度如下图所示:
![](https://static001.geekbang.org/infoq/8b/8bab435c77b054979fee26857571399a.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
导入 1 千万条访问日志,花费 12 分钟 18 秒,平均 13550 条每秒。
在导入过程中,Vector 没有告警信息。已对导入结果检查,日志数量没有问题。
✓ 测试 ClickHouse 导入前,需要预先创建表:
![](https://static001.geekbang.org/infoq/5a/5a8aa92aea87bd1ddac634e70712080a.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
![](https://static001.geekbang.org/infoq/a3/a3f9d9f0a301b7f5d594e1ecfe697904.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
ClickHouse 导入速度如下图所示:
![](https://static001.geekbang.org/infoq/c3/c32d4912a03bc878786f36c8a2bf6c8b.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
导入 1 千万条访问日志,花费 8 分 10 秒,平均 20408 条每秒。
在导入过程中,Vector 有告警信息。已对导入结果检查,日志数量没有问题。
![](https://static001.geekbang.org/infoq/f9/f92592d44174c71790ac2aead522d5e0.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
资源占用(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 毫秒,使用以下查询:
![](https://static001.geekbang.org/infoq/c3/c3506dd5bdf74067ea7548b38fd8fdba.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
![](https://static001.geekbang.org/infoq/f1/f1e1c4877a9d37ccfc538d0034a2dfe2.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
✓ ClickHouse 花费 500 毫秒,使用以下 SQL 脚本:
![](https://static001.geekbang.org/infoq/29/29ecc880e2e7f08bf8f922238a94c08d.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
● 场景 2
对这 1 千万条 Web 访问日志,查询耗时>=1 秒的次数前 10 的路径,包含路径、总次数、最⼤耗时、平均耗时、超 1 秒的次数。
✓ Elasticsearch 花费 7000 毫秒,使用以下查询:
![](https://static001.geekbang.org/infoq/9b/9b8c67510eb3ca00cca9f627b6ad3167.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
✓ ClickHouse 花费 300 毫秒,使用以下 SQL 脚本:
![](https://static001.geekbang.org/infoq/d9/d92392572ee70eec70c134e811ad33c0.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
总结
通过以上几个方面的测试,我们将全面对比 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 等。如果你有想看的数据库测试,也可以私信我们(扫描下方二维码,添加好友)。
![](https://static001.geekbang.org/infoq/67/67ff0e0f2d2837d696d22c75c3ebfb76.png)
评论