交叉联接中的表顺序如何影响性能

时间:2018-08-16 03:14:46

标签: join clickhouse

我有2个表AB,它们都是MergeTree,其中有8192个index_granularity。 当我将cross join应用于2个表时。一般来说,查询喜欢

select
    count(*)
from
(select * from A where ... )
cross join
(select * from B where ...)
where ...;
  • 原始表:A314307856条记录,B909470
  • 过滤掉:A6599条记录,B14860。 (尽管记录差异很大,但两个过滤器都非常快)

在查询中切换AB的顺序时,我注意到性能存在巨大差距。

  • A cross join B1 rows in set. Elapsed: 12.242 sec. Processed 26.72 million rows

  • B cross join A1 rows in set. Elapsed: 45.584 sec. Processed 26.72 million rows

两个订单都有pipeline

CreatingSets
 Lazy
 Expression
  Expression
   ParallelAggregating
    Expression × (num_parts)
     Filter
      Expression
       Expression
        Expression
         Filter
          MergeTreeThread

有时候,B cross join A拥有

CreatingSets
 Lazy
 Expression
  Expression
   Aggregating
    Concat
     Expression
      Filter
       Expression
        Limit
         Expression
          Union
           Limit × 7
            Expression
             Filter
              MergeTreeThread

->我注意到clickhouse-server将通过此管道非常迅速地耗尽内存。

据我所知,通过join查询,clickhouse将首先在右边执行,然后将其放入内存,然后在左边执行。以我为例,过滤出的AB绝对适合内存。

我的问题是:

  • 为什么2个查询的性能差异很大? 2个表的顺序如何影响查询性能?选择订单时的一些建议。

  • 同一查询在多次执行中管道可以不同吗?

更新1: 有关我的查询的更多信息

SELECT 
    count(*)
    FROM 
    (
          SELECT 
            ...
        FROM B 
        WHERE (((day >= '2018-08-15') AND (day <= '2018-08-16')) AND ((timestamp >= 1534310226442) AND (timestamp <= 1534399065648))) AND (log_time <= 1534316318187)
    ) 
    CROSS JOIN 
    (
      SELECT 
            ...
        FROM A
        WHERE (((day >= '2018-08-14') AND (day <= '2018-08-16')) AND ((timestamp >= 1534223826442) AND (timestamp <= 1534399065648))) AND (log_time <= 1534316318187) AND match(..., '...') 
    ) 
    WHERE position(..., ...) > 1

1 个答案:

答案 0 :(得分:2)

  1. 目前,ClickHouse没有基于成本的优化器来自动交换表,如果这是实现相同结果的更有利的方法。首先存在这种差异的原因可能有很多,例如更好的处理器缓存利用率或在进行WHERE丢弃之前进行额外的工作。性能自省功能目前正在合并到ClickHouse master中,并且将在以后的版本中使用,目前更深入的研究主要限于perf / strace / dstat / etc等常规linux工具集。根据建议,您可以通过衡量最适合自己情况的最正确的方法来做正确的事,不要盲目相信任何人的建议。
  2. ClickHouse或多或少是确定性的,因此对于固定查询,它不应更改。您能否提供一种重现此方法的方法?