Database design 优化分组操作的红移性能

目前，我发现自己面临的挑战是，一个简单的“分组方式”大约需要2分钟。以下是我所做的：

我创建一个表

我插入了数据（5400万行）

我管理我的小组

有没有一种方法可以优化这些基本聚合方法的性能

THX

---

Lazloo

红移中有sort_键和dist_键的概念，这对于优化红移非常关键。这些键定义了如何将数据存储在表的红移中

在您的情况下，当前红移默认选择这些键，根据用户的使用情况，这些键可能有效，也可能无效。请浏览以下链接并相应地设计表格

考虑的步骤

对于排序键：

对于dist键：

---

详细说明上述dist关键建议：

通过此设置，同一年/月的数据分散在红移群集节点上。我可以想象，为了计算不同的值，引擎将在每个节点上获得唯一的值，但它必须将这些列表发送到leader节点，将它们合并到主唯一列表中，最后进行计数。如果在年或月列上分发数据，则可能会独立完成每个节点上的不同操作，从而加快处理速度

您还可以对分组所依据的列上的数据进行排序，但最主要的是分发数据

---

无需按

唯一\u clid

排序，至少对于此查询是这样。

您是如何“插入”数据的？请确保redshift在您的列上设置了正确的压缩（如果您使用“复制”命令，则会发生这种情况）。到目前为止，您研究了哪些相关方法来提高此类查询的SQL和redshift性能？请参阅其他链接和投票箭头鼠标覆盖文本。

create table devdb.raw_external_listings.pq_base_account_table
(
sap_id varchar(50) 
,account_name nvarchar(max) 
,Lead_source_code smallint not null
,company_id nvarchar(50) 
,company_name nvarchar(max) 
,description nvarchar(max) 
,Lead_source_name nvarchar(max) 
,Source_Code nvarchar(50) not null
,Source_Name nvarchar(max) 
,source_country varchar(20) 
,business_model varchar(20) 
,posting_ID bigint not null
,Date_Posted date  not null 
,posted_year int not null
,posted_month int not null
,Work_Type varchar(max) 
,Job_Country varchar(20) 
,joblocation nvarchar(max) 
,class_id int 
,unique_clid varchar(max) not null  sortkey
--,unique_clid bigint not null  sortkey
,ultimate_parent_sap_id varchar(50) 
,ultimate_parent_name nvarchar(max)
,ultimate_legal_parent_sap_id varchar(50) 
,ultimate_legal_parent_sap_name varchar(max) 
,account_bl varchar(50) 
,postal_code varchar(50) 
,emp_resp_login varchar(50) 
,full_name nvarchar(max) 
)

SELECT count(distinct unique_clid),count(distinct company_id), count(distinct work_type), posted_year, posted_month
FROM devdb.raw_external_listings.pq_base_account_table with (nolock)
GROUP by posted_year, posted_month
order by posted_year, posted_month