在Redshift中使用連接的最佳方式

我在AWS redshift中有2個表。具體內容如下在Redshift中使用連接的最佳方式

一）印象（計算特定廣告的曝光次數）

行（170萬美元）
分發密鑰（ad_campaign）
排序鍵數的數（created_on）

b）點擊次數（計算特定廣告的點擊次數）。

行（80億美元）
分發密鑰（ad_campaign）
排序關鍵字（created_on）

數我有2片單DC1大型集羣。

我試圖運行下面的查詢

select impressions.offer_id, count(imp_cnt) from 
    bidsflyer.tblImpressionLog_Opt impressions 
full join bidsflyer.tblTrackingLinkLog_Opt clicks 
    on impressions.offer_id=clicks.offer_id and date_trunc('week', 
impressions.created_on)=date_trunc('week', clicks.created_on) 
    where impressions.created_on >= '2017-07-27 00:00:00' 
    group by 1

這個查詢需要更多的則8分鐘運行。考慮到數據量，我認爲這是相當大的，我認爲這不是很大。

查詢計劃看起來像下面

XN HashAggregate (cost=2778257688268.43..2778257688268.60 rows=67 width=12) 
     -> XN Hash Left Join DS_DIST_NONE (cost=179619.84..2778170875920.65 rows=17362469555 width=12) 

    Hash Cond: (("outer".offer_id = "inner".offer_id) AND (date_trunc('week'::text, "outer".created_on) = date_trunc('week'::text, "inner".created_on))) 

    -> XN Seq Scan on tblimpressionlog_opt impressions (cost=0.00..724967.36 rows=57997389 width=20) 
      Filter: (created_on >= '2017-07-27 00:00:00'::timestamp without time zone) 

    -> XN Hash (cost=119746.56..119746.56 rows=11974656 width=12) 
      -> XN Seq Scan on tbltrackinglinklog_opt clicks (cost=0.00..119746.56 rows=11974656 width=12)

東西誰能給我分配的密鑰的正確用法的指導和排序鍵。

我應該如何設計我的查詢？

來源

2017-07-27 AWS Enthusiastic

如果速度是重中之重，我強烈建議您至少使用2個節點。 –

表設置：

1）按照計劃，最貴的操作由offer_id分組。這很有意義，因爲您沒有按照offer_id對數據進行排序或分發。您的表格非常大，所以您可以使用交叉排序鍵(offer_id,created_on)（交錯鍵應該給包含的列賦予相等且與順序無關的權重，並且已知對較大的表具有積極影響）來重新創建表。 2）如果你加入數星期，你可以實現你的星期列（創建一個物理列，並用date_trunc輸出填充它）。這可能會節省一些計算工作量，以便在加入期間動態獲取這些值。但是，此操作很便宜，如果您的表已按時間戳列進行排序，則Redshift可能已經只掃描了適當的塊。此外，如果每個要約都運行一段時間（即要約列具有較高的基數和與時間列的高度相關性），則可以使用複合排序鍵（offer_id,week_created），這將允許更快的合併連接和聚合也會很快樂。

3）如果在其他查詢中不使用ad_campaign，則可以通過offer_id分配兩個表。加入發佈密鑰列是一種好的做法，因爲您擁有單個節點並且分發風格主要影響多節點設置，所以您的查詢不太可能從中受益。所有建議只是假設，不知道數據的確切性質，它們需要運行基準測試（使用建議的配置創建表，複製數據，真空，分析，運行相同的查詢至少3次，並將時間與原始設置）。如果你這樣做，並在這裏發佈結果，我將不勝感激。

RE查詢本身，你可以用JOIN取代FULL JOIN，因爲你不需要它。當你想要得到的不僅僅是沒有相關的點擊和反之亦然兩個表，也展示路口FULL JOIN應該被使用。這似乎情況並不因爲你是impressions.created_on和組過濾通過impressions.offer_id。所以，你需要的只是交叉路口。通過簡單的更換JOIN也FULL JOIN可能會影響查詢性能。如果你想看到零點擊的優惠，你可以使用LEFT JOIN。

來源

2017-07-27 14:18:24 AlexYes

合併連接快於散列連接，你應該努力實現合併連接。你按鍵看起來沒問題，但是你的數據實際上是排序的嗎？紅移不會自動保存搜索結果排序方式排序的關鍵表中的行，就沒有辦法爲紅移來執行你的桌子上合併連接。在桌面上運行一個完整的真空，紅移將開始執行合併連接。

select * from svv_table_info where table = 'impressions' 
select * from svv_table_info where table = 'clicks'

使用上面的查詢來檢查您在表中的未排序數據量。
在你的桌子上運行一個完整的真空。根據未排序數據的數量，這可能需要一段時間並使用大量羣集資源。

VACUUM impressions to 100 percent 
VACUUM clicks to 100 percent

如果我做了一個錯誤的假設，請評論，我會重新調整我的答案。

來源

2017-07-27 14:37:59

感謝拉胡爾的回答。將嘗試這些建議 –

在Redshift中使用連接的最佳方式

回答

相關問題