Clickhouse上用Order By保证绝对正确结果但代价是性能

2022-03-25 17:01:06 阅读：255 来源： 互联网

标签：request Order step 上用 select events 查询 id Clickhouse

一些聚合函数的结果跟流入数据的顺序有关，CH文档明确说明这样的函数的结果是不确定的。这是为什么呢？让我们用explain pipeline来一探究竟。

以一个很简单的查询为例：

select any( step ) from events group by request_id;

events表的定义如下：

CREATE TABLE default.events
(
    `ID` UInt64,
    `request_id` String,
    `step_id` Int64,
    `step` String
)
ENGINE = MergeTree
ORDER BY ID

该查询从events表里面读取数据步骤 step 和请求ID request_id ，按照request_id分组并取第一个step。

我们看一下这个查询的pipeline：

localhost :) explain pipeline select any( `step`) from events group by request_id

┌─explain────────────────────────────────┐
│ (Expression)                           │
│ ExpressionTransform                    │
│   (Aggregating)                        │
│   Resize 32 → 1                        │
│     AggregatingTransform × 32          │
│       StrictResize 32 → 32             │
│         (Expression)                   │
│         ExpressionTransform × 32       │
│           (SettingQuotaAndLimits)      │
│             (ReadFromMergeTree)        │
│             MergeTreeThread × 32 0 → 1 │
└────────────────────────────────────────┘

可以看出没有sorting步骤。这个查询在多核服务器中速度是相当快的，因为充分利用了多核，直到最后一步才归并成一个数据流由一个线程来处理。

可是要注意 这个查询的结果每次都不一样，可以用加过滤条件的计数来测试，测试的SQL如下：

select countIf(A='step1') from (select any( `step`) as A from (select * from events) group by request_id)

结果是：2500579， 2500635，2500660。结果差距都不大，但都不是绝对正确的结果。这是因为多线程执行时并不能严格保证是按照engine=MergeTree 的表的存储顺序来处理数据的。如果能容忍误差就没问题，因为这个查询的效率是非常高的。

但如果要追求绝对的正确结果。则需要显示地指定顺序，改造查询如下：

select any( step ) from (select * from events order by ID) group by request_id;

查询的pipeline变成这样：

localhost :) explain pipeline select any( step ) from (select * from events order by ID) group by request_id;

┌─explain─────────────────────────────────┐
│ (Expression)                            │
│ ExpressionTransform                     │
│   (Aggregating)                         │
│   AggregatingTransform                  │
│     (Expression)                        │
│     ExpressionTransform                 │
│       (Sorting)                         │
│       MergingSortedTransform 36 → 1     │
│         (Expression)                    │
│         ExpressionTransform × 36        │
│           (SettingQuotaAndLimits)       │
│             (ReadFromMergeTree)         │
│             MergeTreeInOrder × 36 0 → 1 │
└─────────────────────────────────────────┘

注意到pipeline中增加了重要的一步MergingSortedTransform 36 → 1 ，这一步保证了查询的正确性，但是将多个线程的数据流归集到一起，排序后继续由一个线程完成剩下的处理步骤，效率上受到很大的影响。测试结果表示：加了ORDER BY 子句的查询能够得到一致的正确结果，但效率差了至少10倍。越是核数多的服务器，其差距越大。

标签：request,Order,step,上用,select,events,查询,id,Clickhouse
来源： https://www.cnblogs.com/chengxin1985/p/16055559.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9

Clickhouse上用Order By保证绝对正确结果但代价是性能