Amazon Aurora MySQL용 병렬 쿼리
이 주제에서는 Amazon Aurora MySQL 호환 버전의 병렬 쿼리 성능 최적화에 대해 설명합니다. 이 기능은 특정 데이터 집약적인 쿼리를 위한 특수한 처리 경로를 사용하면서 Aurora 공유 스토리지 아키텍처를 활용합니다. 병렬 쿼리는 수만 개의 행이 포함된 테이블이 있는 Aurora MySQL DB 클러스터 및 완료되기까지 몇 분 또는 몇 시간이 걸리는 분석 쿼리에서 가장 잘 작동합니다.
주제
Aurora MySQL용 Parallel Query 개요
Aurora MySQL 병렬 쿼리는 데이터 집약적인 쿼리 처리에 수반되는 I/O 및 컴퓨팅의 일부를 병렬화하는 최적화입니다. 병렬화되는 작업은 스토리지로부터 행 검색, 열 값 추출, 어떤 행이 WHERE
절 및 JOIN 절의 조건과 일치하는지 판단을 포함합니다. 이 데이터 집약적인 작업은 Aurora 분산 스토리지 계층의 여러 노드에 위임됩니다(데이터베이스 최적화 용어로는 푸시 다운됩니다). 병렬 쿼리가 없으면, 각 쿼리가 스캔한 모든 데이터를 Aurora MySQL 클러스터(헤드 노드) 내의 단일 노드로 가져오고 거기에서 모든 쿼리 처리를 수행합니다.
작은 정보
PostgreSQL 데이터베이스 엔진에도 '병렬 쿼리'라는 기능이 있습니다. 해당 기능은 Aurora 병렬 쿼리와 관련이 없습니다.
병렬 쿼리 기능을 설정하면 Aurora MySQL 엔진이 힌트 또는 테이블 속성과 같은 SQL 변경의 필요 없이 쿼리가 혜택을 얻을 수 있는 경우를 자동으로 결정합니다. 다음 단원에는서 병렬 쿼리가 쿼리에 적용되는 경우에 대한 설명을 확인할 수 있습니다. 또한 병렬 쿼리가 가장 많은 혜택을 제공하는 경우에 적용되게 하는 방법도 확인할 수 있습니다.
참고
병렬 쿼리 최적화는 완료하는 데 몇 분 또는 몇 시간이 걸리는 장기 실행 쿼리에 가장 큰 이점을 제공합니다. Aurora MySQL은 일반적으로 비용이 적게 드는 쿼리에 대해 병렬 쿼리 최적화를 수행하지 않습니다. 또한 쿼리 캐싱, 버퍼 풀 캐싱, 인덱스 조회를 비롯한 다른 최적화 기술이 더 적합한 경우에도 일반적으로 병렬 쿼리 최적화를 수행하지 않습니다. 병렬 쿼리가 사용될 것으로 예상될 때 사용되고 있지 않은 경우 어떤 문이 Aurora MySQL의 병렬 쿼리를 사용하는지 확인 단원을 참조하세요.
이점
병렬 쿼리를 사용하면 Aurora MySQL 테이블에 대해 데이터 집약적인 분석 쿼리를 실행할 수 있으며, 대부분의 경우 쿼리 처리를 위한 전통적인 작업 분할에 비해 획기적인 성능 향상이 나타날 수 있습니다.
병렬 쿼리의 이점은 다음과 같습니다.
-
여러 스토리지 노드에 걸친 물리적 읽기 요청을 병렬화하여 I/O 성능 개선
-
네트워크 트래픽 감소. Aurora는 전체 데이터 페이지를 스토리지 노드로부터 헤드 노드로 전송한 다음 그 후에 불필요한 행과 열을 필터링하지 않습니다. 대신, Aurora은 결과 집합에 필요한 열 값만 포함된 간소화된 튜플을 전송합니다.
-
푸시 다운 기능 처리, 행 필터링 및
WHERE
절에 대한 열 프로젝션으로 인한 헤드 노드에 대한 CPU 사용량의 감소. -
버퍼 풀에서의 메모리 압력 감소. 병렬 쿼리에 의해 처리된 페이지는 버퍼 풀에 추가되지 않으므로 데이터 집약적인 스캔 중 버퍼 풀에서 자주 사용되는 데이터가 제거될 가능성이 감소됩니다.
-
기존 데이터에 대한 장기 실행 분석 쿼리 수행이 유용해진 덕분에 추출, 변환, 로드(ETL) 파이프라인에서 데이터 중복의 잠재적 감소.
아키텍처
병렬 쿼리 기능은 Aurora MySQL의 주요 아키텍처 원칙을 사용합니다. 스토리지 하위 시스템으로부터 데이터베이스 엔진의 결합 해제 및 통신 프로토콜을 간소화하여 네트워크 트래픽을 감소합니다. Aurora MySQL은 이러한 기법을 사용하여 다시 실행 로그 처리와 같은 쓰기 집약적인 작업의 속도를 높입니다. 병렬 쿼리는 읽기 작업에도 동일한 원칙을 적용합니다.
참고
Aurora MySQL 병렬 쿼리의 아키텍처는 다른 데이터베이스 시스템에서 이름이 유사한 기능의 아키텍처와는 다릅니다. Aurora MySQL 병렬 쿼리는 SMP(대칭적 다중 처리)를 포함하지 않으며 따라서 데이터베이스 서버의 CPU 용량에 의존하지 않습니다. 병렬 처리는 쿼리 조정자 역할을 하는 Aurora MySQL 서버와는 독립적인 스토리지 계층에서 일어납니다.
기본적으로, 병렬 쿼리를 사용하지 않을 경우 Aurora 쿼리에 대한 처리는 원시 데이터를 Aurora 클러스터 내 단일 노드(헤드 노드)로 전송합니다. 그런 다음 Aurora는 해당 단일 노드의 단일 스레드에서 해당 쿼리에 대해 추가되는 모든 처리를 수행합니다. 병렬 쿼리를 사용할 경우, 이러한 I/O 집약적이고 CPU 집약적인 작업의 대부분이 스토리지 계층의 노드로 위임됩니다. 행은 이미 필터링되고 열 값은 이미 추출되어 전송된 상태로, 결과 집합의 간소화된 행만 다시 헤드 노드로 전송됩니다. 성능 혜택은 네트워크 트래픽의 감소, 헤드 노드에서 CPU 사용량의 감소, 및 스토리지 노드 전체에서 I/O 병렬화로부터 비롯됩니다. 병렬 I/O, 필터링 및 프로젝션의 양은 쿼리를 실행하는 Aurora 클러스터의 DB 인스턴스 수와 무관합니다.
사전 조건
병렬 쿼리의 모든 기능을 사용하려면 버전 2.09 이상을 실행하는 Aurora MySQL DB 클러스터가 필요합니다. 병렬 쿼리와 함께 사용하려는 클러스터가 이미 있는 경우 호환 가능한 버전으로 업그레이드하고 나중에 병렬 쿼리를 설정할 수 있습니다. 이 경우 해당 최신 버전에서는 구성 설정 이름 및 기본값이 다르기 때문에 병렬 쿼리를 위한 업그레이드 고려 사항의 업그레이드 절차를 따라야 합니다.
클러스터의 DB 인스턴스는 db.r*
인스턴스 클래스를 사용해야 합니다.
클러스터에 대해 해시 조인 최적화가 설정되어 있는지 확인합니다. 자세한 방법은 병렬 쿼리 클러스터에 대한 해시 조인 설정 단원을 참조하십시오.
aurora_parallel_query
및 aurora_disable_hash_join
과 같은 파라미터를 사용자 지정하려면 클러스터와 함께 사용하는 사용자 지정 파라미터 그룹이 있어야 합니다. DB 파라미터 그룹을 사용하여 각 DB 인스턴스에 대해 이러한 파라미터를 개별적으로 지정할 수 있습니다. 그러나 DB 클러스터 파라미터 그룹에서 지정하는 것이 좋습니다. 이렇게 하면 클러스터의 모든 DB 인스턴스가 이러한 파라미터에 대해 동일한 설정을 상속합니다.
제한 사항
다음 제한 사항이 병렬 쿼리 기능에 적용됩니다.
-
병렬 쿼리는 Aurora I/O-Optimized DB 클러스터 스토리지 구성에서 지원되지 않습니다.
-
db.t2 또는 db.t3 인스턴스 클래스에는 병렬 쿼리를 사용할 수 없습니다. 이 제한은
aurora_pq_force
세션 변수를 사용하여 병렬 쿼리를 요청하는 경우에도 적용됩니다. -
병렬 쿼리는
COMPRESSED
또는REDUNDANT
행 형식을 사용하는 테이블에는 적용되지 않습니다. 병렬 쿼리에 사용하려는 테이블에는COMPACT
또는DYNAMIC
행 형식을 사용합니다. -
Aurora는 비용 기반 알고리즘을 사용하여 각 SQL 문에 대해 병렬 쿼리 메커니즘을 사용할지 여부를 결정합니다. 명령문에서 특정 SQL 구문을 사용하면 병렬 쿼리가 방지되거나 해당 명령문에 대해 병렬 쿼리가 실행되지 않을 수 있습니다. SQL 구문과 병렬 쿼리의 호환성에 대한 자세한 내용은 Aurora MySQL의 병렬 쿼리를 위한 SQL 구성 단원을 참조하세요.
-
각 Aurora DB 인스턴스는 한 번에 일정한 수의 병렬 쿼리 세션만 실행할 수 있습니다. 쿼리에 하위 쿼리, 조인 또는
UNION
연산자 같은 병렬 쿼리를 사용하는 여러 부분이 있는 경우, 그러한 단계가 순차적으로 실행됩니다. 구문은 한 시점에 단일 병렬 쿼리 세션으로만 계산됩니다. 병렬 쿼리 상태 변수를 사용하여 활성 세션의 수를 모니터링할 수 있습니다. 상태 변수Aurora_pq_max_concurrent_requests
를 쿼리하여 주어진 DB 인스턴스의 동시 세션에 대한 제한을 확인할 수 있습니다. -
병렬 쿼리는 Aurora가 지원되는 모든 AWS 리전에서 사용할 수 있습니다. 대부분의 AWS 리전에서 병렬 쿼리를 사용하는 데 필요한 최소 Aurora MySQL 버전은 2.09입니다.
-
병렬 쿼리는 데이터 집약적인 쿼리의 성능을 향상하도록 설계되었습니다. 경량 쿼리용으로 설계되지 않았습니다.
-
SELECT 문, 특히 데이터 집약적인 문에는 리더 노드를 사용하는 것이 좋습니다.
병렬 쿼리를 사용할 경우 I/O 비용
Aurora MySQL 클러스터가 병렬 쿼리를 사용하는 경우 VolumeReadIOPS
값이 증가할 수 있습니다. 병렬 쿼리는 버퍼 풀을 사용하지 않습니다. 따라서 쿼리는 빠르지만 이렇게 최적화된 프로세싱은 읽기 작업 및 관련 비용을 증가시킬 수 있습니다.
쿼리에 대한 병렬 쿼리 I/O 비용은 스토리지 계층에서 측정되며 병렬 쿼리를 켠 상태에서 같거나 더 커집니다. 이를 통해 얻을 수 있는 이점은 쿼리 성능이 향상된다는 것입니다. 병렬 쿼리를 사용할 경우 I/O 비용이 높아질 수 있는 두 가지 이유가 있습니다.
-
테이블의 일부 데이터가 버퍼 풀에 있더라도 병렬 쿼리는 스토리지 계층에서 모든 데이터를 스캔해야 하므로 I/O 비용이 발생합니다.
-
병렬 쿼리를 실행해도 버퍼 풀이 워밍업되지 않습니다. 결과적으로 동일한 병렬 쿼리를 연속으로 실행하면 전체 I/O 비용이 발생합니다.