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