我正在努力通过侦听来自不同来源的事件并将该数据泵入红移集群来构建红移数据库。
这个想法是使用Kinesis消防水带使用COPY命令将数据泵送到红移。但是我在这里有一个两难的境地：我希望首先使用如下选择查询从 redshift 查询一些信息：
select A, B, C from redshift__table where D='x' and E = 'y';
从 redshift 获得所需信息后，我将这些信息与我的事件通知数据相结合，并向 kinesis 发出请求。然后，Kinesis 将完成其工作并发出所需的 COPY 命令。
现在我的问题是，像每秒一样重复查询红移是一个好主意，因为那是我收到事件通知的预期时间？
现在让我描述一个替代场景：
如果我规范化我的表并将一些字段分离到一个单独的表中，那么我将不得不使用规范化设计执行更少的红移查询(可能每 30 秒一次)
但这种方法的缺点是，一旦我将数据放入红移，我将不得不在对红移数据执行实时分析的同时执行表连接。
因此，我希望在高层次上知道哪种方法会更好：
有一个平面表，但在向 kinesis 发出事件通知请求之前对其进行查询。执行分析时不会有任何表联接。
有 2 个表，查询红移的频率较低。但在使用 BI/分析工具显示结果时执行表连接。
您认为这 2 个中哪一个是更好的选择？让我们假设无论哪种情况，我都会使用适当的排序键/分布键。
我肯定会选择您的第二个选项，它涉及与查询联接。这就是 Amazon Redshift 擅长做的事情(特别是如果您正确设置了 SORTKEY 和 DISTKEY)。
让流数据以最有效的方式进入 Redshift，然后在执行查询时加入。这样你的查询就会少得多。
或者，您可以运行常规作业(例如每小时)将数据批处理到宽表中。这取决于加载后查询数据的速度。