BLOG
고객은 데이터웨어 하우스와 비즈니스 인텔리전스 유저가 매우 빠른 응답 시간을 원하므로 동일하게 빠른 속도로 의사 결정을 내릴 수 있다고 말합니다. 또한 데이터가 변경되지 않은 경우에도 유저가 동일한 쿼리를 반복하는 경우가 많다고 말합니다. 반복 쿼리는 실행될 때마다 컴퓨팅 리소스를 소비하므로 모든 쿼리의 성능이 저하됩니다.
이 글에서는 Amazon Redshift의 쿼리 결과 캐싱에 대해 살펴봅니다. 결과 캐싱은 이름이 적용되는 대로 정확히 수행되며 쿼리 결과를 캐시 합니다. 동일한 데이터에 대해 동일한 쿼리가 들어오면 이전 결과가 캐시에서 검색되어 동일한 쿼리를 다시 실행하는 대신 즉시 반환됩니다. 결과 캐싱은 시스템 사용을 줄여 다른 워크로드에 더 많은 리소스를 사용할 수 있게 합니다. 유저에게 보다 빠른 응답 시간을 제공하고, 모든 쿼리의 처리량을 향상시키며, 동시성을 높입니다.
결과 캐싱 옵션
데이터 웨어하우스 결과 캐싱을 구현할 수 있는 두가지 주요 방법이 있습니다. 첫번째 방법은 데이터 테이블의 하위 세트를 저장하고 데이터 웨어하우스 외부에 쿼리 결과를 캐시 하는 것입니다. 이 방법을 사용하려면 데이터 웨어하우스 외부에 로직과 메모리를 추가해야 합니다. 테이블 데이터를 수정할 때 캐시가 무효화되고 쿼리가 다시 실행되는지 확인하기 위해 각별히 주의해야 합니다.
두번째 방법은 데이터 웨어하우스 내부의 쿼리 결과를 캐시하고 이후의 반복 쿼리를 위해 캐시된 결과를 반환하는 것입니다. 이 방법은 데이터를 캐시하고 클러스터 내에서 제공하는 것이 더 빠르기 때문에 더 높은 성능을 제공합니다.
Amazon Redshift는 두번째 방법을 사용하여 클러스터 내의 쿼리 결과를 캐시하여 쿼리 처리량을 높입니다. Amazon Redshift 결과 캐싱은 데이터 및 워크로드 변경에 자동으로 응답하여 여러 BI 애플리케이션 및 SQL 툴을 투명하게 제공합니다. 이 기능은 기본적으로 모든 Amazon Redshift 고객에게 추가 비용 없이 제공됩니다.
Amazon Redshift가 결과 캐싱을 도입한 이후 이 기능을 통해 고객은 매일 수천시간의 실행 시간을 절약할 수 있었습니다. “Amazon Redshift 결과 캐싱을 통해 20%의 쿼리가 1초 안에 완료되었습니다.”라고 샌프란시스코에서 열린 AWS Summit에서 Edmunds 회사의 기술 담당 이사인 Greg Rokita가 말했습니다. “클러스터의 디스크 의존도가 감소함에 따라 클러스터가 나머지 쿼리를 더 잘 처리할 수 있게 되었습니다. 무엇보다도 업무 중심적인 워크로드를 지원하는 Redshift와 같은 속도를 내기 위해 아무것도 변경할 필요가 없었습니다.”라고 덧붙였습니다.
어떻게 작동하나요?
Amazon Redshift에서 쿼리를 실행하면 쿼리와 결과가 모두 메모리에 캐시됩니다. 이후 쿼리가 들어오면 표준화되고 캐시의 쿼리와 비교되어 반복 쿼리가 있는지 여부를 확인합니다. 이 비교에서 Amazon Redshift는 기본 데이터가 어떤 식으로든 변경되었는지도 결정합니다. 테이블이나 기능의 DML(데이터 수정 언어) 또는 DDL(데이터 정의 언어)은 해당 언어를 참조하는 캐시 항목만 무효화합니다. 이러한 문장 예시에는 삽입, 삭제, 업데이트, 복사 및 잘라내기가 포함됩니다. Amazon Redshift는 캐시 메모리를 관리하여 이전 항목을 제거하고, 캐시 자체에 대해 최적의 메모리 사용을 유지합니다.
결과 캐싱은 Amazon Redshift에 의해 완전히 관리되며, 애플리케이션 코드를 변경할 필요가 없습니다. Amazon Redshift는 클러스터의 특정 조건에 따라 최적의 구성을 자동으로 선택하므로 가장 효과적인 구성을 얻는 데 조정이 필요하지 않습니다.
Amazon Redshift는 쿼리가 캐시된 이전 쿼리 결과를 재사용할 수 있다고 결정하면 쿼리 계획, 워크로드 관리자(WLM) 및 쿼리 실행 엔진을 모두 건너뜁니다. 캐시된 결과 행은 초 미만의 성능으로 클라이언트 애플리케이션으로 즉시 반환됩니다. 이 방법을 사용하면 ETL(추출, 변환 및 로드) 및 컴퓨팅 리소스가 필요한 기타 워크로드에 대한 클러스터 리소스를 확보할 수 있습니다.
설계 및 사용
다음 다이어그램은 Amazon Redshift 결과 캐싱의 아키텍처를 보여 줍니다.
쿼리 결과 캐시는 리더 노드의 메모리에 있으며 여러 유저 세션에서 동일한 데이터베이스로 공유됩니다. 이 기능은 투명하므로 기본적으로 유저 구성 없이 작동합니다. 결과 캐싱은 Amazon Redshift MVCC(멀티 버전 동시 실행 제어)를 준수합니다. 테이블 개체에 대한 적절한 잠금을 획득하고 여러 유저 세션에서 테이블 개체를 동시에 읽기/쓰기 할 때 캐시 항목의 라이프 사이클을 관리합니다. 또한 캐시된 결과의 액세스 제어가 관리되므로 유저는 캐시에서 결과 행을 검색하는 데 쿼리에 사용되는 개체에 필요한 권한을 가지고 있어야 합니다.
결과 캐시에서 어떤 쿼리가 제공됩니까?
읽기 전용 쿼리는 일부 예외를 제외하고 캐시 할 수 있습니다. 쿼리 결과는 다음과 같은 경우에 캐시 되지 않습니다.
- 쿼리가 실행될 때마다 평가해야 하는 함수를 사용하는 경우(예: getdate())
- 쿼리가 시스템 테이블 또는 뷰를 참조하는 경우
- 쿼리가 외부 테이블, 즉 Amazon Redshift 스펙트럼 테이블을 참조할 때
- 쿼리가 리더 노드에서만 실행되거나 결과가 너무 큰 경우.
쿼리에 현재_날짜(current_date)와 같은 기능이 포함되어 있고 결과 캐시를 이용하려고 한다고 가정합니다. 현재_날짜(current_date) 값(예: JDBC애플리케이션에서)을 실현하고 쿼리 텍스트를 사용하여 필요에 따라 새로 고침으로써 쿼리 다시 쓰기를 고려할 수 있습니다.
캐시에서 제공된 결과에서 실행된 쿼리를 확인하기 위해 캐시에서 쿼리가 실행될 때 소스 쿼리 ID를 기록하기 위해 새 열 source_query가 시스템 보기 SVL_QLOG에 추가되었습니다.다음 예제 쿼리를 사용하여 캐시된 결과를 사용한 쿼리를 확인할 수 있습니다.
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 |
결과 캐시 사용에 대한 자세한 내용은 Amazon Redshift 문서의 결과 캐싱을 참조하십시오.
요약
Amazon Redshift 결과 캐싱은 반복 쿼리에 낭비되는 컴퓨팅 리소스가 없도록 하는 데 도움이 됩니다. 더 짧은 시간에 더 많은 분석을 수행하여 의사 결정을 지원하고 결과를 개선할 수 있습니다. 이 글에서는 Amazon Redshift 결과 캐싱이 어떻게 작동하는지 설명하고 Amazon Redshift 고객들에게 미치는 중요한 영향에 대해 논의했습니다. 결과 캐싱은 자동으로 사용하도록 설정되며, 환경의 차이를 확인하는 것이 좋습니다.
원문 URL: https://aws.amazon.com/ko/blogs/big-data/get-sub-second-query-response-times-with-amazon-redshift-result-caching/
** 메가존 TechBlog는 AWS BLOG 영문 게재글중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.