本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
查询 Amazon Redshift 的性能因素
有很多因素会影响查询性能。数据、集群和数据库操作的以下方面都会影响查询的处理速度:
表属性
Amazon Redshift 表是在 Amazon Redshift 中存储数据的基本单元,每个表都有一组决定其行为和可访问性的属性。这些属性包括排序、分发方式、压缩编码等。了解这些属性对于优化 Amazon Redshift 表的性能、安全性和成本效益至关重要。
排序键
Amazon Redshift 根据表的排序键按排序顺序将数据存储在磁盘上。查询优化器和查询处理器使用有关数据在计算节点中的位置的信息来减少必须扫描的块数。这减少了要处理的数据量,从而显著提高了查询速度。我们建议您使用排序键来简化WHERE
子句中的过滤器。有关更多信息,请参阅 Amazon Redshift 文档中的使用排序键。
数据压缩
数据压缩降低了存储需求,从而减少了磁盘 I/O 并提高了查询性能。运行查询时,压缩的数据会被读入内存,然后在查询运行时解压缩。通过将更少的数据加载到内存中,Amazon Redshift 可以分配更多的内存来分析数据。由于列式存储按顺序存储相似的数据,因此 Amazon Redshift 可以应用专门与列式数据类型相关的自适应压缩编码。对表列启用数据压缩的最佳方法是使用 Amazon Redshift 中的AUTO
选项在向表加载数据时应用最佳压缩编码。要了解有关使用自动数据压缩的更多信息,请参阅 Amazon Redshift 文档中的加载具有自动压缩功能的表。
数据分布
Amazon Redshift 根据表的分配方式将数据存储在计算节点上。在执行查询时,查询优化程序根据执行联接和聚合的需要将数据重新分配到计算节点。为表选择正确的分配方式有助于通过在执行联接前将数据放在需要的位置来最大程度地减小重新分配步骤的影响。我们建议您使用分配密钥来简化最常见的联接。有关更多信息,请参阅 Amazon Redshift 文档中的使用数据分配方式。
餐桌维护
尽管 Amazon Redshift 为大多数工作负载提供了业界领先的开箱即用性能,但要保持 Amazon Redshift 集群的良好运行需要维护。更新和删除数据会创建必须清理的死行,如果追加顺序与排序键不一致,则即使是仅限追加的表也必须重新排序。
Vacuum
亚马逊 Redshift 中的吸尘过程对于亚马逊 Redshift 集群的运行和维护至关重要。它还会影响查询的性能。由于删除和更新都会标记旧数据,但实际上并未将其删除,因此您必须使用清理功能来回收被前一个UPDATE
和操作标记为删除的表行所占用的磁盘空间。DELETE
Amazon Redshift 可以在后台自动对表进行排序和执行VACUUM DELETE
操作。
要在加载或一系列增量更新操作后清理表,您也可以对整个数据库或对单个表运行 VACUUM
命令。如果表具有排序键,并且表加载未经过优化,无法在插入时进行排序,则必须使用 vacuum 对数据进行重新排序(这可能对性能至关重要)。有关更多信息,请参阅亚马逊 Redshift 文档中的清理表格。
分析
该ANALYZE
操作会更新 Amazon Redshift 数据库中表的统计元数据。通过允许查询计划程序选择最佳计划,使统计数据保持最新可提高查询性能。Amazon Redshift 持续监控您的数据库,并自动在后台执行分析操作。为了最大限度地减少对系统性能的影响,该ANALYZE
操作将在工作负载较轻的时段自动运行。如果您选择显式运行ANALYZE
,请执行以下操作:
-
在运行查询之前运行该
ANALYZE
命令。 -
在每个常规加载或更新周期结束时,定期在数据库上运行该
ANALYZE
命令。 -
对您创建的新表以及发生重大变化的现有表或列运行该
ANALYZE
命令。 -
考虑按不同的计划对不同类型的表和列运行
ANALYZE
操作,具体取决于它们在查询中的使用情况及其更改倾向。 -
要节省时间和群集资源,请在运行
ANALYZE
命令时使用PREDICATE COLUMNS
子句。
集群配置
集群是执行数据的实际存储和处理的节点的集合。如果您想实现以下目标,那么以正确的方式设置 Amazon Redshift 集群至关重要:
-
高可扩展性和并发性
-
高效使用亚马逊 Redshift
-
更好的性能
-
更低的成本
节点类型
Amazon Redshift 集群可以使用多种节点类型之一(RA3 DC2、和 DS2)。每种节点类型都提供不同的大小和限制,以帮助您适当地扩展集群。节点大小决定集群中每个节点的存储容量、内存、CPU 和价格。成本和性能优化始于选择正确的节点类型和大小。有关节点类型的更多信息,请参阅亚马逊 Redshift 文档中的亚马逊 Redshift 集群概述。
节点大小、节点数量和切片
一个计算节点分为多个切片。更多的节点意味着更多的处理器和切片,这使您的查询能够通过在切片上并发运行部分查询来更快地处理查询。但是,更多的节点也意味着更高的开支。这意味着您必须在成本和性能之间找到适合您的系统的平衡。有关亚马逊 Redshift 集群架构的更多信息,请参阅亚马逊 Redshift 文档中的数据仓库系统架构。
工作负载管理
Amazon Redshift 工作负载管理 (WLM) 使用户能够灵活地管理具有优先级的工作负载队列,这样简短、快速运行的查询就不会卡在长时间运行的查询后面的队列中。Automation WLM 使用机器学习 (ML) 算法来分析查询,并将它们放入具有适当资源的相应队列中,同时管理查询并发性和内存分配。有关 WLM 的更多信息,请参阅 Amazon Redshift 文档中的实现工作负载管理。
短查询加速
短查询加速 (SQA) 将短期查询优先于长时间运行的查询。SQA 在专用空间中运行查询,这样 SQA 查询就不会被迫在队列中等待更长的查询。SQA 仅优先处理用户定义的队列中的短时查询。如果您使用 SQA,短期查询开始运行的速度会更快,并且可以更快地看到结果。如果启用 SQA,则可以减少或消除专用于短期查询的 WLM 队列。此外,长时间运行的查询无需争夺 WLM 队列中的空位。这意味着您可以将 WLM 队列配置为使用更少的查询槽。如果使用较低的并发度,则可以提高大多数工作负载的查询吞吐量并提高整体系统性能。有关 SQA 的更多信息,请参阅 Amazon Redshift 文档中的使用短查询加速。
SQL 查询
数据库查询是对数据库数据的请求。该请求应在使用 SQL 的 Amazon Redshift 集群中发出。Amazon Redshift 支持通过 Java 数据库连接 (JDBC) 和开放数据库连接 (ODBC) 进行连接的 SQL 客户端工具。您可以使用支持 JDBC 或 ODBC 驱动程序的大多数 SQL 客户端工具。
查询结构
查询的编写方式会极大地影响其性能。我们建议您编写查询来处理和返回尽可能少的数据,以满足您的需求。有关如何构造查询的更多信息,请参阅本指南的 “设计 Amazon Redshift 查询的最佳实践” 部分。
代码编译
Amazon Redshift 为每个查询执行计划生成和编译代码。编译代码执行更快,因为它消除了使用解释器的开销。在第一次生成和编译代码时,通常会有一些开销成本。因此,首次运行查询时的性能可能会造成误导。运行一次性查询时,开销可能特别明显。我们建议您再次运行查询,以确定其典型性能。
Amazon Redshift 使用无服务器编译服务将查询编译扩展到 Amazon Redshift 集群的计算资源之外。编译的代码段本地缓存于集群中,且是在几乎无限的缓存中。集群重新启动后,此缓存将保持不变。对同一查询的后续调用运行得更快,因为它们可以跳过编译阶段。缓存在 Amazon Redshift 版本之间不兼容,因此在版本升级后运行查询时会重新编译代码。通过使用可扩展的编译服务,Amazon Redshift 能够并行编译代码,以提供始终如一的快速性能。工作负载加速的幅度取决于查询的复杂性和并发性。