연속 구체화된 뷰

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

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

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

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

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

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

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

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

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

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

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

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

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

연속적인 구체화된 뷰는 다음 사용 사례에서 쿼리 성능을 향상시킬 수 있습니다.

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

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

카운터를 사용해야 하는 경우

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

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

다음과 같은 경우에는 연속 구체화된 뷰 대신 카운터를 사용하세요.

  • 필터가 필요하지 않고 행 전체에 적용될 필요가 없는 집계에 사용합니다.
  • 쓰기 작업이 수행된 클러스터에서 쓰기 작업을 즉시 읽어야 하는 경우

다음을 수행하려면 연속 구체화된 뷰를 사용하세요.

  • 집계에 대한 쿼리에 다른 키를 생성합니다.
  • 기본 테이블의 변경사항이 집계에 반영되는 것을 확인합니다.
  • 여러 행의 데이터를 자동으로 결합합니다.

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

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

리소스 프로비저닝 및 성능

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

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

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

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

기존 테이블에 연속적인 구체화된 뷰를 만들면 Bigtable은 기존 테이블 데이터로 뷰를 채우는 일회성 프로세스를 시작합니다. 이 프로세스를 초기 채우기라고 합니다. 초기 채우기에 필요한 시간은 테이블 크기와 쿼리 복잡성에 따라 달라집니다. 기본적으로 초기 채우기 중에는 뷰를 쿼리할 수 없습니다. 하지만 애플리케이션 개발 중과 같이 사용 사례에서 불완전한 데이터를 허용할 수 있는 경우 allow_incomplete_view 쿼리 힌트를 사용하여 채우기가 완료되기 전에 뷰를 쿼리할 수 있습니다. 이 시간 동안 뷰가 집계를 수행하면 반환된 집계에 데이터의 일부만 반영될 수 있습니다. 자세한 내용은 초기 채우기 중 데이터 읽기를 참조하세요.

이 초기 채우기는 클러스터 성능에 미치는 영향을 최소화하기 위해 우선순위가 낮은 백그라운드 작업으로 실행됩니다. 큰 테이블의 경우 클러스터에 노드를 일시적으로 추가하여 뷰 생성을 가속화할 수 있습니다.

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

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를 처리합니다. 초기 채우기에 필요한 시간을 줄이려면 일시적으로 클러스터에 노드를 더 추가하거나 자동 확장을 사용하는 경우 일시적으로 최대 노드 수를 늘릴 수 있습니다.

비확정적 SQL 함수

기본적으로 연속 구체화된 뷰는 인스턴스의 모든 클러스터에서 일관된 결과를 보장하기 위해 결정론적 함수만 지원합니다. 하지만 CLUSTER_ATTRIBUTE()와 같은 비결정론적 함수를 사용하도록 선택하여 데이터를 처리하는 클러스터별로 데이터를 필터링할 수 있습니다. 자세한 내용은 비결정론적 쿼리를 참조하세요.

이러한 함수를 사용하려면 연속 구체화된 뷰를 만들 때 잠재적인 의미 차이를 확인해야 합니다. 자세한 내용은 연속 구체화된 뷰 만들기를 참조하세요.

스토리지

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 측정항목의 분석에 포함되므로 영향을 파악하는 데 도움이 될 수 있습니다. Data API의 ReadRows 메서드를 사용하여 연속적인 구체화된 뷰를 읽을 때 초당 요청 수, 지연 시간, 처리량에 대한 Bigtable 측정항목이 생성됩니다. 자세한 내용은 측정항목을 참조하세요.

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

제한사항

  • 인스턴스당 최대 50개의 연속 구체화된 뷰를 만들 수 있습니다.
  • 테이블당 최대 5개의 연속 구체화된 뷰를 만들 수 있습니다. 필요한 경우 Cloud Customer Care에 문의하여 이 한도 상향을 요청할 수 있습니다.
  • _key를 지정하지 않고 뷰를 만들 때 소스 테이블에서 선택한 열은 NULL가 아니어야 합니다. 자세한 내용은 GROUP BY 또는 ORDER BY 절로 정의된 row key를 참조하세요.
  • 연속 구체화된 뷰를 정의하는 SQL 쿼리는 수정할 수 없습니다. 연속 구체화된 뷰를 삭제하고 변경사항이 적용된 새 뷰를 만들어야 합니다.
  • 다른 연속 구체화된 뷰 또는 논리 뷰의 연속 구체화된 뷰를 만들 수 없습니다.
  • 연속 구체화된 뷰를 정의하는 쿼리는 SELECT *를 사용할 수 없습니다.
  • 연속 구체화된 뷰에는 가비지 컬렉션 정책을 구성할 수 없습니다. 모든 데이터 보관은 소스 테이블의 가비지 컬렉션 정책에 의거하여 제어되며 소스의 가비지 컬렉션은 연속적인 구체화된 뷰에 자동으로 반영됩니다.
  • 마이크로초 타임스탬프 세분성이 있는 테이블에는 연속 구체화된 뷰를 만들 수 없습니다.

다음 단계