博客 / 产品

ClickHouse Newsletter 2022 年 5 月刊：Explain Statement – 查询优化

Christoph Wurm

2022 年 5 月 9 日 - 分钟阅读

大家好，热烈欢迎各位。在阿姆斯特丹的 ClickHouse 办公室，这几周非常忙碌——我们启动了 ClickHouse Cloud 服务的私有预览阶段！在接下来的几周和几个月里，加入本次预览的勇敢用户将帮助我们找到并修复所有错误和微小细节，我们希望在今年晚些时候向全世界开放之前将其做好。如果您对 ClickHouse 的无服务器托管服务感兴趣，请在此处加入我们的候补名单 here。

我们还发布了 ClickHouse 22.4、新的文档页面以及新的官方 ClickHouse Grafana 插件。 ClickHouse 22.5 发布网络研讨会的日期已定，并且即将举办一些聚会，所以别忘了在日历上标记出来！

在日历上标记这些活动

ClickHouse v22.5 发布网络研讨会

时间？ 5 月 19 日星期四上午 9 点（太平洋夏令时间），下午 5 点（格林威治标准时间）
如何加入？ 在此注册。

ClickHouse 美洲虚拟聚会

内容？ Gigasheet 正在使用 ClickHouse 构建一款简单的、无需代码的分析产品，具有基于 Web 的电子表格界面。最终能取代 Excel 的产品？此外，我们自己的 Geoff Genz 将分享他在 Comcast 大规模实施 ClickHouse 的历程。必看！
时间？ 5 月 12 日星期四上午 11 点（太平洋标准时间），下午 2 点（美国东部时间）
方式？ 在纽约或西雅图的聚会小组中注册。

ClickHouse EMEA 虚拟聚会

内容？ 金融科技公司 Opensee 将讨论他们如何使用 ClickHouse 在金融机构中提供跨大量数据的自助分析。之后，ClickHouse 的创建者 Alexey 将深入探讨使 ClickHouse 快速运行的内部机制。请准备好您的问题！
时间？ 5 月 12 日星期四下午 1 点（英国夏令时）/ 下午 2 点（欧洲中部夏令时）/ 下午 3 点（东欧夏令时）\
方式？ 在荷兰、法国、伦敦、德国、班加罗尔的聚会小组中注册——或者如果您愿意，可以全部注册！

我们为 ClickHouse 文档页面赋予了新面貌！左侧有新的导航结构，并且还有许多新内容。我们确信至少有一件新事物供您学习

快速入门 快速开始使用 ClickHouse 的最快方法。只需下载、运行、创建表、插入一些数据并查询！
教程带您了解如何将纽约市出租车行程数据集加载到 ClickHouse 中，您可以在其上运行一些有趣的聚合查询，如何使用字典以及如何连接。
连接用户界面 关于如何将 Grafana、Metabase、Superset 和 Tableau 连接到 ClickHouse 的分步指南。
集成关于如何将 ClickHouse 与 Airbyte、dbt、JDBC、Kafka、MySQL、PostgreSQL、S3 和 Vector 集成的更多分步指南。
用户指南 许多新的用户指南，包括如何设置 ClickHouse Keeper、重新平衡分片、使用 JSON 以及如何使用数据跳过索引和稀疏主索引来提高查询性能。这正是你们许多人一直在等待的！

我们四月份的常规月度版本中有什么

事务作为（高度实验性的）预览功能提供。 BEGIN TRANSACTION、COMMIT 和 ROLLBACK 语句支持原子性地插入到多个表和物化视图中，以及从单个快照进行一致且隔离的读取。更多内容即将推出，敬请关注！
Keeper 负载均衡 您现在可以指定 ClickHouse 实例如何选择要连接的（ClickHouse）Keeper 或（Apache）ZooKeeper 实例。新的 config.xml 设置是 <zookeeper_load_balancing>，可能的值为 random（默认）、in_order、nearest_hostname、first_or_random 和 round_robin。当您有不同的 Keeper 节点彼此相距较远时，这有助于确保 ClickHouse 和 Keeper 之间的低延迟。
表元数据缓存 新的表设置 use_metadata_cache 使用嵌入式 RocksDB 引擎来缓存表元数据。当 ClickHouse 启动时，它将尝试从此缓存中读取，并在需要时回退到磁盘上的表文件。当您有大量数据部分时（通常是由于有大量数据库、表和/或分区，或者由于非常高的插入量创建了大量部分），这非常有用。在一个极端情况下（70 万个部分），元数据缓存能够将启动时间从 75 分钟减少到 20 秒。
Kafka 指标 Kafka 表引擎现在正在公开一些指标，例如已处理消息数、错误数、解析失败的消息数。您可以在 system.metrics 和 system.events 表中找到这些指标。
间隙填充 您现在可以使用插值来填充结果集中的间隙。例如，当您有每分钟数据，但有时缺少某分钟的值（完全缺失，或者可能仍在通过摄取管道并且到达较晚）时，您可以让 ClickHouse 使用先前的值，方法是使用 ORDER BY toStartOfMinute(timestamp) WITH FILL INTERPOLATE (c AS c)。更复杂的表达式也是可能的。
每月最后一天 到目前为止，ClickHouse 日期函数会将时间段舍入到开始时间（ toStartOf[Year|Month|Week|Day|Hour|Minute|etc.）。现在，如果您想舍入到某个月的最后一天（对于财务和会计数据很有用），我们也有了 toLastDayOfMonth。
H3 我们完善了对 H3 的支持，H3 是“六边形分层地理空间索引系统”，最初由 Uber 开发并开源。如果您还不了解它，请查看网站以及与其他系统（如 S2 和 Geohash）的比较。

请查看发布网络研讨会幻灯片并请升级（除非您想停留在 LTS 版本上）。

作为 ClickHouse 用户，您可以拥有的最重要的技能之一是查询优化。这将帮助您入门。

EXPLAIN SYNTAX

如果您还不熟悉 EXPLAIN 语句，请访问文档并查看一下。这是您在 ClickHouse 中调试查询的最佳助手。您应该知道的此命令的第一个实例是 EXPLAIN SYNTAX。您可以像这样使用它

EXPLAIN SYNTAX
SELECT sum(number)
FROM (SELECT * FROM numbers(10000))
WHERE number <= 10

这将显示在任何语法优化后实际要执行的查询。输出结果

┌─explain─────────────────┐
│ SELECT sum(number)      │
│ FROM                    │
│ (                       │	
│     SELECT number       │
│     FROM numbers(10000) │
│     WHERE number <= 10  │
│ )                       │
│ WHERE number <= 10      │
└─────────────────────────┘

您可以看到两件事

子查询中的通配符投影已替换为实际的列名 number。
即使 WHERE 条件仅出现在外部，ClickHouse 也可以确定它也可以应用于子查询，以大幅减少选择的行数。

EXPLAIN PLAN

这将向我们展示查询计划。当查询速度很慢时，这通常是您要查看的第一件事，因为它会显示 ClickHouse 从磁盘读取了多少数据。例如，假设有两个 MergeTree 表，每个表都有 10 亿行，一个未排序，另一个已排序

CREATE TABLE numbers (number int) ENGINE = MergeTree ORDER BY tuple()
AS SELECT number FROM numbers(1e9)

CREATE TABLE numbers_sorted (number int) ENGINE = MergeTree ORDER BY number
AS SELECT number FROM numbers(1e9)

查询速度将大相径庭

SELECT sum(number) FROM numbers WHERE number <= 10

1 rows in set. Elapsed: 0.688 sec. Processed 1.00 billion rows, 4.00 GB (1.45 billion rows/s., 5.81 GB/s.)

SELECT sum(number) FROM numbers_sorted WHERE number <= 10

1 rows in set. Elapsed: 0.007 sec. Processed 8.19 thousand rows, 32.77 KB (1.23 million rows/s., 4.90 MB/s.)

两个查询都只需要 10 个值即可计算其结果，但是，第一个查询必须读取整个表的 10 亿行，而第二个查询仅读取 8192 行（表 index_granularity 的默认大小）。我们可以通过 EXPLAIN PLAIN 运行查询来了解原因（输出已裁剪）

EXPLAIN PLAN actions = 1, indexes = 1 SELECT [...] numbers [...]
┌─explain────────────┐
│ [...]              |
│ ReadFromMergeTree  │
│ ReadType: Default  │
│ Parts: 1           │
│ Granules: 122071   │
└────────────────────┘


EXPLAIN PLAN actions = 1, indexes = 1 SELECT [...] numbers_sorted [...]


┌─explain───────────────────────────────┐
│ [...]                                 │
│ ReadFromMergeTree                     │
│ ReadType: Default                     │
│ Parts: 1                              │
│ Granules: 1                           │
│ Indexes:                              │
│   PrimaryKey                          │
│     Keys:                             │
│       number                          │
│     Condition: (number in (-Inf, 10]) │
│     Parts: 1/1                        │
│     Granules: 1/122071                │
└───────────────────────────────────────┘

两个查询都返回相同的结果（55，即从 1 到 10 的数字之和），但是第一个查询读取所有 122071 个粒度（每个粒度包含 8192 行，因此总计为 10 亿行的数据集），而第二个查询仅读取包含计算正确结果所需的十个数字的单个粒度。

每当您有慢查询时，请通过 EXPLAIN 运行它，您可能会很快找出它为何花费如此长时间以及该怎么做。

这些录像没有 TikTok 视频那么短，但如果您是 ClickHouse 用户，则非常值得您花时间观看。随意以 2 倍速观看，使其感觉更像社交媒体

ClickHouse 22.4 发布网络研讨会。您知道 17:13 处的脑筋急转弯的答案吗？
旧金山湾区聚会讨论了 ClickHouse 组合器、Hydrolix 以及从 Apache Pulsar 流式传输到 ClickHouse。

我们一直在阅读的内容

响应时间提高 10 倍，运营成本更低，存储减少 30%：Instabug 解释了他们为何选择 ClickHouse 作为其 APM 数据的数据库。如果我们诚实地说，这不是一个艰难的决定！
两种尺寸最适合：PostgreSQL 和 Clickhouse：Gitlab 撰写了关于 ClickHouse 和 PostgreSQL 的文章，并且还进行了一些基准测试，其中 ClickHouse 看起来非常好！
ClickHouse Keeper：有人使用 Kafka、Solr 和 Mesos 测试了 ClickHouse Keeper——并且一切正常！ Keeper 不仅适用于 ClickHouse。
推出官方 ClickHouse Grafana 插件：阅读有关新插件的信息，并查看您可以使用它创建的一些精美仪表板。
ClickHouse 文档焕然一新！：Rich 指出了经过改进的 Clickhouse 文档页面中的新内容。
新的 ClickHouse 采用者：欢迎 Better Stack、PingCAP、Synapse、Piwik、Marfeel、Datafold、Kaiko 和 Improvado。也把自己添加进去吧！