변경 내역 개요

변경 내역은 Spanner 데이터베이스의 데이터 변경사항(삽입, 업데이트, 삭제)을 거의 실시간으로 감시하고 스트리밍합니다.

이 페이지에서는 Spanner 변경 내역의 작업 및 작동 방식에 대한 대략적인 개요를 제공합니다. 데이터베이스에서 변경 내역을 만들고 관리하여 다른 서비스와 연결하는 방법은 다음 단계의 링크를 참조하세요.

변경 내역의 용도

변경 내역은 데이터 변경사항을 다른 서비스로 스트리밍할 수 있는 유연하고 확장 가능한 방법을 제공합니다. 일반적인 사용 사례는 다음과 같습니다.

  • 분석을 위해 Spanner 데이터 변경사항을 BigQuery와 같은 데이터 웨어하우스에 복제합니다.

  • 메시지 큐(예: Pub/Sub)로 전송되는 데이터 변경사항을 기반으로 애플리케이션 로직을 트리거합니다.

  • 규정 준수 또는 보관처리 목적으로 Cloud Storage에 데이터 변경사항을 저장합니다.

변경 내역 구성

Spanner는 테이블 및 색인과 마찬가지로 변경 내역을 스키마 객체로 취급합니다. 따라서 DDL 문을 사용하여 변경 내역을 생성, 수정, 삭제하고 다른 DDL 관리 스키마 객체와 마찬가지로 데이터베이스의 변경 내역을 확인할 수 있습니다.

변경 내역을 구성하여 전체 데이터베이스에서 데이터 변경사항을 확인하거나 특정 테이블 및 열로 범위를 제한할 수 있습니다. 한 데이터베이스는 여러 변경 내역을 포함할 수 있으며, 특정 테이블 또는 열에서 이를 감시하는 여러 내역을 한도 내에서 포함할 수 있습니다.

또한 데이터 보관 기간, 값 캡처 유형, TTL 기반 삭제 필터링 또는 테이블 수정 필터를 지정하도록 변경 내역을 구성할 수도 있습니다.

변경 내역을 만드는 DDL을 실행하면 장기 실행 작업이 시작됩니다. 완료되면 새 변경 내역이 즉시 할당된 테이블과 열을 감시하기 시작합니다.

암시적으로 테이블 및 열 보기

전체 테이블을 감시하는 내역은 해당 테이블 정의가 업데이트되더라도 테이블의 모든 열을 암시적으로 감시합니다. 예를 들어 해당 테이블에 새 열을 추가하면 변경 내역의 구성을 수정하지 않아도 변경 내역이 자동으로 새 열을 감시하기 시작합니다. 마찬가지로, 테이블에서 삭제된 열은 변경 내역이 자동으로 감시를 중지합니다.

전체 데이터베이스 변경 내역은 동일한 방식으로 작동합니다. 모든 테이블의 모든 열을 암시적으로 감시하여 변경 내역이 생성된 후에 추가된 테이블 또는 열을 자동으로 감시하고 삭제된 테이블 또는 열의 감시를 중지합니다.

명시적으로 테이블 및 열 보기

테이블의 특정 열만 감시하도록 변경 내역을 구성한 후 나중에 열을 테이블에 추가하면 변경 내역을 재구성하지 않는 한 변경 내역이 이러한 열을 감시하지 않습니다.

데이터베이스 스키마는 변경 내역을 명시적으로 감시하는 열 또는 테이블의 종속 객체로 취급합니다. 이러한 열 또는 테이블을 삭제하려면 먼저 이를 명시적으로 감시하는 변경 내역의 구성에서 이를 수동으로 삭제해야 합니다.

변경 내역이 감시하는 데이터 변경사항 유형

변경 내역이 감시하는 데이터 변경사항에는 감시 중인 테이블 및 열에 적용되는 모든 삽입, 업데이트, 삭제가 포함됩니다. 변경사항은 다음과 같은 경우에 발생할 수 있습니다.

변경 내역은 사용자가 만든 열 및 테이블에서만 데이터 변경사항을 감시할 수 있습니다. 색인, 뷰, 기타 변경 내역, 시스템 테이블(정보 스키마 또는 통계 테이블)은 감시하지 않습니다. 열이 기본 키의 일부가 아닌 경우 변경 내역에서 생성된 열을 감시하지 않습니다. 기본 키 열은 항상 추적됩니다.

또한 변경 내역은 스키마 변경사항 또는 스키마 변경이 직접적인 원인인 데이터 변경사항을 감시하지 않습니다. 예를 들어 전체 데이터베이스를 감시하는 변경 내역은 테이블 삭제로 데이터베이스에서 테이블의 모든 데이터가 삭제되더라도 테이블 삭제를 데이터 변경사항으로 취급하지 않습니다.

Spanner가 변경 내역을 쓰고 변경하는 방법

Spanner는 변경 내역이 감시하는 열에서 데이터 변경사항을 감지할 때마다 데이터 변경 레코드내부 스토리지에 씁니다. 이 작업은 동일한 트랜잭션 내에서 데이터 변경과 동기식으로 이루어집니다. Spanner는 이러한 쓰기를 둘 다 같은 위치에 배치하기 때문에 동일한 서버에서 처리되어 쓰기 처리가 최소화됩니다.

데이터 변경 레코드의 콘텐츠

변경 내역에서 작성하는 모든 데이터 변경 레코드에는 데이터 변경사항에 대한 다음 정보가 포함됩니다.

  • 영향을 받는 테이블의 이름

  • 변경된 행을 식별하는 기본 키의 이름, 값, 데이터 유형

  • 변경 내역 정의를 기반으로 캡처된 변경된 행의 열의 이름 및 데이터 유형

  • 행 열의 이전 값. 이전 값의 가용성과 해당 값의 추적 콘텐츠(수정된 열만 또는 전체 추적 행이 될 수 있음)는 사용자 구성 값 캡처 유형에 따라 다릅니다.

  • 행 열의 새 값. 새 값의 가용성과 해당 값의 추적 콘텐츠는 사용자 구성 값 캡처 유형에 따라 다릅니다.

  • 수정 유형(삽입, 업데이트 또는 삭제)

  • 커밋 타임스탬프

  • 트랜잭션 ID

  • 레코드 시퀀스 넘버

  • 데이터 변경 레코드의 값 캡처 유형

데이터 변경 레코드의 구조에 대한 자세한 내용은 데이터 변경 레코드를 참조하세요.

데이터 보관

변경 내역은 1~7일 동안 데이터 변경 레코드를 보관합니다. DDL을 사용하여 변경 내역을 처음 만들 때 1일(기본값) 외의 데이터 보관 한도를 지정합니다. 이후 언제든지 조정할 수 있습니다. 변경 내역의 데이터 보관 한도를 줄이면 그 즉시 변경 내역의 리더가 새 한도 이전의 모든 변경 데이터를 영구적으로 사용할 수 없게 됩니다.

데이터 보관 기간에는 장단점이 있습니다. 보관 기간이 길면 내역의 데이터베이스에 대한 스토리지 수요가 증가합니다.

값 캡처 유형

변경 내역의 값 캡처 유형 구성 옵션은 변경된 행의 값을 저장하는 방식을 제어합니다. DDL을 사용하여 변경 내역에 다음 값 캡처 유형 중 하나를 지정할 수 있습니다.

  • OLD_AND_NEW_VALUES: 행에서 수정된 열의 이전 값과 새 값을 모두 캡처합니다.

  • NEW_VALUES: 키가 아닌 열의 새 값만 캡처하고 이전 값은 캡처하지 않습니다.

  • NEW_ROW: 해당 열이 변경될 때마다 수정 및 수정되지 않은 감시된 열의 모든 새 값을 캡처합니다. 이전 값은 캡처되지 않습니다.

  • NEW_ROW_AND_OLD_VALUES: 수정 및 수정되지 않은 열의 모든 새 값과 수정된 열의 이전 값을 캡처합니다.

TTL(수명) 기반 삭제 제외

Spanner에서 TTL(수명)을 사용하면 Spanner 테이블에서 주기적으로 데이터를 삭제하는 정책을 설정할 수 있습니다. 기본적으로 변경 내역에는 모든 TTL 기반 삭제가 포함됩니다. exclude_ttl_deletes를 사용하여 TTL 기반 삭제를 제외하도록 변경 내역을 설정할 수 있습니다. TTL 기반 삭제를 제외하도록 이 필터를 설정하면 향후 TTL 기반 삭제만 변경 내역에서 제외됩니다.

이 필터의 기본값은 false입니다. TTL 기반 삭제를 제외하려면 필터를 true로 설정합니다. 변경 내역을 만들 때 필터를 추가하거나 필터를 포함하도록 기존 변경 내역을 수정할 수 있습니다.

테이블 수정 유형

기본적으로 변경 내역에는 삽입, 업데이트, 삭제와 같은 모든 테이블 수정사항이 포함됩니다. 사용 가능한 다음 필터 옵션을 사용하여 변경 내역의 범위에서 이러한 테이블 수정사항 중 하나 이상을 필터링할 수 있습니다.

  • exclude_insert: 모든 INSERT 테이블 수정사항을 제외합니다.
  • exclude_update: 모든 UPDATE 테이블 수정사항을 제외합니다.
  • exclude_delete: 모든 DELETE 테이블 수정사항을 제외합니다.

이러한 필터의 기본값은 false입니다. 특정 유형의 테이블 수정을 제외하려면 필터를 true로 설정합니다. 하나 이상의 필터를 동시에 설정할 수 있습니다.

변경 내역을 만들 때 테이블 수정 유형에 대한 필터를 추가하거나 기존 변경 내역에서 테이블 수정 유형에 대한 필터를 수정할 수 있습니다.

변경 내역 읽기

Spanner는 변경 내역의 데이터를 읽는 여러 방법을 제공합니다.

  • Dataflow를 통해 Apache Beam SpannerIO 커넥터를 사용합니다. 대부분의 변경 내역 애플리케이션에 권장되는 솔루션입니다. Google은 또한 일반적인 사용 사례를 위한 Dataflow 템플릿을 제공합니다.

  • Spanner API를 사용하여 직접 읽습니다. 이 경우 최대 속도와 유연성을 위해 Dataflow 파이프라인의 추상화와 기능을 포기하게 됩니다.

  • Spanner 변경 내역에 Debezium 기반 Kafka 커넥터를 사용합니다. 이 커넥터는 변경 레코드를 Kafka 주제로 직접 스트리밍합니다.

방향 읽기를 사용하여 변경 내역 읽기를 부분 격리할 수 있습니다. 방향성 읽기는 데이터베이스의 트랜잭션 워크로드에 미치는 영향을 최소화하는 데 도움이 될 수 있습니다. Spanner API를 사용하여 변경 내역 읽기를 멀티 리전 인스턴스 구성 내의 특정 복제본 유형 또는 리전으로 라우팅하거나 선택적 읽기 전용 리전이 포함된 커스텀 리전 구성으로 라우팅할 수 있습니다. 자세한 내용은 방향성 읽기를 참조하세요.

Dataflow 사용

Apache Beam SpannerIO 커넥터를 사용하여 변경 내역에서 읽는 Dataflow 파이프라인을 빌드합니다. 특정 변경 내역에 대한 세부정보로 커넥터를 구성하면 Dataflow 파이프라인의 후속 변환에서 추가 처리에 사용할 수 있는 제한되지 않은 단일 PCollection 데이터 세트에 새 데이터 변경 레코드가 자동으로 출력됩니다.

Dataflow는 윈도우 함수를 사용하여 제한되지 않은 컬렉션을 논리적 구성요소 또는 윈도우로 나눕니다. 따라서 Dataflow는 변경 내역에서 읽을 때 약 6초의 지연 시간으로 거의 실시간에 가까운 스트리밍을 제공합니다.

Google은 내역의 모든 데이터 변경사항을 BigQuery 데이터 세트로 전송하거나 Cloud Storage 버킷으로 복사하는 등의 일반적인 변경 내역 사용 사례를 위해 Dataflow 파이프라인을 빠르게 빌드할 수 있는 템플릿을 제공합니다.

변경 내역과 Dataflow가 함께 작동하는 방식에 대한 자세한 개요는 Dataflow를 사용하여 변경 내역 연결 빌드를 참조하세요.

API 사용

Dataflow를 사용하여 변경 내역 파이프라인을 빌드하는 대신 Spanner API를 사용하여 변경 내역의 레코드를 직접 읽는 코드를 작성할 수 있습니다. 이렇게 하면 SpannerIO 커넥터와 동일한 방식으로 데이터 변경 레코드를 읽을 수 있습니다. 변경 내역 데이터를 읽을 때 지연 시간이 최소화되는 대신 커넥터가 제공하는 추상화를 포기해야 합니다.

자세한 내용은 변경 내역 쿼리를 참조하세요. 변경 내역을 쿼리하고 반환된 레코드를 해석하는 방법에 대한 자세한 내용은 변경 내역 파티션, 레코드, 쿼리를 참조하세요.

Kafka 커넥터 사용

Kafka 커넥터는 변경 내역 레코드를 Kafka 주제로 직접 출력하고, Spanner API를 사용하여 변경 내역 쿼리의 세부정보를 제거합니다.

변경 내역과 Kafka 커넥터가 함께 작동하는 방식에 대한 자세한 내용은 Kafka 커넥터로 변경 내역 연결 빌드를 참조하세요.

한도

변경 내역에는 데이터베이스에 포함될 수 있는 최대 변경 내역 수와 단일 열을 감시할 수 있는 최대 스트림 수를 포함한 여러 한도가 있습니다. 전체 목록은 변경 내역 한도를 참조하세요.

권한

변경 내역에는 다음이 사용됩니다.

  • 변경 내역을 생성, 업데이트 또는 삭제하려면 spanner.databases.updateDdl이 필요합니다.

  • 변경 내역의 데이터를 읽으려면 spanner.databases.select가 필요합니다.

SpannerIO 커넥터를 사용하는 경우 변경 내역 데이터를 읽는 Dataflow 작업의 소유자에게 애플리케이션 데이터베이스 또는 별도의 메타데이터 데이터베이스에 대한 추가 IAM 권한이 필요합니다. 메타데이터 데이터베이스 만들기를 참조하세요.

다음 단계