연속 구체화된 뷰

이 문서에서는 연속 구체화된 뷰와 일반적인 사용 사례를 간략하게 설명합니다. 이 페이지를 읽기 전에 Bigtable 개요를 숙지해야 합니다.

Bigtable에서 연속 구체화된 뷰 는 지속적이고 완전 관리형 백그라운드 프로세스의 결과입니다. 이 프로세스는 사용자가 제공하는 SQL 쿼리를 사용하여 Bigtable이 소스 데이터가 변경될 때 증분식으로 업데이트하는 사전 계산된 테이블을 만들고 유지관리합니다. SQL 쿼리에는 기본 Bigtable 테이블에 대한 집계 및 변환이 포함될 수 있습니다.

연속 구체화된 뷰의 데이터에는 다음이 포함됩니다.

  • 소스 테이블의 데이터에서 파생된 집계 또는 변환된 값
  • 그룹화 키를 정의하는 비집계 값

연속 구체화된 뷰를 사용하면 수집하면서 데이터를 미리 집계할 수 있습니다. 또한 연속 구체화된 뷰에는 소스 테이블과는 다른 스키마가 있으며, 소스 테이블에 사용된 쿼리와 다른 조회 패턴을 사용해 쿼리에 최적화된 구조로 소스 테이블 데이터를 표시합니다.

Bigtable의 연속 구체화된 뷰의 주요 특성은 다음과 같습니다.

  • 유지보수 불필요: 연속 구체화된 뷰는 백그라운드에서 사전 계산됩니다. 업데이트 및 삭제를 포함한 소스 테이블의 데이터 변경사항은 사용자가 조치를 취하지 않아도 백그라운드에서 연속 구체화된 뷰로 자동으로 전파됩니다.
  • SQL 개발 패턴: 연속 구체화된 뷰는 SQL 함수, 필터, 집계를 포함한 Bigtable 쿼리의 GoogleSQL 을 기반으로 합니다.
  • 가비지 컬렉션과의 동기화: 연속 구체화된 뷰는 소스 테이블의 가비지 컬렉션 정책과 동기화된 상태를 유지하며, 테이블 데이터가 만료되거나 삭제될 때 자동으로 업데이트됩니다.
  • 읽기 및 쓰기 지연 시간은 영향을 받지 않음: 연속 구체화된 뷰 는 인스턴스 의 클러스터가 적절하게 프로비저닝되거나 자동 확장을 사용하는 경우 소스 테이블의 성능에 미치는 영향이 최소화됩니다.
  • 최종 일관성: 연속 구체화된 뷰는 백그라운드에서 계산됩니다. 연속 구체화된 뷰의 업데이트가 지연될 수 있지만 연속 구체화된 결과는 시간이 지남에 따라 항상 일관성을 유지합니다.

연속 구체화된 뷰를 정의하는 데 사용하는 row key, column qualifier, 열 값은 서비스 데이터로 취급됩니다. 따라서 민감한 정보가 포함된 row key, column qualifier 또는 열 값을 사용하여 연속 구체화된 뷰를 만들지 마세요. 서비스 데이터 처리 방법에 대한 자세한 내용은 Google Cloud 개인정보처리방침을 참조하세요.

Google Cloud CLI, 콘솔의 Bigtable Studio 쿼리 편집기 Google Cloud 또는 Java 및 Go용 Bigtable 클라이언트 라이브러리 Google Cloud 를 사용하여 연속 구체화된 뷰를 만들 수 있습니다.

다음을 사용하여 연속 구체화된 뷰에서 읽을 수 있습니다.

  • Bigtable Studio 쿼리 편집기
  • SQL 쿼리를 지원하는 Bigtable 클라이언트 라이브러리
  • Java 및 Go용 Bigtable 클라이언트 라이브러리를 사용하는 ReadRows API 호출

자세한 내용은 연속 구체화된 뷰에서 읽기를 참조하세요.

연속 구체화된 뷰를 사용하는 경우

연속 구체화된 뷰를 사용하면 SQL을 사용하여 Bigtable 데이터의 새로운 표현을 정의할 수 있습니다. 연속 구체화된 뷰가 생성되면 소스 테이블의 데이터를 SQL 쿼리로 정의된 형식으로 지속적으로 자동 재구성합니다. 그런 다음 테이블을 쿼리하고 데이터를 읽은 후 변환하거나 집계하는 대신 연속 구체화된 뷰를 쿼리할 수 있습니다.

연속 구체화된 뷰는 다음 사용 사례에서 쿼리 성능을 개선할 수 있습니다.

  • 데이터 사전 집계: 연속 구체화된 뷰를 사용하여 행 간에 수신 데이터를 집계할 수 있습니다. 이렇게 하면 대시보드 측정항목과 같은 요약되고 집계된 데이터를 빠르게 검색할 수 있습니다.
  • 람다 및 카파 아키텍처 자동화: 애플리케이션에 실시간 스트리밍 파이프라인 데이터와 이전 데이터가 포함된 일괄 파이프라인 데이터가 혼합되어 필요한 경우 연속 구체화된 뷰를 사용합니다. 이러한 뷰는 추가 스트림 처리 도구나 커스텀 ETL 작업 없이도 기본 데이터의 변경사항을 반영하도록 시간이 지남에 따라 업데이트되는 모든 데이터 소스의 뷰를 제공합니다.
  • 보조 액세스 패턴: 연속 구체화된 뷰는 데이터의 대체 표현을 만듭니다. 이 표현은 소스 테이블에 대한 쿼리에서 사용하는 것과 다른 조회 패턴을 사용하여 쿼리에 최적화할 수 있습니다. 따라서 연속 구체화된 뷰는 데이터에 비동기 보조 색인을 효과적으로 만드는 강력한 도구입니다. 이러한 패턴에 대한 자세한 내용은 비동기 보조 색인 만들기를 참조하세요.

연속 구체화된 뷰를 다른 유형의 Bigtable 뷰와 비교하려면 테이블 및 뷰를 참조하세요.

카운터를 사용하는 경우

데이터를 미리 집계하는 또 다른 방법은 분산 카운터 를 집계 셀을 사용하여 만드는 것입니다.

집계 셀에 대한 쓰기는 쓰기가 수행된 클러스터에서 즉시 읽을 수 있습니다. 연속 구체화된 뷰는 데이터가 작성된 후에 처리되며 결국 소스 테이블과 일관성을 유지합니다.

다음과 같은 경우 연속 구체화된 뷰 대신 카운터를 사용합니다.

  • 필터가 필요하지 않고 행 간에 있을 필요가 없는 집계
  • 쓰기가 수행된 클러스터에서 쓰기를 즉시 읽어야 하는 경우

다음을 수행하려는 경우 연속 구체화된 뷰를 사용합니다.

  • 집계에 대한 쿼리에 다른 키 생성
  • 집계에 반영된 기본 테이블의 변경사항 확인
  • 여러 행의 데이터 자동 결합

다음과 같은 사용 사례에서는 카운터와 연속 구체화된 뷰를 조합하여 사용합니다.

  • 집계 셀에서 최신 측정항목을 캡처하지만 해당 측정항목의 이전 롤업을 유지
  • 연속 구체화된 뷰에서 측정항목 결합

리소스 프로비저닝 및 성능

연속 구체화된 뷰의 지속적인 처리는 우선순위가 낮은 백그라운드 작업으로 발생합니다. 따라서 클러스터의 크기가 적절한 경우 애플리케이션 성능과 소스 테이블의 읽기 및 쓰기 지연 시간에 미치는 영향이 최소화됩니다.

연속 구체화된 뷰 의 데이터를 최신 상태로 유지하는 것이 좋으므로 연속 구체화된 뷰가 포함된 인스턴스의 클러스터 에 자동 확장을 사용 설정합니다. 자동 확장은 처리 오버헤드를 처리할 수 있는 충분한 노드를 자동으로 추가한 후 더 이상 필요하지 않으면 삭제합니다. 이렇게 하면 지속적으로 실행되는 SQL 쿼리를 실행하는 동안 충분한 컴퓨팅 용량을 사용할 수 있습니다. 자동 확장을 사용하면 연속 구체화된 뷰의 스토리지 요구사항을 처리할 수 있는 충분한 노드를 확보할 수도 있습니다.

연속 구체화된 뷰는 인스턴스당 테이블 1,000개 한도에 포함됩니다.

기존 테이블에 연속 구체화된 뷰 만들기

기존 테이블에 연속 구체화된 뷰를 만들면 Bigtable은 뷰를 기존 테이블 데이터로 채우는 일회성 프로세스를 시작합니다. 이 초기 채우기에는 테이블 크기와 쿼리 복잡성에 따라 시간이 걸립니다. 이 시간 동안 뷰를 쿼리할 수 없습니다. 이 초기 데이터 채우기는 클러스터 성능에 미치는 영향을 최소화하기 위해 우선순위가 낮은 백그라운드 작업으로 실행됩니다. 대규모 테이블의 경우 뷰 생성을 가속화하기 위해 클러스터에 노드를 일시적으로 추가할 수 있습니다.

다음 다이어그램은 연속 구체화된 뷰를 만드는 프로세스를 보여줍니다.

Bigtable에서 연속적인 구체화된 뷰를 만드는 프로세스입니다.
그림 1. Bigtable에서 연속 구체화된 뷰를 만드는 프로세스 (확대하려면 클릭)

예를 들어 소스 테이블에 advertiser_id#region#ad_id 패턴을 따르는 키가 있는 행과 광고 지출을 나타내는 숫자 데이터가 포함된 spend_usd column qualifier가 포함된 column family data가 있다고 가정해 보겠습니다.

row key data:spend_usd
adv1#us-east#ad1 100
adv1#us-west#ad2 150
adv2#us-east#ad3 200

다음 쿼리를 사용하여 이 테이블의 연속 구체화된 뷰를 정의하면 175노드 클러스터에서 1TB의 초기 채우기가 약 3시간 만에 완료됩니다.

SELECT
          SPLIT(_key, "#")[SAFE_OFFSET(0)] AS advertiser_id,
          count(*) AS count,
          sum(cast(cast(data['spend_usd'] as string) as int64)) as sum_spend
        FROM `$0`
        GROUP BY advertiser_id

Bigtable은 선형으로 확장되므로 데이터의 모양이 비슷한 경우 175노드 클러스터는 약 6시간 만에 2TB의 데이터를 처리하고 약 30시간 만에 10TB를 처리합니다. 초기 채우기에 필요한 시간을 줄이려면 클러스터에 노드를 일시적으로 추가하거나 자동 확장을 사용하는 경우 최대 노드 수를 일시적으로 늘릴 수 있습니다.

스토리지

Bigtable은 각 연속 구체화된 뷰에 대해 다음을 저장합니다.

  • 연속 구체화된 뷰의 데이터
  • 중간 스토리지

Bigtable 테이블과 마찬가지로 연속 구체화된 뷰는 연속 구체화된 뷰가 포함된 인스턴스의 모든 클러스터에 존재합니다. 인스턴스의 클러스터에는 소스 테이블과 테이블을 기반으로 하는 연속 구체화된 뷰를 저장할 수 있는 충분한 노드가 있어야 합니다. 자동 확장을 사용하면 스토리지 요구사항이 변경될 때 클러스터의 크기를 확장하거나 축소할 수 있습니다.

연속 구체화된 뷰의 스토리지는 소스 테이블과 다르지만 연속 구체화된 뷰는 소스 테이블과 동일한 인스턴스에서 만들어야 합니다.

연속 구체화된 뷰 스토리지

연속 구체화된 뷰에는 연속 구체화된 뷰가 기반으로 하는 SQL 쿼리의 결과로 생성된 데이터가 포함됩니다. 즉, SQL 쿼리의 집계 절로 정의된 집계 값과 그룹화 키를 정의하는 비집계 값이 포함됩니다.

중간 스토리지

연속 구체화된 뷰와 소스 테이블의 동기화를 지원하기 위해 Bigtable은 중간 스토리지 를 사용하여 연속 구체화된 뷰를 증분식으로 업데이트하는 데 필요한 데이터의 사본을 저장합니다.

중간 스토리지의 데이터 양은 연속 구체화된 뷰를 정의하는 SQL 쿼리의 결과를 생성하기 위해 소스 테이블에서 스캔되는 데이터 양과 거의 동일합니다. 예를 들어 쿼리가 전체 테이블에서 데이터를 집계하는 경우 Bigtable은 중간 스토리지에 전체 테이블과 동일한 데이터를 보관합니다. 특정 row key 범위 또는 열의 쿼리를 기반으로 하는 연속 구체화된 뷰는 중간 스토리지에 해당 행 또는 열만 보관합니다.

중간 스토리지는 연속 구체화된 뷰의 수명 동안 지속되어 뷰에 대한 증분 업데이트를 효율적으로 지원하고 소스 테이블에서 연속 구체화된 뷰로 삭제를 전파합니다. 중간 스토리지의 데이터는 읽을 수 없습니다. 중간 스토리지 사용에 대한 통계를 보려면 연속 구체화된 뷰 측정항목을 참조하세요.

복제

복제를 사용하는 인스턴스에서 연속 구체화된 뷰는 테이블과 동일한 방식으로 복제되지 않습니다. 대신 인스턴스의 각 클러스터는 소스 테이블의 자체 사본을 사용하여 연속 구체화된 뷰를 독립적으로 처리합니다. 예를 들어 클러스터 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 측정항목의 분석에 포함되어 영향을 파악하는 데 도움이 됩니다. 초당 요청 수, 지연 시간, 처리량에 대한 Bigtable 측정항목은 Data API의 ReadRows 메서드를 사용하여 연속 구체화된 뷰를 읽을 때 생성됩니다. 자세한 내용은 측정항목을 참조하세요.

Cloud Logging을 시작하려면 쿼리 및 로그 보기 개요를 참조하세요.

제한사항

  • 테이블당 최대 5개의 연속 구체화된 뷰를 만들 수 있습니다. 필요한 경우 Cloud Customer Care에 문의하여 이 한도를 늘릴 수 있습니다.
  • 지정된 _key 없이 뷰를 만들 때 소스 테이블에서 선택한 열은 NULL이 아니어야 합니다. 자세한 내용은 Row key 를 참조하세요. GROUP BY 절로 정의됨.
  • 연속 구체화된 뷰를 정의하는 SQL 쿼리는 수정할 수 없습니다. 연속 구체화된 뷰를 삭제하고 변경사항이 포함된 새 뷰를 만들어야 합니다.
  • 다른 연속 구체화된 뷰 또는 논리적 뷰의 연속 구체화된 뷰는 만들 수 없습니다.
  • 연속 구체화된 뷰의 가비지 컬렉션 정책은 구성할 수 없습니다. 모든 데이터 보관은 소스 테이블의 가비지 컬렉션 정책에 따라 관리되며 소스의 가비지 컬렉션은 연속 구체화된 뷰에 자동으로 반영됩니다.

다음 단계