OLTP의 인덱싱된 뷰?

Question

저는 SQL Server 인덱싱된 뷰(또는 Oracle 구체화된 뷰)에 대해 잘 알고 있으며 이를 OLAP 애플리케이션에서 사용합니다.그들은 실행 계획을 빼앗아 기존 코드를 변경할 필요 없이 이를 인덱싱된 뷰에 다시 매핑할 수 있는 정말 멋진 기능을 가지고 있습니다.

즉.정말 비용이 많이 드는 조인인 SPROC가 있다고 가정해 보겠습니다.

[일부 열] 선택
FROM Table1 INNER JOIN Table2 [세부 사항]
내부 조인 테이블 3 [더 많은 결합] ...

유사한 결과 집합이 포함된 인덱싱된 뷰를 작성한 경우 쿼리 최적화 프로그램은 기본 테이블이 아닌 인덱싱된 뷰에 SPROC를 보낼 가능성이 높으며 성능이 크게 향상됩니다.

이제 인덱싱된 뷰를 사용하고 싶다고 가정해 보겠습니다. OLTP!? 내 말은 이 사이트와 같은 대부분의 OLTP는 상대적으로 읽기가 많다는 것입니다. 조인 비용이 많이 드는 경우 속도를 엄청나게 높이고 잠재적으로 잠금 경합을 줄일 수 있습니다(http://www.codinghorror.com/blog/archives/001166.html).더 좋은 점은 코드를 변경할 필요 없이 인덱싱된 뷰를 작성하기만 하면 된다는 것입니다.

하지만 이는 인덱싱된 뷰에 이러한 데이터의 복사본을 유지해야 하기 때문에 데이터베이스가 더 커진다는 의미이기도 합니다.

OLTP의 경합이나 속도 문제를 해결하기 위해 인덱싱된 뷰를 사용한 사람이 있습니까?왜 나는 이것을 사용하는 것을 본 적이 없습니까?

Answer 1

구체화된 뷰는 OLTP에 대한 보고에 유용할 수 있으며, 특히 결과를 얻기 위해 많은 수의 행이 집계되는 경우에 유용합니다.공간 요구 사항은 저장하는 데이터의 양에 따라 완전히 달라집니다.캐시라고 생각해보세요.

보고서에 필요한 데이터가 얼마나 최신이어야 하는지와 OLTP 성능에 어느 정도 영향을 미칠 수 있는지 사이에서 균형을 맞추는 것이 까다로운 문제입니다.다소 오래된 데이터가 괜찮다면 시스템 활동이 적은 시간 동안 보기 업데이트를 예약할 수 있습니다.

한 번은 최신 데이터가 필요하지 않고 필요했기 때문에 결국 일부 맞춤형 개발을 사용하게 되었습니다.기본 테이블에 대한 각 업데이트는 트랜잭션 테이블에 레코드를 쓰는 트리거를 실행했습니다.이 뷰는 캐시된 집계와 트랜잭션 테이블에 저장된 델타를 살펴보았습니다.시스템 리소스가 허용됨에 따라 트랜잭션이 집계 테이블에 델타 트랜잭션으로 적용되었습니다.이를 통해 두 번째 데이터, 보고에 대한 우수한 성능(발생한 유일한 집계는 최근 트랜잭션) 및 데이터베이스에 대한 부하가 상당히 적습니다(매번 대규모 집계를 다시 계산하지 않고 모든 쓰기 크기를 두 배로 늘림).

불행히도 유지 관리가 복잡했고 간단한 내장 도구를 사용하지 않았습니다.보고 데이터를 기다릴 수 있다면 내장된 구체화된 뷰를 사용하고 새로 고침을 연기하는 것이 가장 좋습니다.

Answer 2

우리는 구체화된 뷰를 사용하여 작업 속도를 높입니다.OLTP 시스템에 대한 보고서에 가장 자주 사용됩니다.대부분의 보고서는 데이터 웨어하우스에서 실행되지만 밤새 웨어하우스를 새로 고치기 때문에 지금까지는 OLTP 테이블에서 데이터를 가져와야 합니다.