데이터가 필요한 쿼리 작업에 대해 이상적으로 포맷되지 않은 경우 하나 이상의 데이터 저장소에 있는 데이터에 대한 미리 채워진 뷰를 생성합니다. 이렇게 하면 효율적인 쿼리와 데이터 추출을 지원하고 애플리케이션 성능을 개선하는 데 도움을 줄 수 있습니다.
컨텍스트 및 문제점
데이터를 저장할 때 개발자와 데이터 관리자의 우선 순위는 데이터를 읽는 방식과는 달리 데이터를 저장하는 방법에 중점을 두는 경우가 많습니다. 선택한 스토리지 형식은 일반적으로 데이터 형식, 데이터 크기 및 데이터 무결성을 관리하기 위한 요구 사항 및 사용 중인 저장소 종류와 밀접한 관련이 있습니다. 예를 들어 NoSQL 문서 저장소를 사용할 때 데이터는 해당 엔터티의 모든 정보를 포함하는 일련의 집합체로 표현되곤 합니다.
그러나 쿼리에 부정적인 영향을 미칠 수 있습니다. 쿼리에 주문 세부 정보가 없는 여러 고객에 대한 주문 요약과 같은 일부 엔터티의 데이터 하위 집합만 필요한 경우 필요한 정보를 얻으려면 관련 엔터티에 대한 모든 데이터를 추출해야 합니다.
솔루션
효율적인 쿼리를 지원하기 위해 일반적인 솔루션은 필요한 결과 집합에 적합한 형식으로 데이터를 구체화하는 뷰를 미리 생성하는 것입니다. 구체화된 뷰 패턴은 원본 데이터가 쿼리에 적합한 형식이 아니거나, 적절한 쿼리를 생성하기 어렵거나, 데이터 또는 데이터 저장소의 특성으로 인해 쿼리 성능이 저하되는 환경에서 미리 채워진 데이터 뷰를 생성하는 방법을 설명합니다.
쿼리에 필요한 데이터만 포함하는 이러한 구체화된 뷰를 통해 애플리케이션은 필요한 정보를 신속하게 얻을 수 있습니다. 구체화된 뷰에는 테이블을 조인하거나 데이터 엔터티를 결합하는 것 외에도 계산 열 또는 데이터 항목의 현재 값, 데이터 항목에 대한 값을 결합하거나 변환을 실행한 결과 및 쿼리의 일부로 지정된 값이 포함될 수 있습니다. 구체화된 뷰는 단일 쿼리에만 최적화할 수도 있습니다.
핵심은 구체화된 뷰와 포함된 데이터는 원본 데이터 저장소에서 완전히 다시 작성할 수 있으므로 완전히 삭제할 수 있다는 것입니다. 구체화된 뷰는 애플리케이션을 통해 직접 업데이트되지 않으므로 전문화된 캐시에 해당됩니다.
뷰의 원본 데이터가 변경되면 새 정보를 포함하도록 뷰를 업데이트해야 합니다. 이 작업은 자동으로 수행되도록 예약하거나 시스템에서 원래 데이터의 변경 내용을 감지할 때 예약할 수 있습니다. 경우에 따라 뷰를 수동으로 다시 생성해야 할 수 있습니다. 그림에서는 구체화된 뷰 패턴을 사용하는 방법의 예를 보여 줍니다.
문제 및 고려 사항
이 패턴을 구현할 방법을 결정할 때 다음 사항을 고려하세요.
보기가 업데이트되는 방법 및 시기 원본 데이터가 급속하게 변경되는 경우, 과도한 오버헤드를 초래하더라도 원본 데이터의 변경을 표시하는 이벤트에 따라 구체화된 뷰를 다시 생성하는 것이 좋습니다. 또는 예약된 작업, 외부 트리거 또는 수동 작업을 사용하여 보기를 다시 생성하는 것이 좋습니다.
데이터를 수정한 이벤트만 보관된 저장소를 유지하는 이벤트 소싱 패턴을 사용하는 일부 시스템에는 구체화된 뷰가 필요합니다. 현재 상태를 확인하기 위해 모든 이벤트를 검사하여 뷰를 미리 채우면 이벤트 저장소에서 정보를 얻을 수 있습니다. 이벤트 소싱을 사용하지 않는 경우, 구체화된 뷰가 도움이 되는지 여부를 고려할 필요가 있습니다. 구체화된 뷰는 하나 또는 적은 수의 쿼리에 특정하게 맞춤화되는 경향이 있습니다. 많은 쿼리를 사용하는 경우, 구체화된 뷰는 수용하기 어려운 수준의 스토리지 용량 요구 사항과 스토리지 비용을 초래할 수 있습니다.
뷰를 생성하거나 예약을 통해 뷰를 업데이트할 때는 데이터 일관성에 미치는 영향을 고려해야 합니다. 뷰를 생성하는 시점에 원본 데이터를 변경하고 있는 경우, 뷰의 데이터 사본이 원본 데이터와 완벽하게 일치하지 않을 수 있습니다.
뷰를 어디에 저장할지 고려해야 하는데, 뷰는 원래 데이터와 동일한 저장소 또는 파티션에 있을 필요가 없습니다. 결합된 몇 가지 다른 파티션의 하위 집합일 수 있습니다.
손실된 경우 뷰를 다시 작성할 수 있습니다. 따라서 보기가 일시적이며 데이터의 현재 상태를 반영하여 쿼리 성능을 향상시키는 데만 사용되는 경우 또는 확장성을 향상시키기 위해 캐시 또는 덜 신뢰할 수 있는 위치에 저장할 수 있습니다.
구체화된 뷰를 정의할 때 기존 데이터 항목의 계산 또는 변환, 쿼리에 전달된 값 또는 적절한 경우 이러한 값의 조합에 따라 데이터 항목 또는 열을 추가하여 값을 최대화합니다.
스토리지 메커니즘이 지원하는 경우 구체화된 뷰를 인덱싱하여 성능을 더 높이는 것이 좋습니다. 대부분의 관계형 데이터베이스는 Apache Hadoop 기반의 빅데이터 솔루션처럼 뷰의 인덱싱을 지원합니다.
이 패턴을 사용해야 하는 경우
이 패턴은 다음과 같은 경우에 유용합니다.
- 직접 쿼리하기 어려운 데이터에 대한 구체화된 뷰를 생성하거나 쿼리가 너무 복잡해서 정규화, 반구조화, 비구조화 방식으로 저장된 데이터를 추출해야 하는 경우
- 쿼리 성능을 크게 향상시키거나 UI, 보고 또는 표시에 대한 원본 뷰 또는 데이터 전송 개체로 직접 작동할 수 있는 임시 뷰를 만듭니다.
- 데이터 저장소에 대한 연결을 항상 사용할 수 없는 경우에 따라 연결되거나 연결이 끊긴 시나리오를 지원합니다. 이 경우 뷰를 로컬로 캐시할 수 있습니다.
- 원본 데이터 형식에 대한 지식이 필요 없는 방식으로 쿼리를 단순화하고 실험 데이터를 표시하는 경우. 예를 들어 하나 이상의 데이터베이스에 다른 테이블을 조인하거나 NoSQL 저장소에서 하나 이상의 작업을기본 수행한 다음 최종 용도에 맞게 데이터 서식을 지정합니다.
- 보안 또는 개인 정보 보호를 위해 일반적으로 액세스할 수 없거나 수정할 수 있거나 사용자에게 완전히 노출되어서는 안 되는 원본 데이터의 특정 하위 집합에 대한 액세스를 제공합니다.
- 개별 기능을 활용하기 위해 다양한 데이터 저장소를 브리징합니다. 예를 들어 참조 데이터 저장소로 쓰기에 효율적인 클라우드 저장소와 구체화된 뷰를 보유하는 좋은 쿼리 및 읽기 성능을 제공하는 관계형 데이터베이스를 사용합니다.
- 마이크로 서비스를 사용하는 경우 데이터 스토리지를 포함하여 느슨하게 결합된 상태로 유지하는 것이 좋습니다. 따라서 구체화된 뷰는 서비스의 데이터를 통합하는 데 도움이 될 수 있습니다. 구체화된 뷰가 마이크로 서비스 아키텍처 또는 특정 시나리오에서 적절하지 않은 경우 DDD(도메인 기반 디자인)에 맞게 잘 정의된 경계를 사용하고 요청 시 해당 데이터를 집계하는 것이 좋습니다.
다음의 상황에는 이 패턴이 유용하지 않습니다.
- 원본 데이터가 단순하고 쿼리하기 용이한 경우
- 원본 데이터는 매우 빠르게 변경되거나 보기를 사용하지 않고 액세스할 수 있습니다. 이런 경우에는 뷰 만들기와 관련된 처리 오버헤드를 방지해야 합니다.
- 일관성은 높은 우선 순위입니다. 뷰는 원본 데이터와 완벽하게 일치하지 않을 수 있습니다.
워크로드 디자인
설계자는 워크로드 디자인에서 구체화된 뷰 패턴을 사용하여 Azure Well-Architected Framework 핵심 요소에서 다루는 목표와 원칙을 해결하는 방법을 평가해야 합니다. 예시:
| 핵심 요소 | 이 패턴이 핵심 목표를 지원하는 방법 |
|---|---|
| 성능 효율성은 크기 조정, 데이터, 코드의 최적화를 통해 워크로드가 수요를 효율적으로 충족하는 데 도움이 됩니다. | 구체화된 뷰는 데이터베이스 엔진 또는 클라이언트가 모든 요청에 대해 다시 계산할 필요 없이 복잡한 계산 또는 쿼리의 결과를 저장합니다. 이 디자인은 전체 리소스 소비를 줄입니다. - PE:08 데이터 성능 |
디자인 결정과 마찬가지로 이 패턴으로 도입될 수 있는 다른 핵심 요소의 목표에 대한 절충을 고려합니다.
예시
다음 그림은 구체화된 뷰 패턴을 사용해 매출액의 요약을 생성하는 예를 보여 줍니다. Azure Storage 계정의 별도 파티션에 있는 Order, OrderItem 및 Customer 테이블의 데이터는 결합되어 각 항목을 구매한 고객 수와 함께 Electronics 범주의 각 제품에 대한 총 판매액이 포함된 보기를 생성합니다.
이 구체화된 뷰를 만들려면 복잡한 쿼리가 필요합니다. 그러나 쿼리 결과를 구체화된 뷰로 노출하면 사용자는 쉽게 결과를 가져오고 직접 사용하거나 다른 쿼리에 통합할 수 있습니다. 보기는 보고 시스템 또는 대시보드에서 사용될 가능성이 높으며 매주와 같은 예약된 기준으로 업데이트할 수 있습니다.
이 예제는 Azure Table 스토리지를 사용하지만 많은 관계형 데이터베이스 관리 시스템도 구체화된 뷰를 위한 기본 지원을 제공합니다.
다음 단계
- Data Consistency Primer(데이터 일관성 입문서). 구체화된 뷰의 요약 정보는 기본 데이터 값을 반영하도록 기본. 데이터 값이 변경되면 요약 데이터는 실시간으로 업데이트할 수 없으므로 그 대신 최종 일관성 접근을 채택해야 합니다. 분산된 데이터의 일관성 유지 관리와 관련된 문제를 요약하고 다양한 일관성 모델의 장점과 단점을 설명합니다.
관련 참고 자료
이 패턴을 구현할 때 다음 패턴도 관련이 있을 수 있습니다.
- CQRS(명령 및 쿼리 책임 분리). 기본 데이터 값이 변경될 때 발생하는 이벤트에 응답하여 구체화된 뷰에서 정보를 업데이트하는 데 사용합니다.
- 이벤트 소싱 패턴 CQRS 패턴와 함께 구체화된 뷰의 정보를 유지하는 데 사용합니다. 구체화된 뷰가 참조하는 원본 데이터 값이 변경되면 시스템은 이런 변경 사항을 설명하는 이벤트를 발생시키고 이벤트를 이벤트 저장소에 저장합니다.
- 인덱스 테이블 패턴입니다. 보통 구체화된 뷰의 데이터는 기본 키로 구성되지만, 쿼리는 다른 필드의 데이터를 검사해 구체화된 뷰에서 정보를 검색할 필요가 있습니다. 네이티브 보조 인덱스를 지원하지 않는 데이터 저장소에 대한 데이터 집합을 통해 보조 인덱스를 만드는 데 사용합니다.