大型表的慢查询性能

Question

我有一个由5600万行组成的表。

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

当我针对一个时间戳列运行带有ORDER命令的SELECT时，返回结果需要花费5-7分钟。

我尝试了该列的群集键，但是由于该表上有一个高DML操作，而该列本身具有很高的基数，所以集群是无效的，而且代价很高。

到目前为止，唯一能显着地将查询时间缩短到15秒的是将仓库大小从一个小的X大增加到一个X大。

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

Answer 1

在date(timestamp)上进行集群(或者更低的基数)会更有效，尽管由于更新量很大，它仍然很昂贵。

在一个欢乐时刻的活动中，我听到一位雪花用户在类似的(ish)场景中通过对晚到的事实(例如iff(event_date<current_date, true, false)))进行聚类来获得可接受的结果(虽然我认为他们是INSERT而不是UPSERTing，而在后来的情况下，必须重写微分区，所以这可能没有多大帮助)。

还有其他事情要考虑。

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

Answer 2

你是在反对：

1. A真正的时间戳列？
2. JSON列作为时间戳但没有附加功能？
3. JSON
4. 中有多少字段是更新与插入的相对比率？

<代码>H19您看过集群统计信息吗？H 210<代码>G 211