Redshift：是否使用必要的外鍵來利用分配鍵？

在亞馬遜的指南中，他們提到爲所有表格指定PRIMARY和FOREIGN KEY，然後在有意義的地方指定分配鍵，就像通常用於連接表的列一樣。我知道，即使使用單個表查詢，正確的DISTKEY規範將有助於執行GROUP BY，但對於JOINing兩個或更多表，DISTKEY列是否也必須指定爲FOREIGN KEY？或者，Redshift會根據用作DISTKEY的列的數據類型（以及可能的名稱）將不同表中的行共同定位到相同的節點？Redshift：是否使用必要的外鍵來利用分配鍵？

我問的原因是因爲我沒有真正在我的應用程序中使用維度表。我可以創建它們僅僅用作外鍵引用來幫助分發，但是維表必須被維護。

看看下面的例子，我有一個經常被連接的兩個表：

CREATE TABLE motorcycles 
(
    id INT, 
    hexcolor CHAR(6) 
); 

CREATE TABLE helmets 
(
    id INT, 
    hexcolor CHAR(6) 
);

現在，在我的應用程序想，我們經常參加摩托車表到頭盔表上hexcolor柱。那麼使用DISTSTYLE KEY並使用DISTKEY (hexcolor)是合理的，對吧？但是，您不能說hexcolor列的摩托車列表是表的表的外鍵，反之亦然。我可以創建一個維表，只是把所有的可能hexcolor值的列表，然後同時摩托車和頭盔表可以有一個外鍵，該維度表，但是這將是一個痛苦維護這個維度表（亞馬遜的指南還警告說，不要指定沒有正確維護的主鍵或外鍵，因爲它會混淆查詢規劃器）。

那麼，以我的摩托車和頭盔爲例，維度表的外鍵是必要的嗎？或者Redshift會假定它應該以相同的方式分配這兩個表的行，這是基於用作分配鍵的列的數據類型相同的事實？

來源

2015-11-04 olanmills

只需添加一個無關的2¢ - 您應該將hexcolor轉換爲24/32位整數並存儲它。它會更快，佔用更少的磁盤空間。 – ZiggyTheHamster

我的真實場景與顏色或摩托車無關。我只是想給出一個對大多數人都有意義的例子。 :) – olanmills

只要列具有相同的數據類型，您應該期望Redshift以同樣的方式分配摩托車和頭盔表。

在你的情況下沒有理由爲外鍵。查詢計劃者將能夠利用這些表由同一個密鑰分發的事實。

但是，閱讀執行計劃總是很好，並確保它說DS_DIST_NONE - 這意味着不需要數據重新分配。

來源

2015-11-04 10:04:24

這與列名是什麼有關？ – olanmills

不，不管列名是什麼。 –

Redshift：是否使用必要的外鍵來利用分配鍵？

回答

相關問題