如何在 Redshift 中找到访问次数最多的表？

Posted 2023-03-31

【中文标题】如何在 Redshift 中找到访问次数最多的表？

【英文标题】：How to find the most accessed table in Redshift?

【发布时间】：2021-05-15 04:43:49

【问题描述】：

我们正在将实时数据流式传输到 Redshift。瓶颈是没有可以同时运行的表加载。我们目前每 15 分钟运行超过 1000 次以上的负载。

但我们希望根据用户使用这些表的频率来减少这个数字。请建议我们如何在 Redshift 中获取此信息。

【问题讨论】：

如果我可以问，你对 VACUUM 做了什么？

还没有觉得有必要对此进行优化。正如我在其他问题中所说的那样。谢谢。

VACCUM 不是优化。它是红移。如果不使用 VACUUM，则使用 Redshift 完全没有意义 - Redshift 允许通过排序表对大数据进行及时的 SQL，而 VACUUM 是排序的核心。如果 VACUUM 没有被使用，表没有排序，Redshift 无法在大数据上提供及时的 SQL - 并且没有其他理由使用它，因为它是在大量使用时 效率低下，成本高昂，并且伴随着大量繁重的约束和要求。

为什么您认为 aws auto vaccum 不起作用？

今天让我测试一下我自己做vaccum是否增加了性能。谢谢。

【参考方案1】：

这个由 awslabs 开源的view 可以用来查询最常查询的表。

创建视图

CREATE OR REPLACE VIEW admin.v_get_table_scan_frequency
AS
SELECT 
    database, 
    schema AS schemaname, 
    table_id, 
    "table" AS tablename, 
    size, 
    sortkey1, 
    NVL(s.num_qs,0) num_qs
FROM svv_table_info t
LEFT JOIN (SELECT
   tbl, perm_table_name,
   COUNT(DISTINCT query) num_qs
FROM
   stl_scan s
WHERE 
   s.userid > 1
   AND s.perm_table_name NOT IN ('Internal Worktable','S3')
GROUP BY 
   tbl, perm_table_name) s ON s.tbl = t.table_id
AND t."schema" NOT IN ('pg_internal')
ORDER BY 7 desc;

表格

\d admin.v_get_table_scan_frequency
   Column   |  Type  | Modifiers
------------+--------+-----------
 database   | text   |
 schemaname | text   |
 table_id   | oid    |
 tablename  | text   |
 size       | bigint |
 sortkey1   | text   |
 num_qs     | bigint |

查询

select * from admin.v_get_table_scan_frequency order by num_qs;

结果

database | schemaname | table_id | tablename | size  | sortkey1      | num_qs
-----------------+------------+----------+------------------------------------------+-------+---------------+--------
 db      | product    | 1        | table1    |    92 | AUTO(SORTKEY) |  13448
 db      | product    | 2        | table2    |   180 | AUTO(SORTKEY) |  13389

在 Prometheus 中保留此查询的时间序列数据可以帮助找到每个表随时间变化的速率和频率趋势。基于此，我们可以决定在 Redshift 中刷新数据的频率。

【讨论】：

好吧，这个视图将“表使用”定义为“扫描次数”。如果有些表使用量很少，只占用一两行，而另一些表使用量很大，占用很多或大部分行怎么办？

我们根据当前活动的查询限制负载。我们的节流逻辑现在会考虑这会限制在过去 1 周内没有活动的表。我们计算出来的应该足够了。

此外，随着时间的推移，它会为我们提供未使用表的信息，我们会通过通知开发人员修复配置来继续删除它们。

嗯。两件事情。首先，系统表的内容是基于数据量，而不是天数。您不一定会有一周的数据。其次，您可以从系统表中计算出从表中读取的字节数，以及从低级步骤表（如您熟悉的 STL_SCAN）中写入的行数。

谢谢。有一个计划将其导出到 prometheus 并使其成为我们的 redshiftloader 将查询的时间序列指标。