데이터 캡처 변경

Change data capture

데이터베이스에서 변경 데이터 캡처(CDC)는 변경된 데이터를 사용하여 조치를 취할 수 있도록 변경된 데이터를 결정하고 추적하는 데 사용되는 소프트웨어 설계 패턴 집합이다.

CDC는 기업 데이터 소스에 대한 변경사항의 식별, 캡처 및 전달에 기반한 데이터 통합 접근방식이다.

CDC는 데이터 웨어하우스 환경에서 종종 발생하는데, 이는 데이터 웨어하우스의 핵심 기능 중 하나이기 때문이다. 그러나 CDC는 어떤 데이터베이스나 데이터 저장소 시스템에서도 활용될 수 있다.

방법론

시스템 개발자는 여러 가지 방법으로 CDC 메커니즘을 설정할 수 있으며, 애플리케이션 로직에서 물리적 스토리지에 이르는 시스템 계층의 조합 또는 하나의 조합으로 설정할 수 있다.

단순화된 CDC 맥락에서, 한 컴퓨터 시스템은 이전 시점으로부터 변경된 것으로 여겨지는 데이터를 가지고 있고, 두 번째 컴퓨터 시스템은 그 변경된 데이터에 기초하여 조치를 취해야 한다.전자가 근원이고 후자가 대상이다.소스와 대상이 물리적으로 동일한 시스템일 수는 있지만, 그렇다고 해서 설계 패턴이 논리적으로 바뀌지는 않을 것이다.여러 CDC 솔루션이 단일 시스템에 존재할 수 있다.

행의 타임스탬프

변경 내용을 캡처해야 하는 표에는 마지막 변경 시간을 나타내는 열이 있을 수 있다.LAST_UPDATE 등의 명칭이 일반적이다.해당 열에 타임스탬프가 있는 테이블의 모든 행이 마지막으로 데이터를 캡처한 시간보다 최신인 것으로 간주된다.

행의 타임스탬프는 낙관적 잠금에도 자주 사용되므로 이 열을 자주 사용할 수 있다.

행의 버전 번호

데이터베이스 설계자는 변경사항을 캡처해야 하는 표에 버전 번호를 포함하는 열을 부여한다.VISE_NUMBER 등의 명칭이 일반적이다.

한 가지 방법은 변경된 각 행을 버전 번호로 표시하는 것이다.현재 버전은 테이블 또는 테이블 그룹에 대해 유지 관리된다.이것은 참조표와 같은 지지 구조로 저장된다.변경 캡처가 발생하면 최신 버전 번호를 가진 모든 데이터가 변경된 것으로 간주된다.변경 캡처가 완료되면 참조 테이블이 새 버전 번호로 업데이트된다.

(이 기술을 낙관적 잠금에 사용되는 행 레벨 버전과 혼동하지 마십시오.낙관적 잠금을 위해 각 행에는 독립 버전 번호, 일반적으로 순차 카운터가 있다.이것은 다른 프로세스가 카운터를 증가시키지 않는 경우에만 프로세스가 행을 원자적으로 업데이트하고 카운터를 증가시킬 수 있도록 한다.그러나 CDC는 모든 행의 원래 "시작" 버전을 모르는 한 모든 변경 사항을 찾기 위해 행 수준 버전을 사용할 수 없다.이것은 유지하기가 비실용적이다.)

행의 상태 표시기

이 기술은 타임스탬프와 버전 관리를 보완하거나 보완할 수 있다.예를 들어, 행이 변경되었음을 나타내는 상태 열(예: true로 설정할 때 행이 변경되었음을 나타내는 부울 열)이 테이블 행에 설정된 경우 대체 열을 구성할 수 있다.그렇지 않으면, 새로운 버전 번호나 이후 날짜가 있음에도 불구하고 행이 여전히 대상에서 업데이트되어서는 안 된다는 것을 나타내는 이전 방법의 보완 역할을 할 수 있다(예를 들어, 데이터는 인간 유효성 검사가 필요할 수 있다).

행의 시간/버전/상태

이 접근방식은 앞에서 논의한 세 가지 방법을 결합한다.지적했듯이, 단일 시스템에서 복수의 CDC 솔루션이 작동하는 것을 흔히 볼 수 있지만, 시간, 버전 및 상태의 조합은 특히 강력한 메커니즘을 제공하며 프로그래머는 가능한 경우 3중창으로 활용해야 한다.그 세 가지 요소는 중복되거나 불필요한 것이 아니다.이 데이터를 함께 사용하면 "상태 코드가 생산 준비되었음을 나타내는 오전 6/1/2005 12:00에서 오전 7/1/2005 12:00 사이에 변경된 버전 2.1의 모든 데이터를 캡처"와 같은 논리가 가능하다.

테이블의 트리거

변경된 데이터를 여러 대상에 전달하기 위한 게시/구독 패턴을 포함할 수 있다.이 접근 방식에서 트랜잭션 테이블에서 발생하는 로그 이벤트를 나중에 "재생"할 수 있는 다른 대기열 테이블로 트리거한다.예를 들어, 계정 테이블이 이 테이블에 대해 트랜잭션을 수행할 때 트리거가 발생하여 이벤트 기록 또는 델타 기록을 별도의 대기열 테이블에 저장할 수 있다고 가정하십시오.대기열 테이블에는 다음 필드의 스키마가 있을 수 있다.ID, TableName, RowId, TimeStamp, Operation.계정 샘플에 삽입된 데이터는 1, 계정, 76, 11/02/2008 오전 12:15, 업데이트일 수 있다.더 복잡한 설계는 변경된 실제 데이터를 기록할 수 있다.그러면 이 대기열 테이블을 "재생"하여 소스 시스템에서 대상으로 데이터를 복제할 수 있다.

[더 많은 토론 필요]

이 기술의 예는 로그 트리거로 알려진 패턴이다.

이벤트 프로그래밍

적절한 시점에 애플리케이션으로 변경을 코딩하는 것도 데이터가 변경되었음을 지능적으로 식별할 수 있는 또 다른 방법이다.이 방법은 프로그래밍 대 보다 쉽게 구현되는 "덤" 트리거를 포함하지만, COMPT 후 또는 특정 열이 특정 값으로 변경된 후에만(대상 시스템이 찾고 있는 것)와 같이 보다 정확하고 바람직한 CDC를 제공할 수 있다.

로그 스캐너

대부분의 데이터베이스 관리 시스템은 데이터베이스 컨텐츠 및 메타데이터에 대한 변경사항을 기록하는 트랜잭션 로그를 관리한다.데이터베이스 트랜잭션 로그의 내용을 스캔하고 해석함으로써 데이터베이스에 대한 변경사항을 비침해적인 방법으로 포착할 수 있다.

변경 데이터 캡처를 위해 트랜잭션 로그를 사용하는 것은 트랜잭션 로그의 구조, 내용 및 사용이 데이터베이스 관리 시스템에만 한정된다는 점에서 난제를 제공한다.데이터 액세스와 달리 트랜잭션 로그에 대한 표준은 존재하지 않는다.일부 데이터베이스는 트랜잭션 로그에 프로그래밍 방식 인터페이스를 제공하지만(예를 들어, 다음과 같은 경우) 대부분의 데이터베이스 관리 시스템은 트랜잭션 로그의 내부 형식을 문서화하지 않는다.Oracle, DB2, SQL/MP, SQL/MX 및 SQL Server 2008).

변경 데이터 캡처를 위해 트랜잭션 로그를 사용하는 다른 문제:

  • 트랜잭션 로그 읽기 및 로그 파일 보관 조정(데이터베이스 관리 소프트웨어는 일반적으로 로그 파일을 오프라인으로 정기적으로 보관)
  • 트랜잭션 로그에 기록되는 물리적 스토리지 형식과 데이터베이스 사용자가 일반적으로 기대하는 논리 형식 간의 변환(예: 일부 트랜잭션 로그는 변경 소비자에게 직접 유용하지 않은 최소한의 버퍼 차이만 저장)
  • 데이터베이스 관리 시스템 버전 간의 트랜잭션 로그 형식 변경 처리.
  • 데이터베이스가 트랜잭션 로그에 기록한 후 나중에 롤백한 커밋되지 않은 변경사항 제거.
  • 데이터베이스에서 테이블 메타데이터 변경사항 처리.

트랜잭션 로그 파일을 기반으로 하는 CDC 솔루션은 다음과 같은 뚜렷한 이점을 가지고 있다.

  • 데이터베이스에 미치는 영향 최소화(전용 호스트에서 로그를 처리하는 데 로그 전달을 사용하는 경우 더욱 그러함)
  • 데이터베이스를 사용하는 응용프로그램에 대한 프로그램 변경 필요 없음.
  • 변경사항 획득 시 대기 시간이 짧음.
  • 트랜잭션 무결성: 로그 검색은 원래 트랜잭션을 커밋된 순서대로 재생하는 변경 스트림을 생성할 수 있다.그러한 변경 스트림에는 캡처된 트랜잭션에 참여하는 모든 테이블의 변경이 포함된다.
  • 데이터베이스 스키마를 변경할 필요 없음

교란 요인

복잡한 도메인에서 종종 발생하듯이 CDC 문제에 대한 최종 해결책은 많은 경쟁적 관심사들 사이에서 균형을 맞춰야 할지도 모른다.

부적합한 소스 시스템

데이터 자체를 수정하지 않았을 때 소스 시스템이 메타데이터 변경사항을 저장하면 변경 데이터 캡처의 복잡성은 증가하지만 가치는 감소한다.예를 들어, 일부 데이터 모델은 마지막으로 살펴봤지만 데이터와 동일한 구조에서 데이터를 변경하지 않은 사용자를 추적한다.이로 인해 Change Data Capture에 노이즈가 발생한다.

캡처 추적

실제로 변경 사항을 추적하는 것은 데이터 소스에 따라 달라진다.데이터가 최신 데이터베이스에서 유지되는 경우 Change Data Capture는 단순한 권한의 문제다.두 가지 기법이 공통적으로 사용된다.

데이터가 현대 데이터베이스에 없는 경우 CDC는 프로그래밍 과제가 된다.

푸시 대 당김

  • 푸시: 소스 프로세스는 자체 프로세스 내에서 변경사항의 스냅샷을 생성하고 다운스트림 행을 전달한다.다운스트림 프로세스는 스냅샷을 사용하여 자체 서브셋을 생성하여 다음 프로세스로 전달한다.
  • Pull: 소스에서 즉시 다운스트림되는 대상, 소스에서 데이터에 대한 요청을 준비한다.다운스트림 타겟은 푸시 모델에서와 같이 스냅샷을 다음 타겟으로 전달한다.

대안

천천히 변경되는 차원(SDC) 모델 예

때로는 서서히 변화하는 차원이 하나의 방법으로 이용되기도 한다.[1]

참고 항목


참조

  1. ^ Eroe, Erit (2015). 4ggg. Rty.

참고 항목