Redshift——查询性能问题答案

【问题标题】：Redshift -- Query Performance IssuesRedshift——查询性能问题
【发布时间】：2016-03-16 06:04:03
【问题描述】：

SELECT
  a.id,
  b.url as codingurl 
FROM fact_A a 
INNER JOIN dim_B b
ON strpos(a.url,b.url)> 0

Fact_A 中的记录数：200 万
Dim_B 中的记录数：1500
执行时间：10 分钟
节点数：2

有人可以帮助我理解为什么上述查询需要更多时间来执行吗？

我们已经在 Fact_A 中声明了分布键，以便在两个节点中适当地均匀分布记录，并且在 Fact_A 中的 URL 上创建了排序键。

Dim_B 表是用DISTRIBUTION ALL 创建的。

【问题讨论】：

您能否提供更多信息，具体来说您使用的是哪种节点，集群中有多少个节点以及A和B的表架构
“为什么上述查询需要更多时间来执行”是什么意思？时间多于什么？或者你只是说你希望它更快？请记住——它必须进行 30 亿次字符串比较，与普通比较（例如 =、=）相比，strpos 不是连接表的有效方法。
您能否提供一些与strpos 一起使用的a.url 和b.url 的示例值？可能有一种更有效的方式来进行查询。

标签： amazon-web-services amazon-redshift

【解决方案1】：

Redshift 没有全文搜索索引或前缀索引，所以像这样的查询（过滤器中使用了strpos）会导致全表扫描，执行strpos 30 亿次。

根据 dim_B 中的 url，您可以通过将前缀提取到单独的列中来优化这一点。例如，如果您总是比较 http[s]://hostname/part1/part2/part3 形式的子路径，那么您可以在 fact_A 和 dim_B 中提取“part1/part2/part3”作为单独的列，并将其设为dist 和排序键。

您还可以依赖 Redshift 的并行性。如果您将集群的大小从 2 个节点调整为 20 个节点，您应该会立即看到 8-10 倍的性能提升，因为这种查询可以由每个节点并行执行（大部分情况下）。

【讨论】：