Azure Synapse Analythics의 소재 뷰 사용

소재 보기
RDBMS에도 데이터베이스에서 구현된 소재 보기가 많은데 이른바'실체를 가진 보기'다.일반적인 보기에는 실제 데이터가 없지만 소재 보기에는 실체로 데이터가 보존되어 있다.
일반 뷰를 사용하는 경우 질의는 뷰 정의와 같이 베이스 테이블로 이동되지만 재료 뷰의 경우 베이스 테이블은 질의를 수행하지 않고 솔리드를 유지한 재료 뷰에서 질의 결과를 반환합니다.
JOIN과 합계 함수를 포함하는 복잡한 조회 사용 소재 보기는 JOIN과 합계의 결과를 미리 실체로 저장하여 조회의 속도를 높일 수 있다.(단, 소재 보기를 업데이트하는 시간이 필요하다.)
소재 보기는 자동으로 사용되기 때문에 다시 쓸 필요가 없습니다
Azure Synapse Analythics의 소재 뷰가 생성되면 질의에서 자동으로 사용됩니다.따라서 복잡한 조회는 소재 보기만 만들고 조회를 고칠 필요가 없으면 조회 속도를 높일 수 있다.
나는 실제로 이 동작을 시험해 볼 것이다.
먼저 다음 질의를 수행합니다.
(쿼리는 TPCH의 세 번째 쿼리입니다.TPC-H를 사용하여 테스트 환경 만들기(Synapse SQL 풀)

/* TPC_H Query 3 - Shipping Priority */
SELECT TOP 10
     L_ORDERKEY
    ,SUM(L_EXTENDEDPRICE*(1-L_DISCOUNT)) AS REVENUE
    ,O_ORDERDATE
    ,O_SHIPPRIORITY
FROM 
     CUSTOMER
    ,ORDERS
    ,LINEITEM
WHERE
    C_MKTSEGMENT = 'BUILDING'
    AND C_CUSTKEY = O_CUSTKEY
    AND L_ORDERKEY = O_ORDERKEY
    AND O_ORDERDATE < '1995-03-15' AND L_SHIPDATE > '1995-03-15'
GROUP BY L_ORDERKEY, O_ORDERDATE, O_SHIPPRIORITY
ORDER BY REVENUE DESC, O_ORDERDATE

이 질의의 실행 결과는 약 1분입니다.

실행 계획은 다음과 같다SHUFFLE_MOVE.

여기서 다음 재료 뷰를 만듭니다.

CREATE MATERIALIZED VIEW REVENUE_MV WITH(DISTRIBUTION=HASH(L_ORDERKEY)) AS
SELECT
     L_ORDERKEY
    ,O_ORDERDATE
    ,O_SHIPPRIORITY
    ,C_MKTSEGMENT
    ,L_SHIPDATE
    ,SUM(L_EXTENDEDPRICE*(1-L_DISCOUNT)) AS REVENUE
FROM
     dbo.CUSTOMER
    ,dbo.ORDERS
    ,dbo.LINEITEM
WHERE
        C_CUSTKEY = O_CUSTKEY
    AND L_ORDERKEY = O_ORDERKEY
GROUP BY
     L_ORDERKEY
    ,O_ORDERDATE
    ,O_SHIPPRIORITY
    ,C_MKTSEGMENT
    ,L_SHIPDATE
;

또한 다음 SQL을 통해 제작된 소재 뷰를 확인할 수 있습니다.

--マテリアライズドビューの確認
SELECT V.name as materialized_view, V.object_id
FROM sys.views V
JOIN sys.indexes I ON V.object_id= I.object_id AND I.index_id < 2;

재료 뷰 작성이 완료되면 방금 수행한 질의를 다시 실행합니다. 수행 시간은 약 5초입니다.

질의의 실행 계획도 재료 뷰를 작성하여 참조 객체를 재료 뷰로 변경하여 더욱 간단해집니다.

이렇게 하면 Azure Synapse Analythics의 소재 뷰를 질의를 덮어쓰지 않고 자동으로 사용할 수 있어 매우 편리합니다.
소재 보기의 업데이트는 자동입니다.기본 테이블 업데이트 시 동시에 구현
소재소재시도는 실체가 있는 보기이기 때문에 소재소재시도가 참고하는 기초표가 변경되었을 때 소재소재시도도 갱신이 필요하다.이 재료 뷰의 업데이트 작업은 Azure Synapse Analythics에서 참조된 베이스 테이블이 업데이트되면 자동으로 업데이트됩니다.기본표와 소재 보기는 모두 같은 거래를 통해 업데이트된 것이다.
따라서 소재시도를 제작할 경우 소재시도의 갱신 관계로 인해 자연스럽게 기초표의 갱신 처리와 데이터 로드 처리가 무거워질 수 있으므로 주의해야 한다.또한 얼마나 무거워질지는 제작된 소재 보기의 내용과 기초 표의 크기에 달려 있다.
소재 보기 사용
일반적인 상황에서 다음과 같은 상황에서 소재의 사용을 많이 연구한다.
거대한 표의 복잡한 분석 조회 성능을 향상시키다
복잡한 분석용 조회는 실행 계획에서 많은 SHUFFLE_MOVE와BROADCAST_MOVE 등의 데이터를 생성하여 조회를 길게 한다.
이 경우 질의에서 많이 사용되는 곳(내부뷰 등)에서 소재 뷰를 사용하면 소재 뷰에서 결과를 되돌릴 수 있어 속도를 낼 수 있다.
질의를 변경하지 않고 성능 향상
소재 보기의 사용은 사용자가 투명하다.소재 보기를 사용하면 조회를 변경하지 않고 조회 속도를 확실히 높일 수 있다.(단, 재료 보기의 물리적 데이터 영역을 주의해야 하며, 기초 표의 업데이트 처리가 느려져 원가와 장점을 천평 위에 두어야 한다.)
성능을 향상시키기 위해 다른 데이터 분산 방식을 지정하다
Azure Synapse Analytics에서 구성 데이터를 분산합니다.구성 방법에는 HASH 분산, Round Robin 분산, 복제 테이블(ALL 분산) 등 3가지가 있는데 임의의 분산 방식으로 60개 배포에 분산된다.
이 데이터의 분산은 기본적으로ALTER TABLE문장 등으로 변경할 수 없다.따라서 조회를 조정할 때 조회에 따라 HASH 분산표를 변경하려는 HASHKEY 등이 발생할 수 있다.이 경우 재료 뷰 역시 3가지 분산 방식 중 어느 하나를 사용할 수 있기 때문에 분산 방식이나 HASH 분산 방식이라도 서로 다른 HASH KEY표를 제작해 소재 뷰로 활용할 수 있다.이렇게 하면 조회의 가장 좋은 데이터 분산을 선택할 수 있다.
추천하는 소재 보기 확인
Azure Synapse Analytics는 질의에 권장되는 소재 뷰를 제공하는 기능을 제공합니다.
다음 SQL을 실행하면 객체에 대한 질의의 재료 뷰를 추천합니다.

EXPLAIN WITH_RECOMMENDATIONS <対象のクエリ>;

예는 이런 느낌이다.

EXPLAIN WITH_RECOMMENDATIONS
SELECT TOP 10
     L_ORDERKEY
    ,SUM(L_EXTENDEDPRICE*(1-L_DISCOUNT)) AS REVENUE
    ,O_ORDERDATE
    ,O_SHIPPRIORITY
FROM 
     CUSTOMER
    ,ORDERS
    ,LINEITEM
WHERE
    C_MKTSEGMENT = 'BUILDING'
    AND C_CUSTKEY = O_CUSTKEY
    AND L_ORDERKEY = O_ORDERKEY
    AND O_ORDERDATE < '1995-03-15' AND L_SHIPDATE > '1995-03-15'
GROUP BY L_ORDERKEY, O_ORDERDATE, O_SHIPPRIORITY
ORDER BY REVENUE DESC, O_ORDERDATE;

결과는 XML로 출력됩니다.
그 결과<materialized_view_candidates with_constants="False">와 <materialized_view_candidates with_constants="True">에는 추천CREATE MATERIALIZED VIEW이 기재되어 있었다.
FALSE는 상수가 없는 CREATE 문장(WHERE 문장의 글자 문자의 축소 조건 등을 배제한 상태)이고, True는 그와 반대되는 상수가 있는 CREATE 문장이다.
다른 한편, 이는 해당 SQL에만 최적화된 소재 뷰로 다른 질의에 적합하지 않을 수 있습니다.
예를 들어, 다음 SQL 예는 다음과 같습니다.

-- Query 1
SELECT A, SUM(B)
FROM T
GROUP BY A

-- Query 2
SELECT C, SUM(D)
FROM T
GROUP BY C

이상은 각각 집행EXPLAIN WITH_RECOMMENDATIONS한 후Query1, 2가 각각 최적화한 이하CREATE MATERIALIZED문장을 추천합니다.
※ 보기 편하도록 실제 출력에서 약간의 수정이 이루어졌습니다.

-- Query 1のEXPLAIN WITH_RECOMMENDATIONSの推奨事項
CREATE MATERIALIZED VIEW View1 AS
SELECT　A, SUM(B)
FROM T
GROUP BY A;

-- Query 2のEXPLAIN WITH_RECOMMENDATIONSの推奨事項
CREATE MATERIALIZED VIEW View2 AS
SELECT C, SUM(D)
FROM T
GROUP BY C;

만약 Query1과 Query2가 이렇게 두 개의 단독 최적화된 소재 보기를 만드는 것보다 더 실행할 수 있다면 하나의 소재 보기로 최적화하는 것이 가장 좋다.

CREATE MATERIALIZED VIEW View1_2 AS
SELECT A, C, SUM(B), SUM(D)
FROM T
GROUP BY A, C;

좀 어려울 수 있지만 EXPLAIN WITH_RECOMMENDATIONS의 추천사항뿐만 아니라 다른 조회와의 호환성도 고려해야 한다.