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，然后在执行查询时合并。 这样，您的查询就会少很多。

或者，您可以运行常规作业（例如每小时一次）以将数据批处理为一个宽表。 这取决于加载后查询数据的速度。