子列的红移分布答案

【问题标题】：Redshift Distribution By Child Columns子列的红移分布
【发布时间】：2017-09-28 00:20:46
【问题描述】：

我的情况

我的 redshift 集群中有一些表，它们都分解为 order_id、shipment_id 或 shipping_item_id，具体取决于表的粒度。 order_id 是 shipping_id 上的一对多关系，shipment_id 是 shipemnt_item_id 上的一对多关系。

我的问题

我在 order_id 上分发，因此所有 shipping_id 和 shipping_item_id 记录应该在表中的相同节点上，因为它们按 order_id 分组。我的问题是，当我必须加入 shipping_id 或 shipping_item_id 时，redshift 会知道记录在同一个节点上，还是会因为它们没有加入 order_id 而广播这些表？

示例表

unified_order                                   shipment_details
+----------+-------------+------------------+   +-------------+-----------+--------------+
| order_id | shipment_id | shipment_item_id |   | shipment_id | ship_day  | ship_details |
+----------+-------------+------------------+   +-------------+-----------+--------------+
|        1 |           1 |                1 |   |           1 | 1/1/2017  | stuff        |
|        1 |           1 |                2 |   |           2 | 5/1/2017  | other stuff  |
|        1 |           1 |                3 |   |           3 | 6/14/2017 | more stuff   |
|        1 |           2 |                4 |   |           4 | 5/13/2017 | less stuff   |
|        1 |           2 |                5 |   |           5 | 6/19/2017 | that stuff   |
|        1 |           3 |                6 |   |           6 | 7/31/2017 | what stuff   |
|        2 |           4 |                7 |   |           7 | 2/5/2017  | things       |
|        2 |           4 |                8 |   +-------------+-----------+--------------+
|        3 |           5 |                9 |   
|        3 |           5 |               10 |   
|        4 |           6 |               11 |   
|        5 |           7 |               12 |   
|        5 |           7 |               13 |   
+----------+-------------+------------------+

分布

distribution_by_node
+------+----------+-------------+------------------+
| node | order_id | shipment_id | shipment_item_id |
+------+----------+-------------+------------------+
|    1 |        1 |           1 |                1 |
|    1 |        1 |           1 |                2 |
|    1 |        1 |           1 |                3 |
|    1 |        1 |           2 |                4 |
|    1 |        1 |           2 |                5 |
|    1 |        1 |           3 |                6 |
|    1 |        5 |           7 |               12 |
|    1 |        5 |           7 |               13 |
|    2 |        2 |           4 |                7 |
|    2 |        2 |           4 |                8 |
|    3 |        3 |           5 |                9 |
|    3 |        3 |           5 |               10 |
|    4 |        4 |           6 |               11 |
+------+----------+-------------+------------------+

【问题讨论】：

给定您的查询示例，我在shipment_details 表中没有看到order_id，如果没有这样的列并且订单和发货之间的关系似乎是，order_id 如何分配它仅保存在unified_order 表中

标签： amazon-redshift

【解决方案1】：

Amazon Redshift 文档没有详细说明如何在节点之间共享信息，但它“广播表”是值得怀疑的。

相反，信息可能会根据需要在节点之间发送——只有相关的列会被共享，并且可能只有数据的子范围。

与其过分担心内部实现，不如针对实际查询测试各种 DISTKEY 和 SORTKEY 策略以确定性能。

遵循Choose the Best Distribution Style 的建议以尽量减少需要在节点之间发送的数据量，并咨询Amazon Redshift Best Practices for Designing Queries 以改进查询。

【讨论】：

感谢约翰的回复。如果未在分布列上连接，Redshift 将broadcast 表（请参阅 ds_bcast_inner）。我不像在 SQL Server 中那样熟悉 Redshift 中的查询构建，但我相信它也会在连接 Logical Processing Order of the SELECT statement 之后应用 select 和 where 语句。我确实计划对此进行测试，但是对于 Redshift，我们需要构建数据以支持我们的查询。

【解决方案2】：

您可以EXPLAIN 您的查询以查看在执行期间数据将如何分布（或不分布）。在本文档中，您将看到如何阅读查询计划： Evaluating the Query Plan

【讨论】：

是的，我将对此进行测试并审查执行计划，但是使用新的分布键填充这些表需要一段时间，所以我想我会问的。