Amazon Redshift Advisor 권장 사항

Amazon Redshift Advisor는 성능을 향상시키고 운영 비용을 절감하기 위해 Amazon Redshift 클러스터를 최적화하는 방법에 대한 권장 사항을 제공합니다. 위의 설명과 같이 콘솔에서 각 권장 사항에 대한 설명을 찾아볼 수 있습니다. 다음 단원에서 이러한 권장 사항에 대한 추가 세부 정보를 찾아볼 수 있습니다.

COPY를 통해 로드되는 Amazon S3 파일 객체 압축

COPY 명령은 Amazon Redshift의 대량 병렬 처리(MPP) 아키텍처를 이용하여 병렬로 데이터를 읽고 로드합니다. Amazon S3, DynamoDB 테이블 및 하나 이상의 원격 호스트의 텍스트 출력에서 파일을 읽을 수 있습니다.

많은 양의 데이터를 로드할 때는 COPY 명령을 사용하여 S3에서 압축된 데이터 파일을 로드하는 것이 좋습니다. 큰 데이터 세트를 압축하면 Amazon S3에 파일을 업로드하는 시간이 단축됩니다. 또한 COPY가 파일을 읽으면서 압축을 해제해 로드 프로세스를 단축할 수 있습니다.

분석

압축되지 않은 큰 데이터 세트를 로드하는 COPY 명령을 장기 실행하면 성능을 대폭 향상할 기회가 있습니다. Advisor 분석은 압축되지 않은 큰 데이터 세트를 로드하는 COPY 명령을 식별합니다. 이러한 경우 Advisor는 Amazon S3에서 소스 파일에 압축을 구현하라는 권장 사항을 생성합니다.

권장 사항

상당한 양의 데이터를 로드하거나 상당한 기간 동안 실행하는 각 COPY가 Amazon S3에서 압축되지 않은 데이터 객체를 수집하도록 합니다. 수퍼유저 권한으로 다음 SQL 명령을 실행하면 Amazon S3에서 압축되지 않은 큰 데이터 세트를 로드하는 COPY 명령을 식별할 수 있습니다.

SELECT
    wq.userid, query, exec_start_time AS starttime, COUNT(*) num_files,
    ROUND(MAX(wq.total_exec_time/1000000.0),2) execution_secs,
    ROUND(SUM(transfer_size)/(1024.0*1024.0),2) total_mb,
    SUBSTRING(querytxt,1,60) copy_sql
FROM stl_s3client s
JOIN stl_query q USING (query)
JOIN stl_wlm_query wq USING (query)
WHERE s.userid>1 AND http_method = 'GET'
    AND POSITION('COPY ANALYZE' IN querytxt) = 0
    AND aborted = 0 AND final_state='Completed'
GROUP BY 1, 2, 3, 7
HAVING SUM(transfer_size) = SUM(data_size) 
AND SUM(transfer_size)/(1024*1024) >= 5
ORDER BY 6 DESC, 5 DESC;         
          

스테이징된 데이터가 로드한 후에도 Amazon S3에 그대로 남아 있는 경우(데이터 레이크 아키텍처에서 일반적으로 발생함) 이 데이터를 압축된 형식으로 저장하면 스토리지 비용을 줄일 수 있습니다.

구현 팁

여러 활성 데이터베이스 격리

모범 사례로, Amazon Redshift의 데이터베이스를 서로 격리하는 것이 좋습니다. 쿼리는 특정 데이터베이스에서 실행되며 클러스터에 있는 다른 데이터베이스의 데이터에 액세스할 수 없습니다. 하지만 클러스터의 모든 데이터베이스에서 실행하는 쿼리는 동일한 기본 클러스터 스토리지 공간을 공유하고 리소스를 컴퓨팅합니다. 단일 클러스터에 여러 활성 데이터베이스가 포함되는 경우 각 워크로드는 일반적으로 서로 관련되지 않습니다.

분석

Advisor 분석은 클러스터에 있는 모든 데이터베이스를 검토하여 동시에 실행되는 활성 워크로드를 확인합니다. 동시에 실행되는 활성 워크로드가 있는 경우 Advisor는 데이터베이스를 별도의 Amazon Redshift 클러스터로 마이그레이션하는 것이 좋다는 권장 사항을 생성합니다.

권장 사항

활성으로 쿼리되는 각 데이터베이스를 별도의 전용 클러스터로 이동하는 것이 좋습니다. 별도의 클러스터를 사용하면 리소스 경합을 줄이고 쿼리 성능을 향상할 수 있습니다. 그렇게 하면 각 워크로드의 스토리지, 비용 및 성능 필요에 맞게 각 클러스터의 크기를 설정할 수 있기 때문입니다. 또한 관련되지 않은 워크로드는 흔히 다른 워크로드 관리 구성에서 이점을 얻을 수 있습니다.

데이터베이스가 활성으로 사용되는지 확인하려면 수퍼유저 권한으로 다음 SQL 명령을 실행할 수 있습니다.

SELECT database,
  COUNT(*) as num_queries,
  AVG(DATEDIFF(sec,starttime,endtime)) avg_duration,
  MIN(starttime) as oldest_ts,
  MAX(endtime) as latest_ts
FROM stl_query
WHERE userid > 1
GROUP BY database;            
         

구현 팁

워크로드 관리(WLM) 메모리 다시 할당

Amazon Redshift는 사용자 쿼리를 수동 WLM 구현로 라우팅하여 처리합니다. 이러한 쿼리의 대기열 라우팅 방식을 정의하는 것이 바로 워크로드 관리(WLM)입니다. Amazon Redshift는 클러스터의 사용 가능한 메모리 중 일부를 각 대기열에 할당합니다. 이렇게 할당된 대기열의 메모리는 다시 쿼리 슬롯으로 분할됩니다.

워크로드에 필요한 것보다 더 많은 슬롯으로 대기열이 구성되면 이러한 사용되지 않은 슬롯에 할당된 메모리는 과소 사용 상태가 됩니다. 구성된 슬롯을 피크 워크로드 요구 사항에 맞게 줄이면 과소 사용 상태의 메모리가 활성 슬롯에 다시 배포되므로 쿼리 성능을 향상할 수 있습니다.

분석

Advisor 문석은 워크로드 동시성 요구 사항을 검토하여 사용되지 않는 슬롯이 있는 쿼리 대기열을 식별합니다. 다음을 발견하면 Advisor는 대기열의 슬롯 수를 줄이기 위한 권장 사항을 생성합니다.

권장 사항

구성된 슬롯을 피크 워크로드 요구 사항에 맞게 줄이면 과소 사용 상태의 메모리가 활성 슬롯에 다시 배포됩니다. 슬롯이 완전히 사용된 적이 없는 대기열의 경우 구성된 슬롯 개수를 줄이는 것이 좋습니다. 이러한 대기열을 식별하려면 수퍼유저 권한으로 다음 SQL 명령을 실행하여 각 대기열의 피크 시간별 슬롯 요구 사항을 비교할 수 있습니다.

WITH
 generate_dt_series AS (select sysdate - (n * interval '5 second') as dt from (select row_number() over () as n from stl_scan limit 17280)),
 apex AS (
     SELECT iq.dt, iq.service_class, iq.num_query_tasks, count(iq.slot_count) as service_class_queries, sum(iq.slot_count) as service_class_slots
     FROM
         (select gds.dt, wq.service_class, wscc.num_query_tasks, wq.slot_count
         FROM stl_wlm_query wq
         JOIN stv_wlm_service_class_config wscc ON (wscc.service_class = wq.service_class AND wscc.service_class > 5)
         JOIN generate_dt_series gds ON (wq.service_class_start_time <= gds.dt AND wq.service_class_end_time > gds.dt)
         WHERE wq.userid > 1 AND wq.service_class > 5) iq
     GROUP BY iq.dt, iq.service_class, iq.num_query_tasks),
     maxes as (SELECT apex.service_class, trunc(apex.dt) as d, date_part(h,apex.dt) as dt_h, max(service_class_slots) max_service_class_slots
                     from apex group by apex.service_class, apex.dt, date_part(h,apex.dt))
SELECT apex.service_class - 5 AS queue, apex.service_class, apex.num_query_tasks AS max_wlm_concurrency, maxes.d AS day, maxes.dt_h || ':00 - ' || maxes.dt_h || ':59' as hour, MAX(apex.service_class_slots) as max_service_class_slots
FROM apex
JOIN maxes ON (apex.service_class = maxes.service_class AND apex.service_class_slots = maxes.max_service_class_slots)
GROUP BY  apex.service_class, apex.num_query_tasks, maxes.d, maxes.dt_h
ORDER BY apex.service_class, maxes.d, maxes.dt_h;            
         

max_service_class_slots 열은 해당 시간 동안 쿼리 대기열에 있는 최대 WLM 쿼리 슬롯 수를 나타냅니다. 사용률이 낮은 대기열이 있는 경우 Amazon Redshift 관리 가이드에 설명된 대로 파라미터 그룹을 수정하여 슬롯 감소 최적화를 구현합니다.

구현 팁

COPY 중 압축 분석 건너뛰기

COPY 명령으로 선언된 압축 인코딩을 사용하여 데이터를 빈 테이블로 로드하면 Amazon Redshift는 스토리지 압축을 적용합니다. 이 최적화를 사용하면 최종 사용자가 로드하더라도 클러스터의 데이터가 효율적으로 저장됩니다. 압축을 적용하기 위해 필요한 분석에는 상당한 시간이 소요될 수 있습니다.

분석

Advisor 분석은 자동 압축 분석에서 지연된 COPY 작업을 확인합니다. 이 분석은 로드되는 동안 데이터를 샘플링하여 압축 인코딩을 결정합니다. 이 샘플링은 ANALYZE COMPRESSION 명령이 수행하는 것과 비슷합니다.

야간 추출, 변환, 로드(ETL) 배치와 같이 데이터를 구조적 프로세스의 일부로 로드하는 경우 압축을 미리 정의할 수 있습니다. 또한 테이블 정의를 최적화하여 부정적인 영향 없이 이 단계를 영구적으로 건너뛸 수도 있습니다.

권장 사항

압축 분석 단계를 건너뛰어서 COPY 응답성을 향상하려면 다음 두 가지 옵션 중 하나를 구현합니다.

가장 좋은 솔루션은 일반적으로 테이블 생성 중에 열 인코딩을 사용하는 것입니다. 이 접근 방식을 사용하면 압축된 데이터를 디스크에 저장하는 장점을 그대로 유지할 수 있기 때문입니다. ANALYZE COMPRESSION 명령을 사용하여 압축 인코딩을 제안할 수 있지만, 이러한 인코딩을 적용하려면 테이블을 다시 생성해야 합니다. 이 프로세스를 자동화하려면 GitHub에 있는 AWSColumnEncodingUtility를 사용합니다.

자동 압축 분석을 트리거한 최신 COPY 작업을 식별하려면 다음 SQL 명령을 실행합니다.

  WITH xids AS (
    SELECT xid FROM stl_query WHERE userid>1 AND aborted=0 
    AND querytxt = 'analyze compression phase 1' GROUP BY xid
    INTERSECT SELECT xid FROM stl_commit_stats WHERE node=-1)
SELECT a.userid, a.query, a.xid, a.starttime, b.complyze_sec, 
    a.copy_sec, a.copy_sql
FROM (SELECT q.userid, q.query, q.xid, date_trunc('s',q.starttime) 
    starttime, substring(querytxt,1,100) as copy_sql, 
    ROUND(datediff(ms,starttime,endtime)::numeric / 1000.0, 2) copy_sec
    FROM stl_query q JOIN xids USING (xid)
    WHERE (querytxt ilike 'copy %from%' OR querytxt ilike '% copy %from%') 
    AND querytxt not like 'COPY ANALYZE %') a
LEFT JOIN (SELECT xid, 
    ROUND(sum(datediff(ms,starttime,endtime))::numeric / 1000.0,2) complyze_sec 
    FROM stl_query q JOIN xids USING (xid)
    WHERE (querytxt like 'COPY ANALYZE %' 
    OR querytxt like 'analyze compression phase %') 
    GROUP BY xid ) b ON a.xid = b.xid
WHERE b.complyze_sec IS NOT NULL ORDER BY a.copy_sql, a.starttime;
         

구현 팁

COPY로 로드되는 Amazon S3 객체 분할

COPY 명령은 Amazon Redshift의 대량 병렬 처리(MPP) 아키텍처를 활용하여 Amazon S3 파일의 데이터를 읽고로드합니다. COPY 명령은 여러 파일에서 데이터를 병렬 방식으로 로드하여 클러스터의 노드에게 워크로드를 분할합니다. 최적의 처리량을 달성하려면 데이터를 여러 파일로 분리하여 병렬 처리를 이용하는 것이 좋습니다.

분석

Advisor 분석은 Amazon S3에서 스테이징된 작은 수의 파일에 포함된 큰 데이터 세트를 로드하는 COPY 명령을 식별합니다. 적은 수의 파일에서 큰 데이터 세트를 로드하는 COPY 명령을 장기 실행하면 성능을 대폭 향상할 기회가 있습니다. Advisor가 이러한 COPY 명령에 상당한 시간이 걸리는 것으로 확인하면 Amazon S3에서 데이터를 추가 파일로 분할하여 병렬 처리를 증가시키기 위한 권장 사항을 생성합니다.

권장 사항

이 경우 나열된 우선 순위에 따라 다음 작업을 수행하는 것이 좋습니다.

특정 COPY 명령은 상당한 양의 데이터를 로드하거나 상당 기간 동안 실행됩니다. 이러한 명령의 경우 클러스터 내 조각 개수의 배수와 같은 수의 여러 데이터 객체를 Amazon S3에서 로드하는 것이 좋습니다. 각 COPY 명령이 로드한 S3 객체 수를 확인하려면 수퍼유저 권한으로 다음 SQL 코드를 실행합니다.

SELECT
    query, COUNT(*) num_files,
    ROUND(MAX(wq.total_exec_time/1000000.0),2) execution_secs,
    ROUND(SUM(transfer_size)/(1024.0*1024.0),2) total_mb,
    SUBSTRING(querytxt,1,60) copy_sql
FROM stl_s3client s
JOIN stl_query q USING (query)
JOIN stl_wlm_query wq USING (query)
WHERE s.userid>1 AND http_method = 'GET'
    AND POSITION('COPY ANALYZE' IN querytxt) = 0
    AND aborted = 0 AND final_state='Completed'
GROUP BY query, querytxt
HAVING (SUM(transfer_size)/(1024*1024))/COUNT(*) >= 2
ORDER BY CASE
WHEN COUNT(*) < (SELECT max(node)+1 FROM stv_slices) THEN 1
WHEN COUNT(*) < (SELECT COUNT(*) FROM stv_slices WHERE node=0) THEN 2
ELSE 2+((COUNT(*) % (SELECT COUNT(*) FROM stv_slices))/(SELECT COUNT(*)::DECIMAL FROM stv_slices))
END, (SUM(transfer_size)/(1024.0*1024.0))/COUNT(*) DESC;   
            
         

구현 팁

테이블 통계 업데이트

Amazon Redshift는 비용 기반 쿼리 옵티마이저를 사용하여 쿼리에 최적의 실행 계획을 선택합니다. 예상 비용은 ANALYZE 명령을 사용하여 수집된 테이블 통계를 기반으로 합니다. 통계가 오래되었거나 누락된 경우 데이터베이스는 매우 복잡한 쿼리의 쿼리 실행에 덜 효율적인 계획을 선택할 수 있습니다. 통계를 최신 상태로 유지하면 최대한 빠른 시간 내에 복잡한 쿼리를 실행하는 데 도움이 됩니다.

분석

Advisor 분석은 통계가 오래되거나 누락된 테이블을 추적합니다. 이 기능은 복잡한 쿼리와 연결된 테이블 액세스 메타데이터를 검토합니다. 복잡한 패턴으로 자주 액세스되는 테이블에 통계가 누락된 경우 Advisor는 ANALYZE를 실행하기 위한 중요 권장 사항을 생성합니다. 복잡한 패턴으로 자주 액세스되는 테이블에 오래된 통계가 있는 경우 Advisor는 ANALYZE를 실행하기 위한 제안 권장 사항을 생성합니다.

권장 사항

테이블 콘텐츠가 대폭 변경될 때마다 ANALYZE를 사용하여 통계를 업데이트합니다. COPY 또는 INSERT 명령을 통해 상당한 수의 새로운 데이터 행이 기존 테이블에 로드될 때마다 ANALYZE를 실행하는 것이 좋습니다. 또한 UPDATE 또는 DELETE 명령을 통해 상당한 수의 행이 수정될 때마다 ANALYZE를 실행하는 것이 좋습니다. 어떤 테이블에 누락되거나 오래된 통계가 있는지 확인하려면 수퍼유저 권한으로 다음 SQL 명령을 실행합니다. 결과는 가장 큰 테이블부터 가장 작은 테이블까지의 순서로 정렬됩니다.

어떤 테이블에 누락되거나 오래된 통계가 있는지 확인하려면 수퍼유저 권한으로 다음 SQL 명령을 실행합니다. 결과는 가장 큰 테이블부터 가장 작은 테이블까지의 순서로 정렬됩니다.

SELECT
   ti.schema||'.'||ti."table" tablename,
   ti.size table_size_mb,
   ti.stats_off statistics_accuracy
 FROM svv_table_info ti
 WHERE ti.stats_off > 5.00
 ORDER BY ti.size DESC;          
         

구현 팁

기본적으로 ANALYZE 임계값은 10퍼센트로 설정됩니다. 이와 같은 기본값은 마지막 ANALYZE 실행 후 테이블에서 변경된 행이 전체 행의 10% 미만인 경우 ANALYZE 명령이 주어진 테이블을 건너뜀을 의미합니다. 결과적으로 ETL 프로세스의 끝에 ANALYZE 명령을 실행하도록 선택할 수 있습니다. 이 방법을 사용한다는 것은 ANALYZE가 종종 생략되고 ANALYZE가 필요할 때 실행된다는 것을 의미합니다.

ANALYZE 통계는 조인 시 사용되는 열(예: JOIN tbl_a ON col_b) 또는 조건자로 사용되는 열(예: WHERE col_b = 'xyz')에 가장 많은 영향을 미칩니다. 기본적으로 ANALYZE는 지정된 테이블에 있는 모든 열에 대한 통계를 수집합니다. 필요한 경우 가장 많은 영향을 미치는 열에 대해서만 ANALYZE를 실행하여 ANALYZE를 실행하는 데 필요한 시간을 줄일 수 있습니다. 다음 SQL 명령을 실행하여 조건자로 사용되는 열을 식별할 수 있습니다. 또한 Amazon Redshift에서 ANALYZE PREDICATE COLUMNS를 지정하여 분석할 열을 선택할 수 있습니다.

WITH predicate_column_info as (
SELECT ns.nspname AS schema_name, c.relname AS table_name, a.attnum as col_num,  a.attname as col_name,
        CASE
            WHEN 10002 = s.stakind1 THEN array_to_string(stavalues1, '||') 
            WHEN 10002 = s.stakind2 THEN array_to_string(stavalues2, '||')
            WHEN 10002 = s.stakind3 THEN array_to_string(stavalues3, '||')
            WHEN 10002 = s.stakind4 THEN array_to_string(stavalues4, '||')
            ELSE NULL::varchar
        END AS pred_ts
   FROM pg_statistic s
   JOIN pg_class c ON c.oid = s.starelid
   JOIN pg_namespace ns ON c.relnamespace = ns.oid
   JOIN pg_attribute a ON c.oid = a.attrelid AND a.attnum = s.staattnum)
SELECT schema_name, table_name, col_num, col_name,
       pred_ts NOT LIKE '2000-01-01%' AS is_predicate,
       CASE WHEN pred_ts NOT LIKE '2000-01-01%' THEN (split_part(pred_ts, '||',1))::timestamp ELSE NULL::timestamp END as first_predicate_use,
       CASE WHEN pred_ts NOT LIKE '%||2000-01-01%' THEN (split_part(pred_ts, '||',2))::timestamp ELSE NULL::timestamp END as last_analyze
FROM predicate_column_info;

자세한 내용은 테이블 분석 단원을 참조하십시오.

단기 쿼리 가속화 활성화

단기 쿼리 가속화(SQA)는 선택한 단기 실행 쿼리를 장기 실행 쿼리보다 우선적으로 적용합니다. SQA 쿼리가 대기열에서 장기 쿼리 뒤에서 대기해야 하지 않도록 SQA는 전용 공간에서 단기 실행 쿼리를 실행합니다. SQA는 단기 실행되고 사용자 정의 대기열에 있는 쿼리에만 우선순위를 부여합니다. SQA가 있으면 단기 실행 쿼리가 더 빠르게 실행하기 시작하며 사용자가 더 빨리 결과를 확인합니다.

SQA를 켜면 단기 쿼리 실행에 전용되는 WLM(Workload Management) 대기열을 축소하거나 제거할 수 있습니다. 또한 장기 실행 쿼리가 단기 실행 쿼리와 대기열의 슬롯에 대해 경합할 필요가 없으므로, 더 적은 쿼리 슬롯을 사용하도록 WLM 대기열을 구성할 수 있습니다. 더 적은 동시성을 사용하면 대부분의 워크로드에 대해 쿼리 처리량이 증가되고 전체 시스템 성능이 향상됩니다. 자세한 내용은 단기 쿼리 가속화 작업 단원을 참조하십시오.

분석

Advisor가 워크로드 패턴을 확인하고 최근 쿼리 개수를 보고합니다. 이때, SQA 적격 쿼리에 대한 지연 시간 및 일일 대기열 시간이 줄어듭니다.

권장 사항

SQA를 켜 WLM 구성을 수정합니다. Amazon Redshift는 기계 학습 알고리즘을 사용하여 각 적격 쿼리를 분석합니다. SQA가 쿼리 패턴에서 학습하면 예측이 향상됩니다. 자세한 내용은 워크로드 관리 구성을 참조하십시오.

SQA를 켜면 WLM이 단기 쿼리에 대한 최대 실행 시간을 ‘동적(dynamic)’으로 기본 설정합니다. SQA 최대 실행 시간에 대해서는 동적 설정을 유지하는 것이 좋습니다.

구현 팁

SQA가 켜져 있는지 확인하려면 다음 쿼리를 실행합니다. 쿼리가 행을 반환한다면 SQA가 켜진 상태입니다.

select * from stv_wlm_service_class_config 
where service_class = 14;

자세한 내용은 SQA 모니터링 단원을 참조하십시오.

테이블의 분산 키 변경

Amazon Redshift는 테이블 배포 스타일에 따라 클라스터에 테이블 행을 분산합니다. KEY 분산이 있는 테이블에는 분산 키(DISTKEY)로서 열이 필요합니다. 테이블 행은 DISTKEY 열 값에 따라 클러스터의 노드 조각에 할당됩니다.

적절한 DISTKEY는 각 노드 조각에 비슷한 행 수를 배치하고 조인 조건에서 자주 참조됩니다. 테이블이 DISTKEY 열에 조인될 때 최적화된 조인이 발생하여 쿼리 성능이 향상됩니다.

분석

Advisor는 클라우저의 워크로드를 분석하여 키 분산 스타일에서 큰 이점을 얻을 수 있는 테이블에 가장 적절한 분산 키를 식별합니다.

권장 사항

Advisor는 분석을 기반으로 테이블의 DISTSTYLE 및 DISTKEY를 변경하는 ALTER TABLE 문을 제공합니다. 상당한 성능 이점을 실현하려면 권장 그룹 내의 모든 SQL 문을 구현해야 합니다.

ALTER TABLE로 큰 테이블을 다시 분산하면 클러스터 리소스가 사용되고 다양한 시간에 임시 테이블 잠금이 필요합니다. 다른 클러스터 워크로드가 적은 경우 각 권장 그룹을 구현합니다. 테이블 배포 속성의 최적화에 대한 자세한 내용은 Amazon Redshift Engineering의 고급 테이블 설계 플레이북: 배포 스타일 및 배포 키에서 확인할 수 있습니다.

ALTER DISTSYLE 및 DISTKEY에 대한 자세한 내용은 ALTER TABLE 섹션을 참조하세요.

테이블의 정렬 키 변경

Amazon Redshift는 테이블 정렬 키에 따라 테이블 행을 정렬합니다. 테이블 행의 정렬은 정렬 키 열 값을 기준으로 합니다.

적절한 정렬 키로 테이블을 정렬하면 디스크에서 요청하는 테이블 블록 읽기 수가 감소되므로 쿼리, 특히 범위 제한 술어를 사용하는 쿼리의 성능을 가속화할 수 있습니다.

분석

Advisor는 며칠 동안 클러스터의 워크로드를 분석하여 테이블에 적합한 정렬 키를 식별합니다.

권장 사항

Advisor는 분석을 기반으로 테이블의 정렬 키를 변경하는 2개의 ALTER TABLE 문 그룹을 제공합니다.

ALTER TABLE을 사용하여 큰 테이블을 정렬할 경우 클러스터 리소스가 사용되고 테이블 잠금이 여러 번 필요합니다. 클러스터의 워크로드가 보통인 경우 각 권장 사항을 구현합니다. 테이블 정렬 키 구성 최적화에 대한 자세한 내용은 Amazon Redshift Engineering's Advanced Table Design Playbook: Compound and Interleaved Sort Keys를 참조하세요.

ALTER SORTKEY에 대한 자세한 내용은 ALTER TABLE 섹션을 참조하세요.

열의 압축 인코딩 변경

압축은 열 수준에서 저장되는 데이터의 크기를 줄일 수 있는 작업입니다. 압축은 Amazon Redshift에서 디스크 I/O 양을 줄여 스토리지 공간을 절약하고 쿼리 성능을 개선하는 데 사용됩니다. 데이터 형식과 쿼리 패턴을 기반으로 각 열에 대해 최적의 압축 인코딩을 권장합니다. 최적의 압축을 통해 쿼리를 보다 효율적으로 실행할 수 있으며 데이터베이스는 최소한의 스토리지 공간을 차지할 수 있습니다.

분석

Advisor는 클러스터의 워크로드 및 데이터베이스 스키마를 지속적으로 분석하여 각 테이블 열에 대한 최적의 압축 인코딩을 식별합니다.

권장 사항

Advisor는 분석을 기반으로 특정 열의 압축 인코딩을 변경하는 ALTER TABLE 문을 제공합니다.

ALTER TABLE로 열 압축 인코딩을 변경하면 클러스터 리소스가 소모되고 여러 번 테이블 잠금이 필요합니다. 클러스터 워크로드가 적은 경우 권장 사항을 구현하는 것이 가장 좋습니다.

참고로 ALTER TABLE 예은 열의 인코딩을 변경하는 여러 문을 보여줍니다.

데이터 형식 권장 사항

Amazon Redshift에는 다양한 사용 사례를 위한 SQL 데이터 형식 라이브러리가 있습니다. INT와 같은 정수 형식, VARCHAR과 같이 문자를 저장하는 형식 등을 예로 들 수 있습니다. Redshift는 빠른 액세스와 뛰어난 쿼리 성능을 제공하기 위해 최적화된 방식으로 형식을 저장합니다. 또한 Redshift는 형식을 지정하거나 쿼리 결과에 대한 계산을 수행하는 데 사용할 수 있는 특정 형식을 위한 함수를 제공합니다.

분석

Advisor는 클러스터의 워크로드 및 데이터베이스 스키마를 지속적으로 분석하여 데이터 형식 변경으로 이점을 얻을 수 있는 열을 식별합니다.

권장 사항

Advisor는 제안된 데이터 형식의 새 열을 추가하는 ALTER TABLE 문을 제공합니다. 함께 제공되는 UPDATE 문은 기존 열에서 새 열로 데이터를 복사합니다. 새 열을 생성하고 데이터를 로드한 후 쿼리 및 수집 스크립트를 변경하여 새 열에 액세스합니다. 그런 다음 SQL 함수 참조에서 찾을 수 있는 새로운 데이터 형식에 특화된 기능 및 함수를 활용합니다.

기존 데이터를 새 열에 복사하는 데 시간이 걸릴 수 있습니다. 클러스터의 워크로드가 적은 경우 각 Advisor 권장 사항을 구현하는 것이 좋습니다. 데이터 타입에서 사용 가능한 데이터 형식 목록을 참조합니다.

데이터가 충분하지 않거나 데이터 형식 변경으로 예상되는 이점이 적은 경우에는 Advisor에서 권장 사항을 제공하지 않습니다.