Amazon Aurora MySQL 的并行查询 - Amazon Aurora
并行查询概述

Amazon Aurora MySQL 的并行查询

本主题描述了 Amazon Aurora MySQL 兼容版的并行查询性能优化。该功能在某些数据密集型查询中使用特殊处理路径，从而利用 Aurora 共享存储架构。并行查询非常适合以下 Aurora MySQL 数据库集群：具有包含数百万行的表以及需要数分钟或数小时才能完成的分析查询。

主题

Aurora MySQL 的并行查询概述

Aurora MySQL 并行查询是一种优化功能，它并行处理在处理数据密集型查询时涉及的一些 I/O 和计算。并行处理的工作包括从存储中检索行，提取列值以及确定哪些行与 WHERE 子句和联接子句中的条件匹配。这种数据密集型工作将委派（在数据库优化术语中为向下推送）给 Aurora 分布式存储层中的多个节点。如果不使用并行查询，每个查询将所有扫描的数据传输到 Aurora MySQL 集群中的单个节点（头节点），并在此处执行所有查询处理。

提示

PostgreSQL 数据库引擎还有一个称为“并行查询”的功能。该功能与 Aurora 并行查询无关。

如果开启了并行查询功能，Aurora MySQL 引擎将自动确定查询何时可以从中受益，而无需进行 SQL 更改（如提示或表属性）。在以下章节中，您可以找到何时将并行查询应用于查询的说明。您还可以了解如何确保在提供最大好处时应用并行查询。

注意

并行查询优化为需要数分钟或数小时才能完成的长时间运行的查询提供最大优势。Aurora MySQL 通常不会为低开销查询运行并行查询优化。如果另一种优化技术更有意义（如查询缓存、缓冲池缓存或索引查找），它通常也不会执行并行查询优化。如果发现在需要时未使用并行查询，请参阅 验证哪些语句使用 Aurora MySQL 的并行查询。

优势

使用并行查询，您可以对 Aurora MySQL 表运行数据密集型分析查询。在很多情况下，与传统的查询处理分工相比，性能提高了一个数量级。

并行查询的好处包括：

  • 由于跨多个存储节点并行处理物理读取请求，提高了 I/O 性能。

  • 降低了网络流量。Aurora 不会将存储节点中的整个数据页面传输到头节点并随后筛选掉不需要的行和列。相反，Aurora 传输仅包含结果集所需的列值的紧凑元组。

  • 由于向下推送 WHERE 子句的函数处理、行筛选和列投影，减少了头节点上的 CPU 使用率。

  • 减轻了缓冲池上的内存压力。并行查询处理的页面不会添加到缓冲池中。此方法可降低数据密集型扫描从缓冲池中逐出经常使用的数据的可能性。

  • 通过使在现有的数据上执行长时间运行的分析查询变得切实可行，可能会在提取、转换和加载 (ETL) 管道中减少重复的数据。

架构

并行查询功能使用 Aurora MySQL 的主要架构准则：将数据库引擎与存储子系统分离，并简化通信协议以减少网络流量。Aurora MySQL 使用这些技术加快写入密集型操作（例如重做日志处理）。并行查询将相同的准则应用于读取操作。

注意

Aurora MySQL 并行查询的架构与其他数据库系统中名称类似的功能架构不同。Aurora MySQL 并行查询不涉及对称多处理 (SMP)，因此不依赖于数据库服务器的 CPU 容量。并行处理是在存储层中发生的，与作为查询协调器的 Aurora MySQL 服务器无关。

默认情况下，如果没有并行查询，Aurora 查询处理涉及将原始数据传输到 Aurora 集群中的单个节点（头节点）。之后，Aurora 会针对该单个节点上单个线程中的该查询执行所有进一步的处理。通过使用并行查询，该 I/O 密集型和 CPU 密集型工作的绝大部分将委派给存储层中的节点。仅将结果集的紧凑行传回到头节点，已筛选行并提取和转换了列值。性能优势来自于网络流量减少、头节点上的 CPU 使用率下降以及跨存储节点并行处理 I/O。并行 I/O、筛选和投影数量与运行查询的 Aurora 集群中的数据库实例数无关。

先决条件

要使用并行查询的所有功能，需要运行版本 2.09 或更高版本的 Aurora MySQL 数据库集群。如果您已有要与并行查询一起使用的集群，可以将其升级到兼容版本并在之后开启并行查询。在这种情况下，请确保遵循 并行查询的升级注意事项中的升级过程，因为这些较新版本中的配置设置名称和默认值不同。

集群中的数据库实例必须使用 db.r* 实例类。

确保为集群启用了哈希联接优化。要了解如何操作，请参阅为并行查询集群开启哈希联接。

要自定义参数（如 aurora_parallel_query 和 aurora_disable_hash_join），您必须具有与集群一起使用的自定义参数组。您可以使用数据库参数组为每个数据库实例单独指定这些参数。但是，我们建议您在数据库集群参数组中指定它们。这样，集群中的所有数据库实例都会继承这些参数的相同设置。

限制

以下限制适用于并行查询功能：

  • Aurora I/O-Optimized 数据库集群存储配置不支持并行查询。

  • 您不能将并行查询与 db.t2 或 db.t3 实例类一起使用。即使您使用 aurora_pq_force 会话变量来请求并行查询，此限制也适用。

  • 并行查询不适用于使用 COMPRESSED 或 REDUNDANT 行格式的表。对于计划与并行查询结合使用的表，请使用 COMPACT 或 DYNAMIC 行格式。

  • Aurora 使用基于成本的算法来确定是否对每个 SQL 语句使用并行查询机制。在语句中使用某些 SQL 结构可以防止并行查询，或使该语句不太可能执行并行查询。有关 SQL 结构与并行查询的兼容性的信息，请参阅 Aurora MySQL 中用于并行查询的 SQL 构造。

  • 每个 Aurora 数据库实例每次只能运行一定数量的并行查询会话。如果查询具有多个使用并行查询的部分（例如，子查询、联接或 UNION 运算符），这些阶段将按顺序运行。在任何时候，该语句仅计为一个并行查询会话。您可以使用并行查询状态变量监控活动会话数。您可以查询 Aurora_pq_max_concurrent_requests 状态变量以检查给定数据库实例的并发会话数限制。

  • 并行查询适用于 Aurora 支持的所有AWS区域。对于大多数 AWS 区域，使用并行查询所需的最低 Aurora MySQL 版本为 2.09。

  • 并行查询旨在提高数据密集型查询的性能。它不是为轻量级查询而设计的。

  • 我们建议您为 SELECT 语句使用读取器节点，尤其是数据密集型语句。

并行查询导致的 I/O 成本

如果您的 Aurora MySQL 集群使用并行查询，您可能会看到 VolumeReadIOPS 值出现增长。并行查询不使用缓冲池。因此，尽管查询速度很快，但这种优化的处理可能会导致读取操作和相关费用的增加。

查询的并行查询 I/O 成本在存储层计量，开启并行查询后，该成本将相同或更高。好处是提高了查询性能。并行查询可能导致 I/O 成本更高的原因有两个：

  • 即使表中的某些数据位于缓冲池中，并行查询也要求在存储层扫描所有数据，这会产生 I/O 成本。

  • 运行并行查询不会预热缓冲池。因此，连续运行同一个并行查询会产生完全 I/O 成本。