Redshift性能：SQL查詢與表規范化

Question

我正在通過偵聽來自不同來源的事件來構建Redshift數據庫，並將該數據泵入Redshift集群。

這個想法是使用Kinesis firehose通過COPY命令將數據泵送至Redshift。 但是我這里有一個難題：我希望首先使用選擇查詢（例如以下查詢）從redshift查詢一些信息：

select A, B, C from redshift__table where D='x' and E = 'y';

從redshift獲得所需的信息后，我將把該信息與事件通知數據結合起來並向kinesis發出請求。 然后，Kinesis將執行其工作並發出所需的COPY命令。

現在我的問題是，像每秒說一次那樣反復查詢redshift是個好主意，因為那是我將在其后收到事件通知的預期時間？

現在讓我描述一個替代方案：

如果我對我的表進行規范化並將某些字段分離到一個單獨的表中，那么我將不得不使用規范化的設計執行更少的redshift查詢（可能每30秒執行一次）

但是這種方法的缺點是，一旦我將數據轉移到紅移中，我將必須執行表聯接，同時對我的紅移數據執行實時分析。

因此，我希望從更高的角度了解哪種方法更好：

1. 只有一個平面表，但是在對事件通知發出運動要求之前先進行查詢。 執行分析時不會有任何表聯接。

2. 有2個表，查詢redshift的頻率降低。 但是在使用BI /分析工具顯示結果時執行表聯接。

您認為這2個中的哪個更好？ 讓我們假設在兩種情況下我都將使用適當的排序鍵/分發鍵。

Answer 1

我絕對會選擇您的第二個選項，它涉及與查詢進行聯接。 這就是Amazon Redshift擅長的事情（尤其是如果您正確設置了SORTKEY和DISTKEY時）。

讓流數據以最有效的方式進入Redshift，然后在執行查詢時合並。 這樣，您的查詢就會少很多。

或者，您可以運行常規作業（例如每小時一次）以將數據批處理為一個寬表。 這取決於加載后查詢數據的速度。