问题描述
该表每 5 分钟处理一次高负载的 UPSERTS，因为它从 KAFKA 加载流数据。每次加载大约 200-500k 次更新。
当我对时间戳列之一运行带有 ORDER BY 的 SELECT 时，返回结果需要 5-7 分钟。
我为该列尝试了 Cluster Key，但由于该表上的 DML 操作很高，而且列本身的基数很高，因此集群效率低且成本高。
到目前为止，唯一将查询时间显着减少到 15 秒左右的想法是将仓库大小从小型增加到 X-Large。
我不相信唯一的解决方案是增加仓库规模。这里的任何建议都会很棒！
解决方法
在 date(timestamp)（或基数较低的东西）上聚类会更有效，但由于更新量的原因，它仍然会很昂贵。
在欢乐时光活动中，我听说一位 Snowflake 用户通过对迟到的事实（例如 iff(event_date<current_date,true,false))）进行聚类，在类似（ish）场景中取得了可接受的结果（尽管我认为他们是 INSERT ing not UPSERTing 并且在后一种情况下无论如何都必须重新编写微分区，因此它可能没有多大帮助。）
还有其他事情需要考虑。
检查查询计划以确认排序是问题所在（例如，在排序上花费了大量时间。）没有看到您的实际查询，我想知道是否大部分时间都花在了表扫描上（当它是从远程存储中获取数据。）如果更大的仓库可以提高性能，则很可能是这种情况，因为集群中每增加一个节点就意味着可以同时读取更多的微分区。
,你在对抗：
- 真正的时间戳列？
- 一个 JSON 列被转换为时间戳，但没有 附加功能？
- JSON 中有多少个字段
- UPDATE 与 INSERT 的相对比率是多少？
- 您是否查看过集群统计信息？