优化 AWS RedShift 查询

Posted 2023-03-30

【中文标题】优化 AWS RedShift 查询

【英文标题】：Optimizing AWS RedShift query

【发布时间】：2018-11-22 05:56:24

【问题描述】：

我将用户详细信息存储在纵向表中，用户的每个属性对应于单独的行。由于数据是纵向的，因此每个用户显然可以有多行。

我正在尝试根据提供的手机号码查找特定用户的所有用户详细信息。我正在使用以下查询：

select ws.*
from (select * from user_details) as vs
inner join 
  (select distinct ms.user_id 
   from (select <given mobile no> as Phone) as ls
   inner join (select * from user_details) as ms on ls.Phone = ms.value
  ) as ws
on ws.user_id = vs.user_id

“key”列对应用户属性，“value”对应用户属性值。

示例表为：

|---------|--------|------------|---------------------|
| user_id |   key  |   value    |       timestamp     |
|---------|--------|------------|---------------------|
|  100    | mobile | 765783xxxx | 2018-09-09 13:40:00 |
|  100    |  email | [e-mail] | 2018-09-09 13:41:00 |
|  100    |  name  | johnny doe | 2018-09-09 13:42:00 |
|  101    | mobile | 456898xxxx | 2018-09-09 13:43:00 |
|  101    | email  | [e-mail] | 2018-09-09 13:44:00 |
|  101    |  name  | janey doe  | 2018-09-09 13:45:00 |
|---------|--------|------------|---------------------|

我首先根据给定的手机号码查找 user_id 并将其与 value 列连接，然后我想查找与该 user_id 对应的所有行。

我已经在 user_id 列上设置了 DISTKEY，在 timestamp 列上设置了 SORTKEY。

此表有近 20 亿行。

集群详情如下：

集群属性：

集群类型：单节点 节点类型：dc1.large

容量详情：

当前节点类型：dc1.large CPU：每个节点 7 个 EC2 计算单元（2 个虚拟内核） 内存：每个节点 15GiB 平台：64 位

使用此配置的查询当前需要 160 秒才能执行。

感谢您在优化此查询和减少运行时间方面的任何帮助。

【问题讨论】：

我认为该查询甚至不会运行。请发布您的实际查询，并通过在每行添加四个或更多空格将其格式化为代码。

为什么嵌套太多了？当嵌套工作过多时，计划总是会出错..

您的查询看起来有点复杂，请您清楚地说明您的要求。如果您提供示例输入和预期输出会有所帮助

如果需要更多详细信息，请告诉我。

表的DISTKEY 和SORTKEY 是什么？

【参考方案1】：

如果不了解表的内容或您想要实现的目标，很难非常提出改进查询的建议。

它很可能很简单：

SELECT DISTINCT user_id
FROM user_details
WHERE value = <given mobile no>

在 Amazon Redshift 中优化查询的另一部分是明智地使用 DISTKEY 和 SORTKEY。再一次，在不知道数据及其使用方式的情况下很难推荐合适的值，但此查询将受益于 value 是 SORTKEY。 （但这并不一定意味着它是所有表格使用的最佳选择。）

【讨论】：

+1- 试试这个（并根据您的要求量身定制），让我们知道速度。也请用你的表的 distkey 和 sortkey 更新你的问题。

此查询的执行时间相同。

它是否给出相同的结果集？如果是这样，可以通过将value 设置为SORTKEY 来优化此查询，但这可能会减慢使用timestamp 的其他查询。

@JohnRotenstein，timestamp 和 value 上的交错排序键会有帮助吗？

通常应避免使用交错排序键。他们需要很长时间才能通过VACUUM 创建，并且只在少数情况下提供好处。 （在这种情况下，仅当 timestamp 和 value 经常在单独查询中的 WHERE 语句中使用时。如果您经常通过电话号码进行用户查找，则可能值得仅使用 user+ 创建一个单独的表phone，可以针对此类查询进行优化。优点是查询速度非常快。缺点是需要使用此信息更新第二个表。