ClickHouse是用于分析的OLAP数据库,因此典型的使用场景是处理相对较少的请求 — 从每小时几个到每秒几十甚至几百个不等 — 但会影响到大量数据(几GB/数百万行)。
但是在其他情况下,它的表现如何?让我们尝试用大量小请求来测试ClickHouse如何处理。这将帮助我们更好地了解可能的使用场景范围和限制。
本文分为两个部分:
- 连接基准测试和测试设置
- 涉及实际数据的最大QPS的场景
环境
对于初始测试,我选择了一台旧工作站:
- 4核 Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz
- 8GB RAM
- SSD硬盘
- CentOS 7
本文中呈现的结果是从该计算机收集的,但当然,很有趣的是在更强大的硬件上重复这些测试。我把这项任务交给我们的读者,这样你就可以在自己的硬件上测试ClickHouse在不同场景下的最大QPS。如果你这样做了,请分享你的结果!为了运行基准测试,我还创建了一组脚本,可以在Altinity的GitHub上免费获取:https://github.com/Altinity/clickhouse-sts/。这些脚本需要Docker(我使用的是v18.09)和Bash。要运行测试套件,只需克隆GitHub存储库,并在根文件夹中运行‘make test’命令。它会在你的主机上执行所有测试(需要几个小时),并将结果放入一个CSV文件中,稍后可以在Excel、Pandas或ClickHouse本身中进行分析。当然,你也可以分享你的发现,以便与本文中的结果进行比较。
这些脚本使用了以下工具:
- https://github.com/wg/wrk,一个轻量级且快速的HTTP基准测试工具,允许创建不同的HTTP工作负载
- ClickHouse发行版中包含的clickhouse-benchmark工具,用于本地协议ClickHouse测试
这两个工具都允许你创建所需并发量的负载(模拟不同数量的并发客户端),并测量每秒处理的查询数和延迟百分位数。
关于ClickHouse处理并发请求的几点说明
默认情况下,ClickHouse可以处理高达4096个入站连接(max_connections在服务器配置文件中设置),但只会同时执行100个查询(max_concurrent_queries),因此所有其他客户端将在队列中等待。客户端请求可以保持在队列中的最长时间由queue_max_wait_ms设置定义(默认为5000或5秒)。这是一个用户/配置文件设置,因此用户可以定义较小的值,在队列过长的情况下提示异常。http连接的长连接超时默认相对较短 — 3秒(keep_alive_timeout设置)。
还有许多高级网络相关设置,用于微调不同的超时、轮询间隔、监听回溯大小等设置。
HTTP ping:HTTP服务器的理论最大吞吐量
首先,让我们检查ClickHouse自身使用的HTTP服务器有多快。换句话说,服务器可以处理多少个“无所事事”的请求。
对于HTTP,两种主要情况很重要:
- 使用保持连接(保持持久连接进行多个请求,而无需重新连接)
- 不使用保持连接(每个请求都建立新连接)
此外,默认情况下ClickHouse的日志级别非常详细(‘trace’)。对于每个查询,它会向日志文件写入几行,这对于调试很好,但当然会增加一些额外的延迟。因此,我们还要检查禁用日志的相同2种场景。
我们对不同并发级别进行了测试,以模拟不同数量的同时连接的客户端(一个接一个地发送请求)。每个测试执行15秒,然后取每秒处理的平均请求数。
结果:
在X轴上,您可以看到同时连接的客户端数。在Y轴上,我们有每个特定场景中每秒处理的平均请求数。
好吧,结果看起来不错:
- 在每个场景中,在8到64个并发连接之间,QPS的最大值都在那台机器上。
- 最大吞吐量约为97K QPS,启用保持连接并禁用日志。
- 启用日志时,速度要慢大约30%,大约为71K QPS。
- 两个不使用保持连接的变体要慢得多(约为18.5 kqps),甚至在这里看不出日志开销。这是预期的,因为使用保持连接,ClickHouse肯定可以处理更多的ping,因为跳过了为每个请求建立连接的额外成本。
现在我们对最大理论可能吞吐量有了感觉,以及ClickHouse Web服务器可以实现的并发级别。实际上,ClickHouse的HTTP服务器实现相当快。例如,NGINX在相同的机器上使用默认设置大约可以提供30K每秒。
SELECT 1
让我们再进一步,检查一个微不足道的 ‘SELECT 1’ 请求。这样的查询在查询解析阶段被‘执行’,因此这将展示‘网络 + 授权 + 查询解析器 + 格式化结果’的理论最大吞吐量,即真实请求永远不会更快。
我们将测试使用保持连接和不使用保持连接的http和https选项,以及本地客户端(安全和非安全)。
结果如下:
这些结果与简单的ping相比显示了相当大的降级。我们得到了:
- 最佳情况下约为14K QPS:http & 保持连接。
- https & 保持连接情况稍差(13K QPS)。在这种情况下,https的开销并不显著。
- http 不使用保持连接时约为10.7 kqps。
- 本地客户端(不安全)约为10.1 kqps。
- 本地客户端(安全)约为9.3 kqps。
- 无保持连接的https表现相当差,约为4.3 kqps。
在最高并发级别上,我们注册了几十个连接错误(即少于0.01%),这很可能是由于操作系统层面的套接字重用问题引起的。ClickHouse在该测试中表现稳定,我没有注册到任何明显的问题。
本地协议显示的性能比http更差可能会让人惊讶,但实际上这是预期的:本地TCP/IP更加复杂,具有许多额外的协议特性。它不适合高QPS,而是适合传输大块数据。
此外,在本地客户端中,随着并发性增加,QPS会出现相当大的下降,在更高的并发级别(>3000)时系统会变得不响应并返回无结果。这很可能是由于clickhouse-benchmark工具为每个连接使用一个单独的线程,线程数和上下文切换过多导致的。
现在让我们看看延迟,即每个客户端等待答案的时间。这个数字在每个请求中会有所变化,因此图表显示了每种情况下延迟的90th percentile。这意味着90%的用户得到的答案比显示的数字更快。
延迟(90th percentile)– 1-256 并发级别
随着并发性的增长,延迟的恶化是可以预料的。目前看起来非常不错:如果您少于256个并发用户,您可以期望延迟在50毫秒以下。
让我们看看高并发性会如何影响。
延迟(90th percentile)– >256 并发级别
现在延迟的恶化更为显著,而且本地协议再次显示出最差的结果。
有趣的是,不使用保持连接的http请求表现非常稳定,并且即使有2K并发用户,延迟也低于50ms。没有保持连接时,延迟更加可预测,并且标准差在并发性增加时保持较小,但QPS会略有降低。这可能与Web服务器的实现细节有关:例如,当使用每个连接一个线程时,线程上下文切换可能会减慢服务器速度,并在一定并发级别后增加延迟。
我们还检查了其他设置,如max_concurrent_queries、queue_max_wait_ms、max_threads、network_compression_method、enable_http_compression以及一些输出格式。在这种情况下调整它们的影响大多是可以忽略的。
多线程的影响
默认情况下,ClickHouse使用多个线程处理更大的查询,以有效利用所有CPU核心。
然而,如果您有大量并发连接,多线程将会增加上下文切换、重新加入线程和工作同步方面的额外成本。
为了衡量并发连接与多线程之间的相互作用,让我们来看一下使用默认多线程设置和max_threads=1设置进行的合成选择,以找到最大的100K个随机数的差异。
结论非常简单:在高并发场景中实现更高的QPS,使用max_threads=1设置。
未完待续…
本文涵盖了对ClickHouse的一般连接性测试。我们检查了服务器本身的速度有多快,它可以处理多少简单查询以及哪些设置会影响高并发场景下的QPS。请查看后续文章,我们将深入估算在键值场景中实际查询的最大QPS,这将为测试案例添加数据。
关注我,紧跟本系列专栏文章,咱们下篇再续!
作者简介:魔都技术专家兼架构,多家大厂后端一线研发经验,各大技术社区头部专家博主。具有丰富的引领团队经验,深厚业务架构和解决方案的积累。
负责:
- 中央/分销预订系统性能优化
- 活动&优惠券等营销中台建设
- 交易平台及数据中台等架构和开发设计
目前主攻降低软件复杂性设计、构建高可用系统方向。
参考:
Redis 不再“开源”,未来采用 SSPLv1 和 RSALv2 许可证 Oracle 正式发布 Java 22 马斯克开源 Grok Java 22 GA 发布 Ubuntu 24.04 LTS 官方壁纸揭晓 C++ 之父反驳白宫观点 微软推出 Sudo for Windows 并开源 苹果“有毒”——甲骨文警告新版 macOS 导致 Java 意外终止 Node.js 新版官网正式上线 微软开源远程缓存存储系统 Garnet:基于 .NET 技术栈、支持接入 Redis 客户端本文由博客一文多发平台 OpenWrite 发布!