Amazon Redshift
数据库开发人员指南 (API 版本 2012-12-01)
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 Amazon AWS 入门

Performance

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

大规模并行处理

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

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 |

有关用于创建上例中所显示结果的查询的详细信息,请参阅优化表设计教程中的步骤 2:测试系统性能以建立基准

编译后的代码

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

执行引擎为 JDBC 连接协议以及 ODBC 和 psql (libq) 连接协议编译不同的代码,使用不同协议的两个客户端均将产生编译代码的首次成本。不过,使用相同协议的其他客户端将从共享缓存代码中获益。