使用 SYSTEM$CLUSTERING_INFORMATION 識別潛在的集群鍵

Question

即使過濾了某個事件，在我的基於事件的數據庫上運行的查詢當前也會掃描所有行 - 導致掃描時間長。 Event_type 是我經常在過濾器中使用的東西，這就是為什么我認為集群在上面可能是一件好事。 該表已按 date_id 和 app_title 聚集。 我使用 SYSTEM$CLUSTERING_INFORMATION 來查看附加 event_type 列上的聚類是否有用。結果很糟糕。 這是否意味着這將是一個糟糕的選擇？ 還是僅僅意味着當前表在這個鍵上的聚集度很差？ 使用這三個集群鍵創建表會導致不同的結果嗎？

（我在下面的查詢/結果中更改了一些名稱和值）

select system$clustering_information('materialized_view', '(date_id, app_title, event_type)');
 
{
  "cluster_by_keys" : "LINEAR(date_id, app_title, event_type)",
  "total_partition_count" : <more than 100k>,
  "total_constant_partition_count" : 0,
  "average_overlaps" : ~500
  "average_depth" : ~500,
  "partition_depth_histogram" : {
    "00000" : 0,
    "00001" : 0,
    "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,
    "00064" : 30,
    "00128" : 3218,
    "00256" : 22146,
    "00512" : 94367,
    "01024" : 134114
  }
}

Answer 1

這是顯示當前集群的state ，不好。 這意味着按照您定義的方式創建集群密鑰可能會有所幫助。

集群鍵中列（或表達式）的順序非常重要。 您希望 go 從較低的基數到較高的基數。 例如，如果您只有五種事件類型，那么它可能應該是列列表中的第一個。

沒有上下文的 APP_TITLE 列更有趣。 如果它具有高基數（列的名稱似乎暗示了這一點），您可以使用諸如left(APP_TITLE, 2)之類的表達式來限制基數。

請記住，如果您需要在非常高的基數或唯一列上設置鍵，請使用表達式減少基數。 您可以通過這種方式查看 Snowflake 在集群鍵中支持哪些功能：

show functions; 
-- Look at the "valid_for_clustering" column to see which are allowed.