변경 데이터 캡처

3. 문제 요소

변경 데이터 캡처(CDC) 시스템 구축 및 운영은 복잡한 문제들의 균형을 맞추는 과정이다. 시스템 개발자는 애플리케이션 로직부터 물리적 스토리지에 이르기까지 다양한 방식과 시스템 계층을 조합하여 CDC 메커니즘을 설정할 수 있다.

특히 트랜잭션 로그 기반 CDC 방식은 여러 장점에도 불구하고 다음과 같은 기술적 어려움이 있다.

• '''표준 부재 및 데이터베이스 관리 시스템(DBMS) 종속성''': 트랜잭션 로그의 구조, 내용, 사용 방식은 DBMS마다 다르며 표준화되어 있지 않다. 대부분의 DBMS는 로그의 내부 형식을 공개하지 않아 특정 시스템에 종속적인 해결책이 필요하다. 일부 DBMS(예: 오라클, DB2, SQL/MP, SQL/MX, SQL Server 2008 등)는 로그 접근을 위한 프로그래밍 인터페이스를 제공하기도 하지만, 이것이 모든 시스템에 적용되는 것은 아니다.
• '''로그 관리의 복잡성''': 트랜잭션 로그를 읽는 작업과 DBMS가 주기적으로 로그 파일을 오프라인 저장소로 보관(아카이빙)하는 작업을 효과적으로 조율해야 한다.
• '''데이터 형식 변환 문제''': 트랜잭션 로그에는 종종 물리적인 저장 형식(예: 최소한의 버퍼 차이)으로 데이터가 기록된다. 이를 변경 데이터를 소비하는 시스템이 이해하고 활용할 수 있는 논리적인 데이터 형식으로 변환하는 과정이 필요할 수 있다.
• '''DBMS 버전 간 호환성 문제''': DBMS 버전이 업그레이드될 때 트랜잭션 로그의 형식이 변경될 수 있으며, CDC 솔루션은 이러한 변화에 대응할 수 있어야 한다.
• '''롤백된 트랜잭션 처리''': 로그에는 기록되었지만 최종적으로 커밋되지 않고 롤백된 변경 사항들이 포함될 수 있다. CDC 시스템은 이러한 커밋되지 않은 변경 사항을 식별하고 결과에서 제외해야 한다.
• '''메타데이터 변경 처리''': 데이터베이스 테이블의 구조(스키마) 변경과 같은 메타데이터 변경 사항이 발생했을 때, 이를 올바르게 해석하고 CDC 프로세스에 반영하는 것이 어려울 수 있다.

3. 1. 부적절한 소스 시스템

3. 2. 캡처 추적

• 데이터베이스 트리거를 이용하여 변경 사항을 감지하고 기록하는 방식.
• 데이터 변경 작업 직후 트랜잭션 로그를 읽어 변경 내역을 파악하는 방식.

• 타임스탬프 활용: 변경 사항을 추적해야 하는 테이블에 각 행이 마지막으로 수정된 시간을 기록하는 열(예: `LAST_UPDATE`, `LAST_MODIFIED`)을 둔다. 마지막으로 데이터를 가져간 시점보다 최신 타임스탬프를 가진 행은 변경된 것으로 간주한다. 이 방식은 낙관적 잠금과 같은 다른 목적으로 이미 타임스탬프 열이 사용되고 있는 경우 쉽게 적용할 수 있다.
• 버전 번호 활용: 테이블에 버전 번호를 관리하는 열(예: `VERSION_NUMBER`)을 추가한다. 각 행이 변경될 때마다 버전 번호를 부여하거나, 테이블 전체 또는 관련 테이블 그룹에 대한 현재 버전을 별도의 참조 구조(예: 참조 테이블)에 유지 관리한다. 변경 캡처 시, 참조 구조에 기록된 마지막 버전 이후의 버전 번호를 가진 데이터를 변경된 것으로 간주하고, 캡처가 완료되면 참조 구조의 버전을 최신으로 업데이트한다. (단, 이는 각 행마다 독립적인 버전 번호를 사용하는 낙관적 잠금의 행 수준 버전 관리와는 다른 개념이다. CDC에서 행 수준 버전을 사용하려면 모든 행의 초기 버전을 알아야 하는데, 이는 현실적으로 관리가 어렵다.)
• 상태 플래그 활용: 테이블 행에 변경 여부를 나타내는 상태 열(예: 변경 시 `true`로 설정되는 불리언 열)을 두어 변경된 행을 식별한다. 이 방식은 타임스탬프나 버전 번호 방식과 함께 사용될 수도 있다. 예를 들어, 최신 타임스탬프나 버전 번호를 가졌더라도 상태 플래그가 특정 조건(예: '검증 필요')을 나타내면 대상 시스템에서 즉시 업데이트하지 않도록 제어할 수 있다.
• 조합 방식: 위에서 언급된 타임스탬프, 버전 번호, 상태 플래그 방식을 조합하여 사용하는 것은 특히 강력한 변경 추적 메커니즘을 제공한다. 세 요소는 서로 보완적이며, 함께 사용하면 "상태 코드가 '운영 준비 완료'이고, 버전 2.1이며, 2005년 6월 1일 0시부터 2005년 7월 1일 0시 사이에 변경된 모든 데이터 캡처"와 같이 매우 구체적인 조건으로 변경 데이터를 식별할 수 있다.

예를 들어, 계정(Accounts) 테이블의 76번 행이 2008년 11월 2일 0시 15분에 수정되었다면, 큐 테이블에는 `(1, 'Accounts', 76, '2008-11-02 00:15:00', 'Update')`와 같은 데이터가 기록될 수 있다. 더 정교한 설계에서는 실제로 변경된 데이터 값 자체를 큐 테이블에 기록하기도 한다.
트랜잭션 로그 기반 방식데이터베이스의 트랜잭션 로그를 직접 읽어 변경 사항을 캡처하는 방식도 널리 사용된다. 이 방식은 다음과 같은 뚜렷한 장점을 가진다.

• 데이터베이스 영향 최소화: 특히 로그 파일을 별도의 전용 호스트로 전송하여 처리하는 경우, 원본 데이터베이스 시스템에 주는 부하가 매우 적다.
• 애플리케이션 수정 불필요: 데이터베이스를 사용하는 기존 애플리케이션 코드를 변경할 필요가 없다.
• 낮은 지연 시간: 변경 사항이 로그에 기록되는 즉시 감지할 수 있어 실시간 데이터 동기화에 유리하다.
• 트랜잭션 무결성 보장: 로그 스캔을 통해 원본 트랜잭션이 커밋된 순서대로 변경 스트림을 생성하고 재생할 수 있으며, 단일 트랜잭션에 포함된 여러 테이블의 변경 사항을 일관성 있게 처리할 수 있다.
• 데이터베이스 스키마 변경 불필요: 추적을 위해 테이블 구조를 변경할 필요가 없다.

• 표준 부재 및 DBMS 종속성: 데이터 접근 방식과 달리 트랜잭션 로그의 구조, 내용, 사용 방식은 데이터베이스 관리 시스템(DBMS)마다 다르며 표준화되어 있지 않다. 대부분의 DBMS는 로그의 내부 형식을 공개하지 않지만, 일부(예: 오라클, DB2, SQL/MP, SQL/MX, SQL Server 2008)는 로그 접근을 위한 프로그래밍 인터페이스를 제공하기도 한다.
• 로그 관리의 복잡성: 로그 파일을 읽는 작업과 데이터베이스 시스템이 주기적으로 로그 파일을 보관(아카이빙)하는 작업을 조율해야 한다.
• 데이터 형식 변환: 트랜잭션 로그에는 물리적인 저장 형식(예: 버퍼 변경 내역)으로 기록되는 경우가 많아, 이를 애플리케이션에서 사용하기 쉬운 논리적인 데이터 형식으로 변환해야 할 수 있다.
• DBMS 버전 간 호환성: DBMS 버전이 업그레이드될 때 로그 형식이 변경될 수 있어 이에 대한 대응이 필요하다.
• 롤백된 트랜잭션 처리: 로그에는 기록되었지만 최종적으로 커밋되지 않고 롤백된 변경 사항을 식별하고 제외해야 한다.
• 메타데이터 변경 처리: 테이블 구조(스키마) 변경과 같은 메타데이터 변경 사항을 올바르게 해석하고 처리해야 한다.

3. 3. 푸시(Push) vs. 풀(Pull)

• '''푸시'''(Push): 소스 시스템(프로세스)이 자체적으로 변경 데이터의 스냅샷을 생성하여 대상 시스템(다운스트림 프로세스)으로 직접 전달하는 방식이다. 대상 시스템은 전달받은 스냅샷을 사용하고, 필요한 경우 이를 가공하여 또 다른 대상 시스템으로 전달할 수 있다.
• '''풀'''(Pull): 대상 시스템(소스 바로 다음의 다운스트림 타겟)이 소스 시스템에게 변경된 데이터 제공을 요청하는 방식이다. 소스 시스템은 요청에 따라 데이터를 전달하며, 대상 시스템은 이 데이터를 받아 처리한다. 푸시 방식과 마찬가지로, 대상 시스템은 받은 스냅샷을 다음 대상 시스템에 전달할 수 있다.

4. 대안

• 유형 1: 기존 데이터를 새 데이터로 덮어쓴다.
• 유형 2: 데이터 변경 이력을 모두 유지한다.
• 유형 3: 이전 값과 현재 값만 유지한다.

참조

_[1] 서적 4ggg Rty
_[2] 서적 4ggg Rty