1

我有一个包含 5600 万行的表。

该表每 5 分钟处理一次高负载的 UPSERTS，因为它正在从 KAFKA 加载流数据。每次加载大约 200-500k 更新。

当我针对其中一个时间戳列运行带有 ORDER BY 的 SELECT 时，需要 5-7 分钟才能返回结果。

我为该列尝试了 Cluster Key，但由于该表上的 DML 操作很高，并且列本身的基数很高，所以集群效率低且成本高。

到目前为止，唯一将查询时间显着减少到大约 15 秒的想法是将仓库大小从 Small 增加到 X-Large。

我不相信唯一的解决方案是增加仓库规模。这里的任何建议都会很棒！

4

2 回答 2

1

集群date(timestamp)（或较低基数的东西）会更有效，尽管由于更新量很大，它仍然会很昂贵。

在一个欢乐时光活动中，我听说一个 Snowflake 用户通过对迟到的事实（例如iff(event_date<current_date, true, false))）进行聚类，在类似（ish）场景中取得了可接受的结果（尽管我认为他们INSERT没有UPSERTing 并且在后一种情况下，微分区必须是无论如何都要重新编写，所以它可能没有多大帮助。）

还有其他事情需要考虑。

检查查询计划以确认排序是问题（例如，在排序上花费了大量时间。）没有看到您的实际查询，我想知道是否大部分时间都花在了表扫描上（当它抓取数据时）来自远程存储。）如果更大的仓库提高了性能，则很可能是这种情况，因为集群中每个添加的节点都意味着可以同时读取更多的微分区。

于 2021-07-18T14:21:21.750 回答
0

你是否在反对：

  1. 一个真正的时间戳列？
  2. JSON 列转换为时间戳但没有附加功能？
  3. JSON中有多少个字段
  4. UPDATE 与 INSERT 的相对比率是多少？
  5. 你看过集群统计信息吗？
于 2021-07-18T18:58:31.697 回答