쿼리 성능에 영향을 미치는 요인

노드, 프로세서 또는 조각 수 – 컴퓨팅 노드는 조각으로 분할됩니다. 노드가 많아질수록 프로세서와 조각의 수도 늘어난다는 것을 의미합니다. 그러면 쿼리를 다수의 조각으로 나눠 동시에 실행하기 때문에 쿼리의 처리 속도를 높일 수 있습니다. 하지만 노드 추가는 비용 증가를 의미하기 때문에 시스템에 적합한 가성비를 찾는 것이 중요합니다. Amazon Redshift 클러스터 아키텍처에 대한 자세한 내용은 데이터 웨어하우스 시스템 아키텍처 섹션을 참조하세요.

노드 유형 - Amazon Redshift 클러스터는 여러 노드 유형 중 하나를 사용할 수 있습니다. 각 노드 유형마다 크기와 제한이 다르기 때문에 상황에 따라 클러스터를 확장하는 데도 좋습니다. 노드 크기는 스토리지 용량, 메모리, CPU, 그리고 클러스터의 각 노드 요금을 결정합니다. 노드 유형에 대한 자세한 내용은 Amazon Redshift 관리 가이드의 Amazon Redshift 클러스터의 개요 섹션을 참조하세요.

데이터 분산 - Amazon Redshift는 테이블의 배포 스타일에 따라 테이블 데이터를 컴퓨팅 노드에 저장합니다. 쿼리를 실행하면 쿼리 옵티마이저가 필요에 따라 데이터를 컴퓨팅 노드로 다시 분산시켜 조인 및 집계를 실행합니다. 테이블에 적합한 분산 스타일을 선택하면 조인에 앞서서 데이터를 필요한 것에 배치하여 재분산 단계의 영향을 최소화하는 데 효과적입니다. 자세한 내용은 쿼리 최적화를 위한 데이터 배포 섹션을 참조하세요.

데이터 정렬 순서 – Amazon Redshift는 테이블의 정렬 키에 따라 테이블 데이터를 정렬 순서대로 디스크에 저장합니다. 쿼리 옵티마이저와 쿼리 프로세서는 데이터 배치 정보를 사용하여 스캔할 블록 수를 줄이기 때문에 쿼리 속도를 높이는 데도 유용합니다. 자세한 내용은 정렬 키 섹션을 참조하세요.

데이터 집합 크기 – 클러스터의 데이터 볼륨이 높을수록 스캔 및 재분산이 필요한 행이 늘어나기 때문에 쿼리 성능이 느려질 수 있습니다. 이때는 주기적인 정리 작업(VACUUM)과 데이터 아카이빙, 그리고 조건자를 사용한 쿼리 데이터 세트 제한을 통해 이러한 성능 문제를 완화할 수 있습니다.

동시 작업 – 한 번에 다수의 작업을 실행하면 쿼리 성능에 영향을 미칠 수 있습니다. 각 작업마다 유효한 쿼리 대기열에서 슬롯을 1개 이상 사용할 뿐만 아니라 각 슬롯에 연결되어 있는 메모리를 사용하기 때문입니다. 다른 작업이 실행 중이라면 사용 가능한 쿼리 대기열 슬롯 수가 부족할 수 있습니다. 이로 인해 사용 가능한 슬롯이 열릴 때까지 기다린 후에 쿼리 처리를 시작할 수 있습니다. 쿼리 대기열의 생성 및 구성에 대한 자세한 내용은 워크로드 관리 섹션을 참조하세요.

쿼리 구조 – 쿼리 작성 방식 또한 성능에 영향을 미칩니다. 따라서 가능하다면 요건에 따라 최소한의 데이터를 처리하여 반환할 수 있도록 쿼리를 작성하는 것이 좋습니다. 자세한 내용은 Amazon Redshift 쿼리 설계 모범 사례 섹션을 참조하세요.

코드 컴파일 – Amazon Redshift는 각 쿼리 실행 계획마다 코드를 생성하여 컴파일합니다.

컴파일된 코드는 인터프리터 사용에 따른 오버헤드를 제거하기 때문에 실행 속도가 더욱 빠릅니다. 단, 처음 코드를 생성 및 컴파일할 때는 오버헤드 비용이 일부 발생하기 마련입니다. 결과적으로 쿼리를 처음 실행할 때의 성능을 잘못 판단할 수가 있습니다. 오버헤드 비용은 특히 한 번 쿼리를 실행할 때 현저히 발생할 수 있습니다. 따라서 쿼리를 두 번 실행하여 일반적인 성능을 결정해야 합니다. Amazon Redshift는 서버리스 컴파일 서비스를 사용하여 Amazon Redshift 클러스터의 컴퓨팅 리소스 이상으로 쿼리 컴파일을 확장합니다. 컴파일된 코드 세그먼트는 클러스터와 거의 무제한 캐시에 로컬로 캐시됩니다. 이 캐시는 클러스터 재부팅 후에도 유지됩니다. 동일한 쿼리의 후속 실행은 컴파일 단계를 건너뛸 수 있기 때문에 더 빠르게 실행됩니다.

캐시는 Amazon Redshift 버전 간에 호환되지 않으므로 컴파일 캐시가 플러시되고 버전 업그레이드 후 쿼리가 실행될 때 코드가 다시 컴파일됩니다. 쿼리에 엄격한 SLA가 있는 경우 클러스터 테이블의 데이터를 스캔하는 쿼리 세그먼트를 미리 실행하는 것이 좋습니다. 이를 통해 Amazon Redshift는 기본 테이블 데이터를 캐시하여 버전 업그레이드 후 쿼리를 계획하는 시간을 줄일 수 있습니다. Amazon Redshift는 확장 가능한 컴파일 서비스를 사용하여 코드를 병렬로 컴파일하여 일관되게 빠른 성능을 제공할 수 있습니다. 워크로드 속도 향상의 규모는 쿼리의 복잡성과 동시성에 따라 다릅니다.