Amazon Redshift 성능

이 주제에서는 성능을 높이는 Amazon Redshift 구성 요소에 대해 설명합니다. 이러한 구성 요소를 이해하면 Amazon Redshift의 성능을 조정하고 성능 저하 문제를 해결하는 데 도움이 됩니다.

Amazon Redshift는 이러한 성능 기능을 사용하여 매우 빠른 쿼리 실행을 달성합니다.

대용량 병렬 처리

대용량 병렬 처리(MPP)는 아무리 복잡한 쿼리라고 해도 빠른 속도로 실행하여 대용량 데이터를 처리할 수 있습니다. 다수의 컴퓨팅 노드가 각 노드의 코어마다 전체 데이터를 분할하여 동일하게 컴파일된 쿼리 세그먼트를 실행하면서 최종 결과 집계에 이를 때까지 모든 쿼리를 처리합니다.

Amazon Redshift는 데이터를 병렬로 처리 할 수 있도록 테이블의 행을 계산 노드에 배포합니다. 각 테이블마다 적절한 분산 키를 선택하면 데이터 분산을 최적화함으로써 워크로드의 밸런스를 유지할 뿐만 아니라 노드 간 데이터 이동을 최소화할 수도 있습니다. 자세한 내용은 최상의 배포 스타일 선택 단원을 참조하십시오.

플랫 파일에서 데이터를 로드할 때는 다수의 파일에서 데이터를 읽어오는 동시에 워크로드를 다수의 노드로 분산시켜서 병렬 방식으로 데이터를 처리합니다. 데이터를 테이블에 로드하는 방법에 대한 자세한 내용은 데이터 로드에 대한 Amazon Redshift 모범 사례 단원을 참조하세요.

열 기반 데이터 스토리지

데이터베이스 테이블을 위한 열 기반 스토리지는 전체 디스크 I/O 요건을 크게 줄여주며 분석 쿼리 성능을 최적화하는 데 중요한 요인입니다. 자세한 내용은 열 기반 스토리지 단원을 참조하십시오.

열이 적절하게 정렬되면 쿼리 프로세서가 대용량의 데이터 블록 하위 집합을 빠르게 필터링할 수 있습니다. 자세한 내용은 최상의 정렬 키 선택 단원을 참조하십시오.

데이터 압축

데이터 압축은 스토리지 요건을 줄여 디스크 I/O를 감소시킴으로써 쿼리 성능이 향상되는 효과가 있습니다. 쿼리를 실행하면 압축된 데이터를 메모리로 읽어온 후 쿼리 실행 도중 압축이 해제됩니다. 적은 데이터를 메모리에 로드하면 Amazon Redshift는 더 많은 메모리를 할당하여 데이터를 분석할 수 있습니다. 원주형 스토리지는 유사한 데이터를 순차적으로 저장하기 때문에 Amazon Redshift는 원주형 데이터 형식에 특별히 연결된 적응형 압축 인코딩을 적용할 수 있습니다. 테이블 열에 데이터 압축을 가능하게 하는 가장 좋은 방법은 데이터로 테이블을 로드할 때 Amazon Redshift가 최적의 압축 인코딩을 적용하는 것입니다. 자동 데이터 압축의 사용에 대한 자세한 내용은 자동 압축을 사용하여 테이블 로드 단원을 참조하세요.

쿼리 최적화 프로그램

Amazon Redshift 쿼리 실행 엔진은 MPP를 인식하고 열 기반 데이터 리포지토리를 활용하는 쿼리 옵티마이저를 통합합니다. Amazon Redshift 쿼리 옵티마이저는 종종 다중 테이블 조인, 하위 쿼리 및 집계를 포함하는 복잡한 분석 쿼리를 처리하기위한 중요한 향상 및 확장을 구현합니다. 쿼리 최적화에 대한 자세한 내용은 쿼리 성능 튜닝 단원을 참조하세요.

결과 캐싱

쿼리 런타임을 줄이고 시스템 성능을 향상시키기 위해 Amazon Redshift는 특정 형식의 쿼리 결과를 리더 노드의 메모리에 캐시합니다. 사용자가 쿼리를 제출하면 Amazon Redshift는 결과 캐시에서 쿼리 결과의 유효한 캐시 된 복사본을 확인합니다. 결과 캐시에서 일치 항목이 발견되면 Amazon Redshift는 캐시된 결과를 사용하고 쿼리를 실행하지 않습니다. 결과 캐싱은 사용자가 볼 수 있습니다.

결과 캐싱은 기본적으로 설정되어 있습니다. 현재 세션에 대해 결과 캐싱을 해제하려면 enable_result_cache_for_session 파라미터를 off로 설정합니다.

Amazon Redshift는 다음 조건이 모두 충족될 때 캐시된 결과를 새 쿼리에 사용합니다.

캐시 효율성과 리소스의 효율적인 사용을 극대화하기 위해 Amazon Redshift는 일부 대규모 쿼리 결과 집합을 캐시하지 않습니다. Amazon Redshift는 여러 요인에 따라 쿼리 결과를 캐시할지 여부를 결정합니다. 이러한 요소에는 캐시의 항목 수와 Amazon Redshift 클러스터의 인스턴스 유형이 포함됩니다.

특정 쿼리에 결과 캐시가 사용되었는지 여부를 확인하려면 SVL_QLOG 시스템 보기를 쿼리합니다. 쿼리에 결과 캐시가 사용된 경우 소스 쿼리 열이 소스 쿼리의 쿼리 ID를 반환합니다. 결과 캐싱이 사용되지 않은 경우 source_query 열 값은 NULL입니다.

다음 예에서는 userid 104 및 userid 102가 제출한 쿼리에 userid 100이 실행한 쿼리의 결과 캐시가 사용됩니다.

select userid, query, elapsed, source_query from svl_qlog 
where userid > 1
order by query desc;

userid | query  | elapsed  | source_query
-------+--------+----------+-------------
   104 | 629035 |       27 |       628919
   104 | 629034 |       60 |       628900
   104 | 629033 |       23 |       628891
   102 | 629017 |  1229393 |             
   102 | 628942 |       28 |       628919
   102 | 628941 |       57 |       628900
   102 | 628940 |       26 |       628891
   100 | 628919 | 84295686 |             
   100 | 628900 | 87015637 |             
   100 | 628891 | 58808694 |             

컴파일 코드

리더 노드는 완전히 최적화된 컴파일 코드를 모든 클러스터 노드로 분산시킵니다. 쿼리를 컴파일하면 인터프리터와 관련된 오버헤드가 감소함으로써 특히 복잡한 쿼리의 경우 런타임 속도가 빨라집니다. 컴파일된 코드는 동일한 클러스터의 세션 간에 캐시되고 공유됩니다. 그러면 동일한 쿼리의 향후 실행은 종종 파라미터가 다른 경우에도 더 빨라질 것입니다.

쿼리 실행 엔진은 JDBC 연결 프로토콜일 때와 ODBC 연결 프로토콜일 때 컴파일하는 코드가 다르기 때문에, 클라이언트 2개가 서로 다른 프로토콜을 사용하는 경우에는 각각 코드를 컴파일하는 최초 비용이 발생합니다. 하지만 동일한 프로토콜을 사용하는 클라이언트는 캐시 코드 공유라는 이점을 누릴 수 있습니다.