연속 구체화된 뷰
이 문서에서는 연속 구체화된 뷰와 일반적인 사용 사례를 간략하게 설명합니다. 이 페이지를 읽기 전에 Bigtable 개요를 숙지해야 합니다.
Bigtable에서 구체화된 연속 뷰는 구체화된 연속 뷰를 점진적으로 업데이트하는 지속적으로 실행되는 SQL 쿼리의 완전 관리형 미리 계산된 결과입니다. SQL 쿼리에는 기본 Bigtable 테이블에 대한 집계 및 변환이 포함될 수 있습니다. 연속 구체화된 뷰를 사용하면 성능과 효율성을 높일 수 있습니다.
연속 구체화된 뷰의 데이터에는 다음이 포함됩니다.
- 소스 테이블의 데이터에서 파생된 집계 또는 변환된 값
- 그룹화 키를 정의하는 집계되지 않은 값
연속 구체화된 뷰를 사용하면 데이터를 수집할 때 미리 집계할 수 있습니다. 또한 연속 구체화된 뷰는 소스 테이블과 스키마가 다르며, 소스 테이블에서 사용되는 쿼리와 다른 조회 패턴이 있는 쿼리에 최적화된 구조로 소스 테이블 데이터를 표시합니다.
Bigtable의 연속 구체화된 뷰의 주요 특징은 다음과 같습니다.
- 유지보수 불필요: 연속 구체화된 뷰는 백그라운드에서 미리 계산됩니다. 업데이트 및 삭제를 비롯한 소스 테이블의 데이터 변경사항은 사용자 작업 없이 백그라운드에서 연속 구체화된 뷰로 자동으로 전파됩니다.
- SQL 개발 패턴: 연속 구체화된 뷰는 SQL 함수, 필터, 집계를 포함한 Bigtable 쿼리용 GoogleSQL을 기반으로 합니다.
- 가비지 컬렉션과의 동기화: 연속 구체화된 뷰는 소스 테이블의 가비지 컬렉션 정책과 동기화되어 테이블 데이터가 만료되거나 삭제될 때 자동으로 업데이트됩니다.
- 읽기 및 쓰기 지연 시간에 영향이 없음: 인스턴스의 클러스터가 적절하게 프로비저닝되거나 자동 확장을 사용하는 경우 연속 구체화된 뷰는 소스 테이블의 성능에 미치는 영향이 최소화됩니다.
- 결과적 일관성: 연속 구체화된 뷰는 백그라운드에서 계산됩니다. 연속 구체화된 뷰의 업데이트가 지연될 수 있지만 연속 구체화된 결과는 시간이 지나도 항상 일관됩니다.
연속 구체화된 뷰를 정의하는 데 사용하는 행 키, 열 한정자, 열 값은 서비스 데이터로 취급됩니다. 따라서 민감한 정보가 포함된 row key, column qualifier 또는 column 값을 사용하여 연속 구체화된 뷰를 만들지 마세요. 서비스 데이터 처리 방법에 대한 자세한 내용은 Google Cloud 개인정보처리방침을 참고하세요.
Google Cloud CLI, Google Cloud 콘솔의 Bigtable Studio 쿼리 편집기 또는 Java 및 Go용 Bigtable 클라이언트 라이브러리를 사용하여 연속 구체화된 뷰를 만들 수 있습니다.
다음을 사용하여 연속 구체화된 뷰에서 읽을 수 있습니다.
- Bigtable Studio 쿼리 편집기
- SQL 쿼리를 지원하는 Bigtable 클라이언트 라이브러리
- Java 및 Go용 Bigtable 클라이언트 라이브러리를 사용한
ReadRows
API 호출
자세한 내용은 연속 구체화된 뷰에서 읽기를 참고하세요.
연속 구체화된 뷰를 사용하는 경우
구체화된 연속 뷰를 사용하면 SQL을 사용하여 Bigtable 데이터의 새로운 표현을 정의할 수 있습니다. 연속 구체화된 뷰가 생성되면 소스 테이블의 데이터가 SQL 쿼리로 정의된 형식으로 지속적으로 자동 재구성됩니다. 그런 다음 테이블을 쿼리하고 데이터를 읽은 후 변환하거나 집계하는 대신 연속 구체화된 뷰를 쿼리할 수 있습니다.
연속 구체화된 뷰는 다음 사용 사례에서 쿼리 성능을 향상할 수 있습니다.
- 데이터 사전 집계: 연속 구체화된 뷰를 사용하여 행 전체에서 수신 데이터를 집계할 수 있습니다. 이를 통해 대시보드의 측정항목과 같은 요약되고 집계된 데이터를 빠르게 가져올 수 있습니다.
- 람다 및 카파 아키텍처 자동화: 애플리케이션에 실시간 스트리밍 파이프라인 데이터와 과거 데이터가 포함된 배치 파이프라인 데이터가 혼합되어야 하는 경우 연속 구체화된 뷰를 사용하세요. 이러한 뷰는 추가 스트림 처리 도구나 맞춤 ETL 작업 없이도 기본 데이터의 변경사항을 반영하기 위해 시간이 지남에 따라 업데이트되는 모든 데이터 소스의 뷰를 제공합니다.
- 보조 액세스 패턴: 연속 구체화된 뷰는 데이터의 대체 표현을 만듭니다. 이 표현은 소스 테이블에 대한 쿼리에서 사용하는 것과 다른 조회 패턴이 있는 쿼리에 맞게 최적화할 수 있습니다. 이러한 패턴에 대한 자세한 내용은 비동기 보조 색인 만들기를 참고하세요.
연속 구체화된 뷰를 다른 유형의 Bigtable 뷰와 비교하려면 테이블 및 뷰를 참고하세요.
카운터를 사용해야 하는 경우
집계 셀을 사용하여 분산 카운터를 만들어 데이터를 사전 집계할 수도 있습니다.
집계 셀에 대한 쓰기는 쓰기가 수행된 클러스터에서 즉시 읽을 수 있습니다. 연속 구체화된 뷰는 데이터가 기록된 후에 처리되며 결국 소스 테이블과 일치하게 됩니다.
다음과 같은 경우에는 연속 구체화된 뷰 대신 카운터를 사용하세요.
- 필터가 필요하지 않고 행 간에 있을 필요가 없는 집계
- 쓰기가 수행된 클러스터에서 쓰기를 즉시 읽어야 하는 경우
다음과 같은 경우 연속 구체화된 뷰를 사용하세요.
- 집계에 대한 쿼리에 다른 키 생성
- 집계에 반영된 기본 표의 변경사항 확인
- 여러 행의 데이터를 자동으로 결합하기
다음과 같은 사용 사례에서는 카운터와 연속 구체화된 뷰를 함께 사용하세요.
- 집계 셀에서 최신 측정항목을 캡처하되 해당 측정항목의 이전 롤업은 유지합니다.
- 연속 구체화된 뷰에서 측정항목 결합
리소스 프로비저닝 및 성능
연속 구체화된 뷰의 지속적인 처리는 우선순위가 낮은 백그라운드 작업으로 실행됩니다. 따라서 클러스터의 크기가 적절한 경우 애플리케이션 성능과 소스 테이블의 읽기 및 쓰기 지연 시간에 미치는 영향이 최소화됩니다.
지속적 구체화된 뷰의 데이터가 최신 상태로 유지되도록 하려면 지속적 구체화된 뷰가 포함된 인스턴스의 클러스터에 자동 확장을 사용 설정하는 것이 좋습니다. 자동 확장 기능은 처리 오버헤드를 처리할 수 있을 만큼 충분한 노드를 자동으로 추가한 다음 더 이상 필요하지 않으면 삭제합니다. 이렇게 하면 지속적으로 실행되는 SQL 쿼리를 실행하는 동안 충분한 컴퓨팅 용량을 사용할 수 있습니다. 또한 자동 확장을 통해 연속 구체화된 뷰의 스토리지 요구사항을 처리할 수 있을 만큼 충분한 노드를 확보할 수 있습니다.
연속 구체화된 뷰는 인스턴스당 테이블 1,000개 한도에 포함됩니다.
스토리지
Bigtable은 각 연속 구체화된 뷰에 대해 다음을 저장합니다.
- 연속 구체화된 뷰의 데이터
- 중간 스토리지
모든 Bigtable 테이블과 마찬가지로 연속 구체화된 뷰는 이를 포함하는 인스턴스의 모든 클러스터에 존재합니다. 인스턴스의 클러스터에 소스 테이블과 테이블을 기반으로 하는 연속 구체화된 뷰를 저장할 수 있는 충분한 노드가 있어야 합니다. 자동 확장을 사용하면 스토리지 요구사항이 변경될 때 클러스터의 크기를 확장하거나 축소할 수 있습니다.
연속 구체화된 뷰의 스토리지는 소스 테이블과 다르지만 연속 구체화된 뷰는 소스 테이블과 동일한 인스턴스에 만들어야 합니다.
연속 구체화된 뷰 스토리지
구체화된 연속 뷰에는 구체화된 연속 뷰가 기반으로 하는 SQL 쿼리의 결과 데이터가 포함됩니다. 즉, SQL 쿼리의 집계 절로 정의된 집계 값과 그룹화 키를 정의하는 집계되지 않은 값이 포함됩니다.
중간 스토리지
연속 구체화된 뷰와 소스 테이블의 동기화를 지원하기 위해 Bigtable은 중간 스토리지를 사용하여 연속 구체화된 뷰를 증분 업데이트하는 데 필요한 데이터의 사본을 저장합니다.
중간 저장소의 데이터 양은 연속 구체화된 뷰를 정의하는 SQL 쿼리의 결과를 생성하기 위해 소스 테이블에서 스캔되는 데이터 양과 거의 같습니다. 예를 들어 쿼리가 전체 테이블의 데이터를 집계하는 경우 Bigtable은 중간 스토리지에 전체 테이블에 해당하는 데이터를 보관합니다. 특정 행 키 범위 또는 열의 쿼리를 기반으로 하는 연속 구체화된 뷰는 중간 스토리지에 해당 행 또는 열만 유지합니다.
중간 스토리지는 뷰의 증분 업데이트를 효율적으로 지원하고 소스 테이블에서 연속 구체화된 뷰로 삭제를 전파하기 위해 연속 구체화된 뷰의 수명 동안 유지됩니다. 중간 스토리지의 데이터를 읽을 수 없습니다. 중간 스토리지 사용량에 대한 통계는 연속 구체화된 뷰 측정항목을 참고하세요.
복제
복제를 사용하는 인스턴스에서는 연속 구체화된 뷰가 테이블과 동일한 방식으로 복제되지 않습니다. 대신 인스턴스의 각 클러스터는 소스 테이블의 자체 복사본을 사용하여 연속 구체화된 뷰를 독립적으로 처리합니다. 예를 들어 클러스터 A의 소스 테이블에 기록된 데이터는 클러스터 B의 테이블로 복제된 후 클러스터 B의 연속 구체화된 뷰로 복제됩니다.
비용
지속적 구체화된 뷰를 사용하는 데 리소스당 비용은 없습니다. 하지만 연속 구체화된 뷰를 만들고 동기화하려면 처리 및 저장소가 필요하며 표준 요금이 청구됩니다. 연속 구체화된 뷰를 만들면 다음 항목이 증가합니다.
- 스토리지 - 연속 구체화된 뷰에 데이터를 저장하는 비용과 중간 스토리지 비용이 청구됩니다. 자세한 내용은 스토리지를 참고하세요.
- 컴퓨팅 - 소스 테이블의 지속적인 동기화와 연속 구체화된 뷰에는 CPU 처리가 필요하며 추가 백그라운드 작업을 처리하기 위해 클러스터에 노드가 더 필요할 수 있습니다.
동시에 반복되는 계산과 효율성이 낮은 다른 쿼리를 실행하기 위해 더 이상 데이터의 범위 스캔을 수행하지 않는 경우와 같이 소스 테이블의 일부 처리가 감소할 수 있습니다. 또한 Dataflow 또는 Spark와 같은 파이프라인 작업을 실행하여 소스 데이터를 집계하고 Bigtable에 다시 쓸 필요가 없을 수도 있습니다.
가격에 대한 자세한 내용은 Bigtable 가격 책정을 참고하세요. 연속 구체화된 뷰 사용량을 모니터링하는 데 도움이 되는 측정항목은 측정항목을 참고하세요.
측정항목
연속 구체화된 뷰는 연속 구체화된 뷰를 모니터링하는 데 사용할 수 있는 여러 주요 측정항목을 Cloud Logging에 보고합니다.
측정항목 | 설명 |
---|---|
materialized_view/max_delay |
연속 구체화된 뷰의 처리 지연 시간 상한 |
materialized_view/storage |
연속 구체화된 뷰 스토리지에 사용된 데이터 양(바이트) |
materialized_view/intermediate_storage |
지속적으로 구체화된 뷰의 중간 처리에 사용된 데이터 양(바이트) |
table/materialized_view_intermediate_storage |
이 테이블에 정의된 연속 구체화된 뷰의 중간 처리에서 사용되는 데이터 양 |
materialized_view/user_errors |
연속 구체화된 뷰의 사용자 데이터에서 발생한 오류 수입니다. 사용자 오류로 인해 데이터가 뷰로 전파되지 않습니다. |
materialized_view/system_errors |
연속 구체화된 뷰에 대한 시스템의 오류 수 |
또한 테이블 ID 대신 연속 구체화된 뷰 ID를 사용하여 연속 구체화된 뷰를 모니터링하는 데 많은 Bigtable 테이블 측정항목을 사용할 수 있습니다. 특히 연속 구체화된 뷰는 CPU 측정항목의 분류에 포함되어 있으므로 영향을 파악하는 데 도움이 됩니다. Data API의 ReadRows
메서드를 사용하여 연속 구체화된 뷰를 읽으면 초당 요청 수, 지연 시간, 처리량에 관한 Bigtable 측정항목이 생성됩니다. 자세한 내용은 측정항목을 참고하세요.
Cloud Logging을 시작하려면 로그 쿼리 및 보기 개요를 참고하세요.
제한사항
- 테이블당 연속 구체화된 뷰를 하나만 만들 수 있습니다.
- 지정된
_key
없이 뷰를 만드는 경우 소스 테이블에서 선택된 열은NULL
이 아니어야 합니다. 자세한 내용은GROUP BY
절로 정의된 행 키를 참고하세요. - 연속 구체화된 뷰를 정의하는 SQL 쿼리는 수정할 수 없습니다. 지속적 구체화된 뷰를 삭제하고 변경사항이 적용된 새 뷰를 만들어야 합니다.
- 다른 연속 구체화된 뷰 또는 논리 뷰의 연속 구체화된 뷰는 만들 수 없습니다.
- 연속 구체화된 뷰의 가비지 컬렉션 정책은 구성할 수 없습니다. 모든 데이터 보관은 소스 테이블의 가비지 컬렉션 정책에 따라 관리되며 소스의 가비지 컬렉션은 연속 구체화된 뷰에 자동으로 반영됩니다.