前言
数据库作为产品架构的重要组成部分，一直是技术人员做产品选型的考虑因素之一。
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等。如果你有想看的数据库测试，也可以私信我们（扫描下方二维码，添加好友）。
