CTAS 사용 시 주의 사항 - Amazon Redshift

CTAS 사용 시 주의 사항

Limits

Amazon Redshift는 노드 유형별로 클러스터당 테이블 수 할당량을 적용합니다.

테이블 이름으로 입력할 수 있는 최대 문자 수는 127자입니다.

단일 테이블에서 정의할 수 있는 최대 열 수는 1,600개입니다.

열 및 테이블 속성의 상속

CREATE TABLE AS(CTAS) 테이블은 자신이 생성된 테이블로부터 제약 조건, 자격 증명 열, 기본 열 값 또는 기본 키를 상속하지 않습니다.

CTAS 테이블에 대한 열 압축 인코딩을 지정할 수 없습니다. Amazon Redshift가 다음과 같이 압축 인코딩을 자동으로 할당합니다.

  • 정렬 키로 정의된 열은 RAW 압축이 할당됩니다.

  • BOOLEAN, REAL, DOUBLE PRECISION, GEOMETRY 또는 GEOGRAPHY 데이터 유형으로 정의된 열은 RAW 압축이 할당됩니다.

  • SMALLINT, INTEGER, BIGINT, DECIMAL, DATE, TIME, TIMETZ, TIMESTAMP 또는 TIMESTAMPTZ로 정의된 열에는 AZ64 압축이 할당됩니다.

  • CHAR, VARCHAR 또는 VARBYTE로 정의된 열에는 LZO 압축이 할당됩니다.

자세한 내용은 압축 인코딩데이터 타입 단원을 참조하세요.

열 인코딩을 명시적으로 할당하려면 CREATE TABLE을 사용하세요.

CTAS가 SELECT 절의 쿼리 계획을 기반으로 새 테이블의 분산 스타일과 정렬 키를 결정합니다.

조인, 집계, order by 절 또는 limit 절을 포함하는 쿼리와 같은 복잡한 쿼리인 경우, CTAS는 쿼리 계획을 기반으로 최적의 분산 스타일과 정렬 키를 선택하기 위해 최대한 시도합니다.

참고

큰 데이터 집합 또는 복잡한 쿼리로 최상의 성능을 얻으려면 일반적인 데이터 집합을 사용하여 테스트하는 것이 좋습니다.

쿼리 최적화 프로그램이 데이터 정렬과 배포를 위해 선택하는 열이 있을 경우 어떤 열을 선택할지 살펴보는 쿼리 계획을 검사함으로써 CTAS가 선택할 배포 키와 정렬 키를 예측할 수 있는 경우가 종종 있습니다. 쿼리 계획의 최상위 노드가 단일 테이블(XN Seq Scan)의 간단한 순차적 스캔인 경우에는 CTAS가 일반적으로 원본 테이블의 분산 스타일과 정렬 키를 사용합니다. 쿼리 계획의 최상위 노드가 다른 순차적 스캔(예: XN Limit, XN Sort, XN HashAggregate 등)인 경우, CTAS는 쿼리 계획을 기반으로 최적의 분산 스타일과 정렬 키를 선택하기 위해 최대한 시도합니다.

예를 들어, 다음 유형의 SELECT 절을 사용하여 5개의 테이블을 만든다고 가정해봅시다.

  • 간단한 select 문

  • limit 절

  • LISTID를 사용하는 order by 절

  • QTYSOLD를 사용하는 order by 절

  • group by 절을 사용하는 SUM 집계 함수

다음 예에서는 각 CTAS 문에 대한 쿼리 계획을 보여 줍니다.

explain create table sales1_simple as select listid, dateid, qtysold from sales; QUERY PLAN ---------------------------------------------------------------- XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=8) (1 row) explain create table sales2_limit as select listid, dateid, qtysold from sales limit 100; QUERY PLAN ---------------------------------------------------------------------- XN Limit (cost=0.00..1.00 rows=100 width=8) -> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=8) (2 rows) explain create table sales3_orderbylistid as select listid, dateid, qtysold from sales order by listid; QUERY PLAN ------------------------------------------------------------------------ XN Sort (cost=1000000016724.67..1000000017155.81 rows=172456 width=8) Sort Key: listid -> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=8) (3 rows) explain create table sales4_orderbyqty as select listid, dateid, qtysold from sales order by qtysold; QUERY PLAN ------------------------------------------------------------------------ XN Sort (cost=1000000016724.67..1000000017155.81 rows=172456 width=8) Sort Key: qtysold -> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=8) (3 rows) explain create table sales5_groupby as select listid, dateid, sum(qtysold) from sales group by listid, dateid; QUERY PLAN ---------------------------------------------------------------------- XN HashAggregate (cost=3017.98..3226.75 rows=83509 width=8) -> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=8) (2 rows)

각 테이블에 대한 배포 키와 정렬 키를 보려면 다음에 표시된 것처럼 PG_TABLE_DEF 시스템 카탈로그 테이블을 쿼리합니다.

select * from pg_table_def where tablename like 'sales%'; tablename | column | distkey | sortkey ----------------------+------------+---------+--------- sales | salesid | f | 0 sales | listid | t | 0 sales | sellerid | f | 0 sales | buyerid | f | 0 sales | eventid | f | 0 sales | dateid | f | 1 sales | qtysold | f | 0 sales | pricepaid | f | 0 sales | commission | f | 0 sales | saletime | f | 0 sales1_simple | listid | t | 0 sales1_simple | dateid | f | 1 sales1_simple | qtysold | f | 0 sales2_limit | listid | f | 0 sales2_limit | dateid | f | 0 sales2_limit | qtysold | f | 0 sales3_orderbylistid | listid | t | 1 sales3_orderbylistid | dateid | f | 0 sales3_orderbylistid | qtysold | f | 0 sales4_orderbyqty | listid | t | 0 sales4_orderbyqty | dateid | f | 0 sales4_orderbyqty | qtysold | f | 1 sales5_groupby | listid | f | 0 sales5_groupby | dateid | f | 0 sales5_groupby | sum | f | 0

다음 표에 결과가 요약되어 있습니다. 단순성을 기하기 위해 설명 계획에서 비용, 행 및 너비 세부 정보는 생략합니다.

CTAS SELECT 문

설명 계획 최상위 노드

배포 키

정렬 키

S1_SIMPLE

select listid, dateid, qtysold from sales

XN Seq Scan on sales ...

LISTID DATEID
S2_LIMIT

select listid, dateid, qtysold from sales limit 100

XN Limit ...

없음(EVEN) None
S3_ORDER_BY_LISTID

select listid, dateid, qtysold from sales order by listid

XN Sort ...

Sort Key: listid

LISTID LISTID
S4_ORDER_BY_QTY

select listid, dateid, qtysold from sales order by qtysold

XN Sort ...

Sort Key: qtysold

LISTID QTYSOLD
S5_GROUP_BY

select listid, dateid, sum(qtysold) from sales group by listid, dateid

XN HashAggregate ...

없음(EVEN) None

CTAS 문에서 분산 스타일과 정렬 키를 명시적으로 지정할 수 있습니다. 예를 들어, 다음 문은 EVEN 분산을 사용하여 테이블을 생성하고 SALESID를 정렬 키로 지정합니다.

create table sales_disteven diststyle even sortkey (salesid) as select eventid, venueid, dateid, eventname from event;

압축 인코딩

ENCODE AUTO는 테이블의 기본값으로 사용됩니다. Amazon Redshift는 테이블의 모든 열에 대한 압축 인코딩을 자동으로 관리하지 않습니다.

수신 데이터의 배포

수신 데이터의 해시 배포 구성표가 대상 테이블의 해시 배포 구성표와 일치하는 경우, 데이터 로드 시 데이터를 물리적으로 배포할 필요는 실제로 없습니다. 예를 들어, 새 테이블에 대해 배포 키가 설정되고 같은 키 열에 배포된 다른 테이블에서 데이터가 삽입되고 있는 경우, 같은 노드와 조각을 사용하여 데이터가 적절히 로드됩니다. 하지만 원본 테이블과 대상 테이블이 모두 EVEN 배포로 설정되어 있는 경우 데이터는 대상 테이블로 다시 배포됩니다.

자동 ANALYZE 작업

Amazon Redshift는 CTAS 명령으로 생성하는 테이블을 자동으로 분석합니다. 이 테이블들이 처음 생성될 때는 테이블에서 ANALYZE 명령을 실행할 필요가 없습니다. 테이블을 수정하는 경우, 다른 테이블과 같은 방법으로 분석해야 합니다.