SQL Server용 Openflow Connector 비교

이 페이지에서는 SQL Server용 Openflow Connector(Change Tracking 기반)와 SQL Server(CDC)용 Openflow Connector(Change Data Capture 기반)의 차이점을 설명해요. 소스 변경 감지 방식, 소스 부하 영향, 설정 복잡도, 그리고 언제 어떤 커넥터를 골라야 하는지 다룹니다.

출처: Snowflake 문서

본문

Note

이 커넥터는 Snowflake Connector Terms에 의해 규율됩니다.

Snowflake는 SQL Server용으로 두 가지 Openflow 커넥터를 제공합니다. 이들은 주로 소스 변경을 감지하는 방식에서 다릅니다:

SQL Server용 Openflow Connector는 SQL Server Change Tracking을 사용해 폴링 사이에 변경된 행을 식별합니다.
SQL Server(CDC)용 Openflow Connector는 SQL Server Change Data Capture를 사용해 트랜잭션 로그에서 모든 행 수준 변경을 캡처합니다.

공통점

소스 변경 감지 방식을 제외하면 두 커넥터는 동일한 핵심 동작과 요구 사항을 공유합니다:

둘 다 단일 SQL Server 인스턴스의 하나 이상의 데이터베이스에서 선택한 테이블을 근-실시간 또는 일정에 따라 Snowflake로 복제합니다.
둘 다 단일 노드 Openflow 런타임이 필요합니다(Min nodes와 Max nodes를 1로 설정). 지속 워크로드에 맞춰 런타임 크기를 정하세요. 하나의 런타임에서 동일 유형의 커넥터 인스턴스를 여러 개 실행할 수 있습니다. Runtime sizing 참고.
둘 다 SQL Server 인증으로 사용자 이름·비밀번호만 지원합니다.
둘 다 기본 키가 있는 테이블만 복제합니다.

변경 감지 방식의 차이

Change Tracking은 연속된 폴링 사이 변경의 순효과(net effect)만 보고합니다. 두 폴링 사이에 행이 여러 번 업데이트되면 SQL Server용 Openflow Connector는 최종 상태만 보며 중간 상태는 보존되지 않습니다.

Change Data Capture는 개별 DML 작업 하나하나를 보존합니다. 두 연속 폴링 사이에 행이 여러 번 업데이트되면 SQL Server(CDC)용 Openflow Connector는 각 중간 상태를 커밋 순서대로 봅니다.

실무적으로 보면, SQL Server용 Openflow Connector는 현재 행 상태만 중요한 데이터 동기화용 사례에 적합하고, SQL Server(CDC)용 Openflow Connector는 대상을 동기화하는 것에 더해 모든 변경을 캡처해야 하는 감사(audit)·히스토리용 사례에 적합합니다.

소스 데이터베이스 영향

두 SQL Server 기능은 서로 다른 트레이드오프를 중심으로 설계되어 있으며, 커넥터는 그 트레이드오프를 그대로 물려받습니다.

SQL Server용 Openflow Connector는 추적되는 테이블의 모든 DML 작업에 트랜잭션당 오버헤드를 추가합니다:

각 insert·update·delete는 같은 트랜잭션 안에서 SQL Server 내부의 변경 추적 사이드 테이블에 행을 씁니다. Microsoft는 이 오버헤드가 낮도록 설계했습니다.
변경을 읽는지 여부와 관계없이 모든 DML 작업에서 비용이 발생합니다.
높은 DML 워크로드, 특히 넓은 기본 키나 열 추적(column tracking)을 켠 경우 오버헤드가 측정 가능해질 수 있습니다.
커넥터의 증분 쿼리는 매 폴링마다 소스 테이블에 대해 CHANGETABLE(CHANGES ...)를 조인하므로, 폴링 빈도와 테이블 활동이 소스 부하에 더해집니다.

SQL Server(CDC)용 Openflow Connector는 DML 트랜잭션에 비용을 추가하지 않지만, 소스의 다른 곳으로 비용을 옮깁니다:

SQL Server는 어차피 트랜잭션 로그를 쓰므로 DML 트랜잭션은 추가 쓰기 비용을 지불하지 않습니다.
SQL Server Agent 캡처 작업이 백그라운드에서 트랜잭션 로그를 읽고 전용 변경 테이블을 채웁니다. 이 작업은 소스에서 CPU와 I/O를 소비합니다.
커넥터는 행 잠금을 걸지 않고 전용 변경 테이블에서 변경을 읽으므로, 복제는 애플리케이션 트래픽을 늦추지도, 그것에 의해 늦춰지지도 않습니다.
트랜잭션 로그는 캡처 작업의 위치를 지나서 잘릴(truncate) 수 없습니다. 뒤처진 캡처 작업이나 오래 실행되는 트랜잭션은 로그가 커지게 할 수 있습니다.

대략적인 지침으로:

DML 규모가 낮거나 중간이고 단순한 설정이 중요한 데이터베이스라면 SQL Server용 Openflow Connector가 더 가벼운 선택인 경향이 있습니다.
고부하 OLTP 워크로드이거나 복제 읽기를 라이브 소스 테이블에서 떼어내는 것이 중요하다면 SQL Server(CDC)용 Openflow Connector가 더 잘 확장되는 경향이 있습니다. 대가는 소스 쪽 설정이 더 많고 트랜잭션 로그 보존에 더 신경을 써야 한다는 점입니다.

지원되는 SQL Server 에디션과 환경

두 SQL Server 기능은 소스에서 사용 가능 여부가 다릅니다:

Change Tracking은 Express와 Web을 포함한 모든 SQL Server 에디션, 그리고 Azure SQL Database와 Azure SQL Managed Instance에서 사용할 수 있습니다.
Change Data Capture는 SQL Server Standard 또는 Enterprise 에디션이 필요합니다. SQL Server Express나 Web에서는 사용할 수 없습니다.

각 커넥터가 지원하는 구체적인 버전·플랫폼은 Supported SQL Server versions와 Supported SQL Server versions를 참고하세요.

설정 복잡도

SQL Server용 Openflow Connector는 데이터베이스 수준 설정 하나(CHANGE_TRACKING = ON)와 복제되는 테이블마다 테이블 수준 설정 하나가 필요합니다. SQL Server Agent도, 캡처 인스턴스도 필요 없습니다.
SQL Server(CDC)용 Openflow Connector는 소스에서 SQL Server Agent가 실행 중이어야 합니다. 복제되는 각 테이블에는 sys.sp_cdc_enable_table로 생성하는 캡처 인스턴스가 필요합니다. 지속적인 복제는 캡처 작업이 건강하게 유지되는지에 달려 있습니다. 복제되는 테이블에 64KB보다 큰 LOB 열이 포함되어 있으면 소스 인스턴스의 SQL Server max text repl size 설정도 올려야 합니다. 플랫폼별 구성 단계는 Raise max text repl size for large LOB columns를 참고하세요.

스키마 변경 처리

두 커넥터 모두 테이블의 전체 재스냅샷 없이, 복제 중 지원되는 소스 테이블 스키마 변경을 적용합니다. 어느 커넥터도 숫자 열의 정밀도(precision)나 배율(scale) 변경은 지원하지 않습니다. 변경 감지가 활성화된 상태에서 테이블의 기본 키를 바꾸는 것은 소스에서 SQL Server가 차단합니다. 커넥터를 새 복제 키로 옮기려면 해당 테이블의 복제를 다시 시작하세요.

SQL Server용 Openflow Connector는 다음 폴링에서 스키마 변경을 반영합니다. 새 열을 대상 테이블에 추가하고(기존 행은 백필하지 않음), 삭제된 열은 기존 데이터를 보존하기 위해 __SNOWFLAKE_DELETED 접미사를 붙여 이름을 바꿔 소프트 삭제합니다.
SQL Server(CDC)용 Openflow Connector는 업데이트된 스키마를 반영하는 새 SQL Server 캡처 인스턴스로 전환해 스키마 변경을 자동 적용합니다. 이는 설정 중 배포되는 Openflow CDC 래퍼 프로시저에 의존합니다. 이 프로시저 덕분에 커넥터가 승격된 권한을 보유하지 않고도 캡처 인스턴스를 만들고 드롭할 수 있습니다.

자세한 내용은 Schema changes와 About Openflow Connector for SQL Server의 Schema changes 섹션을 참고하세요.

언제 어떤 커넥터를 선택할까

다음에 해당하면 SQL Server용 Openflow Connector를 선택하세요:

대상에서 현재 행 상태만 필요할 때(예: 데이터 동기화나 중앙 보고).
소스 쪽 설정을 가장 단순하게 하고 싶을 때.
Change Data Capture를 사용할 수 없는 에디션이나 플랫폼에서 실행할 때.
DML 규모가 낮거나 중간이고 소스의 움직이는 부품을 최소화하고 싶을 때.

다음에 해당하면 SQL Server(CDC)용 Openflow Connector를 선택하세요:

감사·히스토리용 사례에서 폴링 사이 중간 상태를 포함한 모든 개별 행 수준 변경이 필요할 때.
고부하 OLTP 소스를 운영하고 복제 읽기를 라이브 테이블에서 떼어내고 싶을 때.
SQL Server Standard 또는 Enterprise에서 실행할 수 있고 SQL Server Agent 캡처 작업을 운영할 수 있을 때.

SQL Server용 Openflow Connector 비교