根据文档,我们可以根据基数(该列的不同值)和联接条件中使用的列选择要进行聚类的列。这是其中一个表的聚类信息的o / p选择查询,其查询执行占用了总执行时间的80%以上(仅用于扫描表)。仅供参考,我已根据联接条件中使用的列收集了该表的以下输出。
基于与我的理解有关的o / p。以下是使我感到基于主题列对表进行聚类将有助于提高性能的点。
total_partition_count 20955与average_overlaps之比:17151.4681 total_partition_count 20955与average_depth的比率:16142.2524
1。如果我的理解是错误的,请纠正我。(基于以下事实,该表是否适合进行聚类?)
还请注意以下几点
2。如果我选择对表进行聚类,是否需要任何停机时间?或者聚类是否会增加我的账单?
3。此集群会影响未来的DML操作吗?
4。我看到选择查询在扫描37 GB数据后返回23行,这是除了选择群集作为选项之外提高查询性能的最佳解决方案。
让我知道所需的任何详细信息
select SYSTEM$CLUSTERING_INFORMATION('tablename','(columnname)');
{
"cluster_by_keys" : "LINEAR(column used in join condition)",
"total_partition_count" : 20955,
"total_constant_partition_count" : 2702,
"average_overlaps" : 17151.4681,
"average_depth" : 16142.2524,
"partition_depth_histogram" : {
"00000" : 0,
"00001" : 1933,
"00002" : 0,
"00003" : 0,
"00004" : 0,
"00005" : 0,
"00006" : 0,
"00007" : 0,
"00008" : 0,
"00009" : 0,
"00010" : 0,
"00011" : 0,
"00012" : 0,
"00013" : 0,
"00014" : 0,
"00015" : 0,
"00016" : 0,
"08192" : 2,
"16384" : 3,
"32768" : 19017
}
}
答案 0 :(得分:0)
但是在一个表上只能有一个集群,因此,如果您使一个查询更好,则可能使其他查询更糟。也是
自动群集在后台运行,考虑到硬盘驱动器的碎片整理。都是一样的,因此看来这是“工作”,是的,您为此付费。
未来DML不会直接受到聚类的影响,因为您已经开始聚类,因此将来的插入速度将慢N倍。但是,鉴于您要更改数据,DML multi会以两种方式影响您的集群,如果您插入的数据是随机排序的(相对于您的集群),则需要对数据进行排序。另外,您是否需要插入高频信号,这可能会干扰后台聚类操作。另外,如果您将新数据插入新分区,则更大的数据集需要重新整理。
您可以使用ORDER BY重写表并自行进行集群。
答案 1 :(得分:0)
分析SYSTEM $ CLUSTERING_INFORMATION数据。
“ average_overlaps”:17151.4681> 表中每个微分区的重叠微分区的平均数量。数字高表明表没有很好的聚集。
“平均深度”:16142.2524> 表中每个微分区的平均重叠深度。数字高表明表没有很好的聚集。
桶00000到32768描述了群集密钥被划分为多少个微分区(概念上与文件类似)。
“ 00000”:0> 20955个总微分区中有零(0)个恒定的微分区。
“ 32768”:19017> 32768表示32768微分区包含一个群集密钥。 19017微分区包含的集群密钥最多也包含19017个其他微分区,这很糟糕,因为我们需要完全扫描所有这些微分区以找到那些集群密钥之一。
https://docs.snowflake.com/en/sql-reference/functions/system_clustering_information.html
2。自动集群在后台运行,不需要停机。就计费而言,将收取一些额外费用。
3。群集不会像这样影响将来的DML操作,但是如果该表上的DML操作持续进行,那么只要新的微分区数量达到某个阈值,自动群集就会开始其操作以保持表的良好群集