【问题标题】:How to speed up big query in ClickHouse?如何加快 ClickHouse 中的大查询?
【发布时间】:2020-05-06 10:23:52
【问题描述】:

背景:

我在 ClickHouse 中提交了一个本地查询(不使用缓存),它处理了 41443 万行,42.80 GB。 查询持续了 100 多秒。 我的 ClickHouse 实例安装在 AWS c5.9xlarge EC2 和 12T st1 EBS 上

在此查询期间,IOPS 最多为 500,读取的 throughput 最多为 20M/s。 作为比较,st1 EBS max IOPS500 和 max throughput500M/s

这是我的问题:

  1. 500IOPS 是否真的限制了我的查询(文件读取)速度? (不管缓存)我应该将 EBS 卷类型更改为 gp2 还是 io1 以增加 IOPS
  2. 在相同的IOPS下有什么设置可以提高throughput? (如我所见,实际上离天花板很远) 我尝试增加'max_block_size' 以一次读取更多文件,但它似乎不起作用。
  3. 如何延长缓存时间?大查询需要几分钟。缓存需要几秒钟。但缓存似乎不会持续很长时间。
  4. 如何预热色谱柱以满足所有要求?请显示 sqls。

【问题讨论】:

    标签: performance clickhouse throughput


    【解决方案1】:

    500 IOPS 真的会限制我的查询(文件读取)速度吗?

    是的

    我应该将 EBS 卷类型更改为 gp2 还是 io1 以提高 IOPS?

    是的

    在相同的IOPS下,有没有什么设置可以提高吞吐量?

    调整 max_bytes_to_read

    减少列数(在选择中)

    减少零件数量(在选择中)

    如何延长缓存时间?

    min_merge_bytes_to_use_direct_io=1

    如何预热色谱柱以满足所有要求?请显示sqls。

    select a,b,c,d from T Format Null

    【讨论】:

    • 作为参考,我查询的表包含数千个分区(目前为2k)。我发现max_bytes_to_read 默认设置为 0,这意味着没有限制。我试图改变它的值,但发现性能没有显着变化。这是否意味着我的查询产生如此低的吞吐量只是因为有太多部分并且它不符合max_bytes_to_read 限制
    • 可能我将max_bytes_to_read 与另一个参数混淆了。我记得 CH 读取 1MB 缓冲区。但是您的目标不是吞吐量。是的,2k 零件可能是来自 500IPS 限制的压力的原因。部分可能太小,CH 执行更多的 IO 操作来读取许多文件而不是一个文件。尝试用另一个分区重建表。
    猜你喜欢
    • 1970-01-01
    • 2015-09-14
    • 2018-08-12
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-04-29
    • 2019-06-22
    相关资源
    最近更新 更多