구체화된 보기

  • 아티클

구체화된 뷰는 원본 테이블 또는 다른 구체화된 뷰를 통해 집계 쿼리를 노출합니다.

구체화된 뷰는 항상 집계 쿼리의 최신 결과를 반환합니다(항상 최신). 구체화된 뷰를 쿼리하는 것은 원본 테이블을 통해 직접 집계를 실행하는 것보다 성능이 높습니다.

참고

구체화된 뷰를 사용하는 이유는 무엇인가요?

일반적으로 사용되는 집계의 구체화된 뷰에 리소스(데이터 스토리지, 백그라운드 CPU 주기)를 투자하면 다음과 같은 이점이 있습니다.

  • 성능 향상: 구체화된 뷰를 쿼리하는 것은 일반적으로 동일한 집계 함수에 대해 원본 테이블을 쿼리하는 것보다 더 잘 수행됩니다.

  • 신선도: 구체화된 뷰 쿼리는 구체화가 마지막으로 발생한 시점과 관계없이 항상 최신 결과를 반환합니다. 쿼리는 뷰의 구체화된 부분을 원본 테이블의 레코드와 결합합니다. 이 레코드는 아직 구체화되지 않았으며( delta 파트) 항상 최신 결과를 제공합니다.

  • 비용 절감:구체화된 뷰를 쿼리하면 원본 테이블에 대한 집계보다 클러스터의 리소스가 적게 소비됩니다. 집계만 필요한 경우 원본 테이블의 보존 정책을 줄일 수 있습니다. 이 설정은 원본 테이블에 대한 핫 캐시 비용을 줄입니다.

예제 사용 사례는 구체화된 뷰 사용 사례를 참조하세요.

구체화된 뷰의 작동 방식

구체화된 뷰는 다음 두 가지 구성 요소로 구성됩니다.

  • 구체화된 부분 - 이미 처리된 원본 테이블의 집계된 레코드를 보유하는 테이블입니다. 이 테이블은 항상 집계의 그룹별 조합당 단일 레코드를 보유합니다.
  • 델타 - 아직 처리되지 않은 원본 테이블에서 새로 수집된 레코드입니다.

구체화된 뷰를 쿼리하면 구체화된 부분이 델타 부분과 결합되어 집계 쿼리의 최신 결과를 제공합니다. 오프라인 구체화 프로세스는 델타 에서 구체화된 테이블로 새 레코드를 수집하고 기존 레코드를 업데이트합니다. 델타와 구체화된 부분 간의 교집합이 크고 많은 레코드에 업데이트가 필요한 경우 구체화 프로세스에 부정적인 영향을 미칠 수 있습니다. 이러한 상황을 해결하는 방법에 대한 구체화된 뷰 모니터링 을 참조하세요.

구체화된 뷰 쿼리

구체화된 뷰를 쿼리하는 방법에는 두 가지가 있습니다.

  • 전체 뷰 쿼리: 구체화된 뷰를 테이블 쿼리와 마찬가지로 이름으로 쿼리할 때 구체화된 뷰 쿼리는 구체화된 뷰 부분을 아직 구체화되지 않은 원본 테이블의 레코드와 결합 합니다( delta).

    • 구체화된 뷰를 쿼리하면 원본 테이블에 수집된 모든 레코드에 따라 항상 최신 결과가 반환됩니다. 구체화된 뷰에서 구체화된 부분과 구체화되지 않은 부분에 대한 자세한 내용은 구체화된 뷰의 작동 방식을 참조하세요.
    • 이 옵션은 쿼리 시간 동안 파트를 구체화 delta 해야 하므로 가장 잘 수행되지 않을 수 있습니다. 이 경우 성능은 뷰의 기간과 쿼리에 적용된 필터에 따라 달라집니다. 구체화된 뷰 쿼리 최적화 프로그램 섹션에는 전체 뷰를 쿼리할 때 쿼리 성능을 향상시킬 수 있는 방법이 포함되어 있습니다.

  • 구체화된 부분만 쿼리: 뷰를 쿼리하는 또 다른 방법은 함수를 사용하는 것입니다materialized_view(). 이 옵션은 사용자가 허용할 최대 대기 시간을 지정하면서 뷰의 구체화된 부분만 쿼리할 수 있도록 지원합니다.

    • 이 옵션은 최신 레코드를 반환하도록 보장되지는 않지만 항상 전체 보기를 쿼리하는 것보다 성능이 더 높아야 합니다.
    • 이 함수는 원격 분석 대시보드와 같이 성능을 위해 약간의 새로 고침을 희생하려는 시나리오에 유용합니다.

팁

구체화된 부분에 대한 쿼리는 항상 전체 뷰를 쿼리하는 것보다 더 나은 성능을 발휘합니다. 사용 사례에 materialized_view() 해당하는 경우 항상 함수를 사용합니다.

  • 구체화된 뷰는 클러스터 간 또는 데이터베이스 간 쿼리에 참여하지만 와일드카드 공용 구조체 또는 검색에는 포함되지 않습니다.

    • 다음 예제에는 모두 이름으로 ViewName구체화된 뷰가 포함됩니다.
    cluster('cluster1').database('db').ViewName
cluster('cluster1').database('*').ViewName
database('*').ViewName
database('DB*').ViewName
database('*').materialized_view('ViewName')
database('DB*').materialized_view('ViewName')
    • 다음 예제에는 구체화된 뷰의 레코드가 포함되지 않습니다 .
    cluster('cluster1').database('db').*
database('*').View*
search in (*)
search *

구체화된 뷰 쿼리 최적화 프로그램

전체 뷰를 쿼리할 때 구체화된 부분은 쿼리 시간 동안 과 delta 결합됩니다. 여기에는 를 집계하고 delta 구체화된 부분과 조인하는 것이 포함됩니다.

  • 쿼리에 구체화된 뷰 쿼리의 키로 그룹에 대한 필터가 포함된 경우 전체 뷰를 쿼리하는 것이 더 좋습니다. 성능 팁 섹션에서 쿼리 패턴 .create materialized-view 에 따라 구체화된 뷰를 만드는 방법에 대한 자세한 팁을 참조하세요.
  • 쿼리 최적화 프로그램은 쿼리 성능을 향상시킬 것으로 예상되는 요약/조인 전략을 선택합니다. 예를 들어 쿼리 순서를 섞 을지 여부에 대한 결정은 부분적으로 레코드 delta 수를 기반으로 합니다. 다음 클라이언트 요청 속성 은 적용된 최적화에 대한 일부 제어를 제공합니다. 구체화된 뷰 쿼리를 사용하여 이러한 속성을 테스트하고 쿼리 성능에 미치는 영향을 평가할 수 있습니다.
클라이언트 요청 속성 이름 형식 Description
materialized_view_query_optimization_costbased_enabled bool 로 false설정하면 구체화된 뷰 쿼리에서 요약/조인 최적화를 사용하지 않도록 설정합니다. 기본 전략을 사용합니다. 기본값은 true입니다.
materialized_view_shuffle dynamic 구체화된 뷰 쿼리를 강제로 섞고(선택 사항) 순서를 섞을 특정 키를 제공합니다. 아래 예제를 참조하세요.

예제

  1. 전체 보기를 쿼리합니다. 원본 테이블의 최신 레코드는 다음과 같습니다.

    ViewName

  2. 마지막으로 구체화된 시점과 관계없이 뷰의 구체화된 부분만 쿼리합니다.

    materialized_view("ViewName")

  3. 전체 보기를 쿼리하고 전략을 사용하기 shuffle 위한 "힌트"를 제공합니다. 원본 테이블의 최신 레코드는 다음과 같습니다.

    • 예제 #1: 열을 기반으로 Id 순서 섞기(사용과 유사)hint.shufflekey=Id
    set materialized_view_shuffle = dynamic([{"Name" : "ViewName", "Keys" : [ "Id" ] }]);
ViewName
    • 예제 #2: 모든 키에 따라 순서 섞기(사용과 유사)hint.strategy=shuffle
    set materialized_view_shuffle = dynamic([{"Name" : "ViewName" }]);
ViewName

성능 고려 사항

구체화된 뷰 상태에 영향을 미칠 수 있는 기본 기여자는 다음과 같습니다.

  • 클러스터 리소스: 클러스터에서 실행되는 다른 프로세스와 마찬가지로 구체화된 뷰는 클러스터의 리소스(CPU, 메모리)를 사용합니다. 클러스터가 오버로드된 경우 구체화된 뷰를 추가하면 클러스터 성능이 저하될 수 있습니다. 클러스터 상태 메트릭을 사용하여 클러스터의 상태를 모니터링합니다. 최적화된 자동 크기 조정 은 현재 자동 크기 조정 규칙의 일부로 고려 중인 구체화된 뷰 상태를 고려하지 않습니다.

  • 구체화된 데이터와 겹칩니다 . 구체화하는 동안 마지막 구체화(델타) 이후 원본 테이블에 수집된 모든 새 레코드가 처리되고 뷰로 구체화됩니다. 새 레코드와 이미 구체화된 레코드 간의 교차점이 높을수록 구체화된 뷰의 성능이 저하됩니다. 구체화된 뷰는 업데이트되는 레코드 수(예 arg_max : 보기)가 원본 테이블의 작은 하위 집합인 경우에 가장 적합합니다. 구체화된 뷰 레코드의 전부 또는 대부분을 모든 구체화 주기에서 업데이트해야 하는 경우 구체화된 뷰가 잘 수행되지 않을 수 있습니다.

  • 수집 속도: 구체화된 뷰의 원본 테이블에는 데이터 볼륨 또는 수집 속도에 하드 코딩된 제한이 없습니다. 그러나 구체화된 뷰에 권장되는 수집 속도는 1~2GB/초 이하입니다. 높은 수집 속도는 여전히 잘 수행 될 수 있습니다. 성능은 클러스터 크기, 사용 가능한 리소스 및 기존 데이터와의 교집합 양에 따라 달라집니다.

  • 클러스터의 구체화된 뷰 수: 위의 고려 사항은 클러스터에 정의된 각 구체화된 뷰에 적용됩니다. 각 보기는 자체 리소스를 사용하며, 많은 보기가 사용 가능한 리소스에서 서로 경쟁합니다. 클러스터의 구체화된 뷰 수에 대한 하드 코딩된 제한은 없지만 정의된 뷰가 많을 때 클러스터가 구체화된 모든 뷰를 처리하지 못할 수 있습니다. 클러스터에 구체화된 뷰가 하나 이상 있는 경우 용량 정책을 조정할 수 있습니다. 정책에서 의 ClusterMinimumConcurrentOperations 값을 늘려 더 구체화된 뷰를 동시에 실행합니다.

  • 구체화된 뷰 정의: 구체화된 뷰 정의는 최상의 쿼리 성능을 위해 쿼리 모범 사례에 따라 정의되어야 합니다. 자세한 내용은 명령 성능 팁 만들기를 참조하세요.

구체화된 뷰를 통해 구체화된 뷰

구체화된 원본 뷰가 중복 제거 뷰인 경우 다른 구체화된 뷰를 통해 구체화된 뷰를 만들 수 있습니다. 특히 원본 레코드를 중복 제거하려면 구체화된 원본 뷰의 집계가 있어야 take_any(*) 합니다. 구체화된 두 번째 뷰는 지원되는 집계 함수를 사용할 수 있습니다. 구체화된 뷰를 통해 구체화된 뷰를 만드는 방법에 대한 자세한 내용은 명령을 참조하세요.create materialized-view.

팁

구체화된 다른 뷰를 통해 정의된 구체화된 뷰를 쿼리할 때는 함수를 사용하여 materialized_view() 구체화된 부분만 쿼리하는 것이 좋습니다. 두 보기가 완전히 구체화되지 않으면 전체 뷰 쿼리가 수행되지 않습니다. 자세한 내용은 구체화된 뷰 쿼리를 참조하세요.

관련 콘텐츠