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

影响查询性能的因素

影响查询性能的因素有很多。数据、集群、数据库操作的以下方面都会影响查询过程的速度。

  • 节点、处理器或切片的数量 – 一个计算节点分为多个切片。节点越多意味着处理器和切片越多,通过跨各个切片并发运行查询的多个部分,可加快查询的处理速度。但是,节点越多也意味着花费越高,因此,您需要为自己的系统找到成本和性能之间的适当平衡点。有关 Amazon Redshift 集群架构的更多信息,请参阅数据仓库系统架构

  • 节点类型 – Amazon Redshift 集群可以使用密集存储节点或密集计算节点。对于大量数据存储需求,推荐使用密集存储节点类型;密集计算节点类型是专为性能密集型工作负载而优化的。每个节点类型提供不同的大小和限制,以帮助您适当地扩展集群。节点大小决定集群中每个节点的存储容量、内存、CPU 和价格。有关节点类型的更多信息,请参阅 Amazon Redshift 定价

  • 数据分配 – Amazon Redshift 根据表的分配方式在计算节点上存储表数据。在执行查询时,查询优化程序根据执行联接和聚合的需要将数据重新分配到计算节点。为表选择适当的分配方式可在执行联接前将数据放置到所需位置,这有助于尽量减少重新分配步骤产生的影响。有关更多信息,请参阅选择数据分配方式

  • 数据排序顺序 – Amazon Redshift 根据表的排序键将表数据按照排序顺序存储在磁盘中。查询优化程序和查询处理器利用数据放置位置的相关信息减少需要扫描的数据块数,从而提高查询速度。有关更多信息,请参阅选择排序键

  • 数据集大小 – 集群中的数据量越大,则需要扫描和重新分配的行数也越多,这会降低查询性能。您可以定期对数据进行 Vacuum 和存档操作,并使用谓词来限制查询数据集,以减轻这一影响。

  • 并发操作 – 同时运行多个操作会影响查询性能。每个操作都会占用可用查询队列中的一个或多个槽,并占用与这些槽关联的内存。如果其他操作正在运行,则可能没有充足的查询队列槽可用。在这种情况下,查询必须等待有槽回收后才能开始处理。有关创建和配置查询队列的更多信息,请参阅实施工作负载管理

  • 查询结构 – 查询的编写方式也会影响其性能。在满足需求的前提下,请尽量将查询编写为处理和返回尽量少的数据。有关更多信息,请参阅Amazon Redshift 查询设计最佳实践

  • 代码编译 – Amazon Redshift 为每个查询执行计划生成和编译代码。

    编译代码执行更快,因为它消除了使用解释器的开销。首次生成和编译代码时总会产生一些开销。因此,首次运行查询时的性能可能会造成误导。运行一次性查询时,此开销可能会特别明显。再一次运行查询以确定其典型性能。

    同样,在比较从不同客户端发送的同一查询的性能时要多加注意。执行引擎为 JDBC 连接协议和 ODBC 及 psql (libpq) 连接协议生成不同的代码。如果两个客户端使用不同的协议,则每个客户端都会产生首次生成编译代码的开销,即使针对同一查询也是如此。不过,使用相同协议的其他客户端将通过共享缓存代码而获益。使用 ODBC 的客户端和运行 psql(带 libpq)的客户端可共享相同的编译代码。

    编译的代码段本地存储集群中并远程存储在 AWS 账户级缓存中。相同查询的后续执行可以更快地运行,因为它可以跳过编译阶段。缓存在集群重启后依然保留,但可通过维护升级擦除。

    当存在本地缓存未命中时,将使用远程共享缓存。如果存在远程缓存命中,则将缓存项提取到本地缓存。远程缓存在同一 AWS 账户内的集群之间共享。因此,查询可以更快地运行:

    • 当查询在同一账户的不同集群上运行时。

    • 当查询在集群中的不同会话中运行时。

    • 而且,通常当查询具有不同的查询参数但具有相同的执行计划时。