쿼리 저장소에 대한 사용 시나리오 - Azure Database for PostgreSQL - 유연한 서버
적용 대상: 
Azure Database for PostgreSQL - 유연한 서버
예측 가능한 워크로드 성능을 추적하고 유지하는 것이 중요한 다양한 시나리오에서 쿼리 저장소를 사용할 수 있습니다. 다음 예를 살펴 보십시오.
- 비용이 많이 드는 쿼리를 식별하고 튜닝합니다.
- A/B 테스트를 수행합니다.
- 즉석 워크로드를 식별하고 개선합니다.
비용이 많이 드는 쿼리 식별 및 조정
장기 실행 쿼리 식별
서버 데이터베이스의 쿼리 저장소 뷰를 azure_sys 사용하여 가장 오래 실행되는 쿼리를 빠르게 식별할 수 있습니다. 이러한 쿼리는 대부분의 리소스를 사용하는 경향이 있습니다. 가장 오래 실행되는 쿼리를 최적화하면 시스템에서 실행 중인 다른 쿼리가 사용하도록 리소스를 해제하여 성능을 개선할 수 있습니다.
성능 델타를 사용하여 쿼리 대상 지정
쿼리 저장소는 성능 데이터를 시간 창으로 조각화하므로 시간이 지남에 따라 쿼리의 성능을 추적할 수 있습니다. 이를 통해 전체적인 소요 시간 증가의 원인이 되는 쿼리를 정확히 식별할 수 있습니다. 따라서 워크로드의 범위가 지정된 문제 해결을 수행할 수 있습니다.
비용이 높은 쿼리 조정
차선의 성능으로 쿼리를 식별할 경우 수행하는 작업은 문제의 특성에 따라 달라집니다. 이러한 작업 중 일부는 다음과 같을 수 있습니다.
- 쿼리에서 사용하는 기본 테이블에 대한 통계가 최신 상태인지 확인하세요.
- 비용이 많이 드는 쿼리를 다시 작성하는 것이 좋습니다. 예를 들어 쿼리 매개 변수화를 활용하고 임시 SQL 사용을 줄입니다. 애플리케이션 쪽이 아닌 데이터베이스 쪽에서 데이터 필터링을 적용하는 것과 같이 데이터를 읽을 때 최적의 논리를 구현하세요.
A/B 테스트 수행
쿼리 저장소를 사용하여 도입하려는 애플리케이션 변경 전후 또는 마이그레이션 전후의 워크로드 성능을 비교합니다. 쿼리 저장소를 사용하여 워크로드 성능에 대한 변경 내용의 영향을 평가하는 예제 시나리오:
- PostgreSQL의 주 버전 간 마이그레이션
- 애플리케이션의 새 버전 출시.
- 서버에 부여된 리소스 양 수정
- 서버 동작에 영향을 주는 서버 매개 변수 변경
- 비용이 많이 드는 쿼리가 참조하는 테이블에서 누락된 인덱스 만들기.
- Azure Database for PostgreSQL 단일 서버에서 Azure Database for PostgreSQL 유연한 서버로 마이그레이션
이러한 시나리오에서 다음 워크플로를 적용합니다.
- 계획된 변경 전에 쿼리 저장소를 사용하여 워크로드를 실행하여 성능 기준을 생성합니다.
- 제어된 시간에 원하는 변경 내용을 적용합니다.
- 변경 후 시스템의 성능을 명확하게 볼 수 있도록 충분한 시간 동안 워크로드를 계속 실행합니다.
- 변경 전과 후의 결과를 비교합니다.
- 변경 또는 롤백을 유지할지 결정합니다.
임시 워크로드 식별 및 개선
일부 워크로드에는 전체 애플리케이션 성능을 개선하기 위해 조정할 수 있는 주요 쿼리가 없습니다. 일반적으로 이러한 워크로드는 비교적 많은 고유 쿼리로 구성되고, 이러한 각 쿼리는 시스템 리소스의 일부를 소비합니다. 각 고유 쿼리는 자주 실행되지 않으므로 개별적으로 런타임 소비가 중요하지 않습니다. 반면에 애플리케이션이 항상 새 쿼리를 생성하는 경우 시스템 리소스의 상당한 부분이 쿼리 컴파일에 사용되고 이는 최적 상황이 아닙니다. 일반적으로 이 상황은 애플리케이션이 쿼리를 생성하는 경우(저장 프로시저 또는 매개 변수가 있는 쿼리를 사용하는 대신) 또는 기본적으로 쿼리를 생성하는 개체 관계형 매핑 프레임워크를 사용하는 경우 발생합니다.
애플리케이션 코드를 제어하고 있는 경우 저장 프로시저나 매개 변수가 있는 쿼리를 사용하도록 데이터 액세스 레이어를 다시 작성하는 것이 좋습니다. 그러나 전체 데이터베이스(모든 쿼리) 또는 동일한 쿼리 해시가 있는 개별 쿼리 템플릿에 대해 쿼리 매개 변수화를 강제로 적용하여 애플리케이션을 변경하지 않고도 이 상황을 개선할 수 있습니다.