다음을 통해 공유


구체화된 보기

적용 대상: ✅Microsoft Fabric✅Azure Data Explorer

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

구체화된 뷰는 항상 집계 쿼리의 최신 결과를 반환합니다(항상 새로 고침). 구체화된 뷰 를 쿼리하는 것은 원본 테이블에서 직접 집계를 실행하는 것보다 성능이 뛰어난다.

참고 항목

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

일반적으로 사용되는 집계의 구체화된 뷰에 리소스(데이터 스토리지, 백그라운드 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 * 
    
  • 구체화된 뷰는 이벤트 하우스 간 또는 데이터베이스 간 쿼리에 참여하지만 와일드카드 공용 구조체 또는 검색에는 포함되지 않습니다.

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

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

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

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

ingestion_time() 구체화된 뷰의 컨텍스트에서 함수

ingestion_time() 함수는 전체 뷰를 쿼리하는 경우 구체화된 뷰의 컨텍스트에서 사용될 때 null 값을 반환합니다. 뷰의 구체화된 부분을 쿼리할 때 반환 값은 구체화된 뷰의 형식에 따라 달라집니다.

  • 단일 arg_max()/arg_min()take_any()/집계 ingestion_time() 를 포함하는 구체화된 뷰에서는 원본 테이블의 해당 레코드와 같습니다.ingestion_time()
  • 다른 모든 구체화된 뷰에서 값 ingestion_time() 은 구체화의 대략적인 시간입니다(구체화된 뷰의 작동 방식 참조).

예제

  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() 구체화된 부분을 쿼리하는 것이 좋습니다. 두 보기가 모두 완전히 구체화되지 않은 경우 전체 뷰 쿼리는 수행되지 않습니다. 자세한 내용은 구체화된 뷰 쿼리를 참조 하세요.