Performance - Amazon Redshift
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

Performance

Amazon Redshift 通过使用这些性能功能来实现极快的查询运行。

大规模并行处理

大规模并行处理 (MPP) 支持对大量数据快速运行最复杂的查询。多个计算节点处理所有查询处理以获得最终结果聚合,运行相同的编译后查询的每个节点的每个核心在整个数据的各个部分进行分段。

Amazon Redshift 将表行分配给计算节点,以便能并行处理数据。通过为每个表选择相应的分配键,可以优化数据分配以均衡工作负载,并最大程度地减少节点间的数据移动。有关更多信息,请参阅选择最佳的分配方式

加载平面文件中的数据时将利用并行处理,方式是跨多个节点分配工作负载,同时从多个文件进行读取。有关如何将数据加载到表的更多信息,请参阅Amazon Redshift 加载数据的最佳实践

列式数据存储

数据库表的列式存储大大降低了总体磁盘 I/O 要求,它是优化分析查询性能的一个重要因素。按列式方式存储数据库表信息将减少磁盘 I/O 请求数与需从磁盘加载的数据量。减少加载到内存中的数据量使 Amazon Redshift 能够在执行查询时执行更多的内存中处理。有关更详细的说明,请参阅 列式存储

在适当地对列进行排序时,查询处理器能够快速筛选出大型数据块子集。有关更多信息,请参阅选择最佳的排序键

数据压缩

数据压缩将降低存储要求,从而减少磁盘 I/O 来提高查询性能。在运行查询时,压缩的数据将读入内存,然后在查询运行期间解压缩。将少量数据加载到内存中使 Amazon Redshift 能够分配更多内存来分析数据。由于列式存储将按顺序存储类似数据,因此 Amazon Redshift 能够应用与列式数据类型关联的自适应压缩编码。对表列启用数据压缩的最佳方式是,允许 Amazon Redshift 在您将表与数据一起加载时应用最优压缩编码。要了解有关使用自动数据压缩的更多信息,请参阅使用自动压缩加载表

查询优化程序

Amazon Redshift 查询运行引擎集成了 MPP 感知的查询优化程序并采用了面向列式的数据存储。Amazon Redshift 查询优化程序实施大量增强和扩展以便处理通常包含多表联接、子查询和聚合的复杂的分析查询。要了解有关优化查询的更多信息,请参阅优化查询性能

结果缓存

为了缩短查询运行时间并提高系统性能,Amazon Redshift 在领导节点的内存中缓存特定查询类型的结果。当用户提交查询时,Amazon Redshift 会在结果缓存中检查是否有查询结果的有效缓存副本。如果在结果缓存中找到匹配项,Amazon Redshift 会使用缓存的结果而不执行查询。结果缓存对用户透明。

默认情况下,结果缓存处于打开状态。要为当前会话禁用结果缓存,请将 enable_result_cache_for_session 参数设置为 off

在满足以下所有条件时,Amazon Redshift 将为新查询使用缓存的结果:

  • 提交查询的用户具有查询中所用对象的访问权限。

  • 查询中的表或视图未更改。

  • 查询不使用必须在每次运行时求值的函数,例如 GETDATE。

  • 该查询不引用 Amazon Redshift Spectrum 外部表。

  • 可能影响查询结果的配置参数未更改。

  • 查询的语法与缓存的查询相符。

为了最大限度地提升缓存有效性和资源的使用效率,Amazon Redshift 不缓存一些非常大的查询结果集。Amazon Redshift 会根据多个因素确定是否缓存查询结果。这些因素包括缓存中的条目数以及 Amazon Redshift 集群的实例类型。

要确定查询是否使用了结果缓存,请查询 SVL_QLOG 系统视图。如果查询使用了结果缓存,source_query 列会返回源查询的查询 ID。如果未使用结果缓存,则 source_query 列值为 NULL。

以下示例说明了由 userid 104 和 userid 102 提交的查询使用了来自 userid 100 运行的查询的结果缓存。

select userid, query, elapsed, source_query from svl_qlog where userid > 1 order by query desc; userid | query | elapsed | source_query -------+--------+----------+------------- 104 | 629035 | 27 | 628919 104 | 629034 | 60 | 628900 104 | 629033 | 23 | 628891 102 | 629017 | 1229393 | 102 | 628942 | 28 | 628919 102 | 628941 | 57 | 628900 102 | 628940 | 26 | 628891 100 | 628919 | 84295686 | 100 | 628900 | 87015637 | 100 | 628891 | 58808694 |

编译后的代码

领导节点跨集群的所有节点分发完全优化的编译后的代码。编译查询将减少与解释器关联的开销,从而加快运行速度,特别是加快复杂查询的运行速度。缓存编译后的代码并在同一个集群的多个会话中进行共享。因此,同一查询的未来运行的速度将更快,通常甚至可使用不同的参数来运行。

查询运行引擎为 JDBC 和 ODBC 连接协议编译不同的代码,这样,使用不同协议的两个客户端会各自产生编译代码的首次成本。不过,使用相同协议的客户端会因共享缓存代码而获益。