분산 환경에 대해 적절한 기본 키 선택
증분 동기화에 참가하는 테이블의 경우 Sync Framework에서 각 행을 고유하게 식별하도록 요구합니다. 클라이언트 및 서버 스냅숏 동기화의 경우에는 각 행을 고유하게 식별하지 않아도 됩니다. 일반적으로 행은 서버 또는 피어 데이터베이스에서 정의되는 기본 키로 식별됩니다. 특히 분산 환경에서는 기본 키로 사용할 열 형식을 주의해서 선택해야 합니다. 기본 키는 모든 노드에서 고유해야 하며 다시 사용하면 안 됩니다. 행이 삭제되면 해당 행의 기본 키가 다른 행에 사용되지 않아야 합니다. 기본 키를 둘 이상의 노드에서 사용하는 경우에는 기본 키 충돌이 발생할 수 있습니다. 이는 모든 분산 환경에서 발생하며 Sync Framework의 제한 사항이 아닙니다. 이 항목에서는 기본 키와 관련하여 선택할 수 있는 몇 가지 옵션 및 분산 환경에서 각 옵션을 사용하는 경우에 대해 설명합니다.
자동 증분(ID) 열
일반적으로 데이터베이스 설계자는 기본 키로 자동 증분 열을 선택합니다. 이 자동 증분 속성(SQL Server의 IDENTITY 속성)은 테이블에 삽입하는 각 레코드에 대해 새 값을 생성합니다. 이 새 값은 현재 값(시드)을 일정한 수(증분)만큼 증가 또는 감소시킨 다음 해당 결과를 삽입되는 행에 할당하는 방식으로 생성됩니다. 자동 증분 열에서는 일반적으로 정수 등의 간단한 데이터 형식을 사용합니다. 이로 인해 클러스터된 인덱스가 보다 간단해지고 조인의 효율성이 높아지며 기본 테이블을 쿼리할 때의 IO가 줄어듭니다.
그러나 시드 및 증분 속성은 고정되어 있으며 그 수가 제한되어 있는 사용 가능한 값 중에서 선택하는 것이기 때문에 기본 키 충돌이 발생할 가능성이 매우 높습니다. 이러한 형식의 키는 다운로드 전용 데이터 캐싱 시나리오에 적합합니다. 이러한 시나리오의 경우 새 기본 키 값을 생성하는 노드는 서버나 지정된 피어뿐입니다. 그러므로 이러한 값은 토폴로지의 모든 노드에서 고유합니다. 삽입 작업이 한 노드에서만 수행되는 경우에는 자동 증분 열을 업로드 전용 및 양방향 시나리오에서도 사용할 수 있습니다. 이러한 시나리오의 경우 삽입 작업은 일반적으로 서버나 지정된 피어에서만 수행되며 업데이트 작업과 삭제 작업(가능한 경우)은 하나 이상의 클라이언트에서 수행됩니다. 둘 이상의 노드에서 삽입 작업을 수행해야 하는 경우에는 이 항목의 뒷부분에서 설명하는 다른 작업 방식 중 하나를 사용해야 합니다.
GUID
GUID(SQL Server의 uniqueidentifier 열)를 기본 키로 사용하면 많은 수의 노드에서 기본 키가 고유하게 유지되며 자동 증분 열을 사용하는 경우 발생할 수 있는 기본 키 충돌의 가능성이 없어집니다. 그러나 기본 키에서 GUID를 사용하면 다음과 같은 결과가 발생합니다.
큰 데이터 형식(16바이트)으로 인해 클러스터된 인덱스의 크기가 커지므로 조인 등의 일반 작업 효율성이 떨어질 수 있습니다.
순서가 지정되지 않은 상태로 GUID가 생성되면 행이 클러스터된 인덱스에서 임의의 위치에 삽입됩니다. 그러면 클러스터된 인덱스가 조각화될 수 있습니다. 이는 기본 테이블을 쿼리하는 데 필요한 IO에 좋지 않은 영향을 줄 수 있습니다.
SQL Server 2005 이상 버전에서는 NEWSEQUENTIALID() 함수를 사용하여 순차적으로 GUID를 생성하여 이러한 조각화를 방지할 수 있습니다.
노드 식별자를 포함하는 키
이 방법을 사용하는 경우 서버 또는 클라이언트 노드에서 고유한 값을 토폴로지 전체에서 고유한 값과 결합하는 키를 사용합니다. 예를 들어 클라이언트 및 서버 동기화에서는 노드에서 고유한 자동 증분 열을 Sync Framework가 각 클라이언트에 할당하는 ID의 해시를 저장하는 열과 결합하여 사용할 수 있습니다. 이 ID는 토폴로지 전체에서 고유한 ClientId입니다. 그런 다음 이 두 열이 포함된 합성 기본 키를 만듭니다. 행 ID와 클라이언트 ID를 하나의 열에 포함할 수 있도록 삽입된 각 행에 대해 값을 생성하는 시스템을 개발하는 방법도 있습니다.
자연 키
이 전략의 경우에는 생성된 키가 아닌 비즈니스 키를 사용하여 레코드를 고유하게 식별합니다. 예를 들어 고객 정보를 저장하는 데 사용되는 테이블은 ID 열 대신 주민 등록 번호 열을 기본 키로 사용할 수 있습니다. 그러나 이 방법을 사용하는 경우 레코드를 식별하는 데 두 개 이상의 열이 필요하면 기본 키가 커질 수 있습니다. 또한 이와 같은 복합 키는 하나 이상의 외래 키 관계를 지원하도록 다른 테이블로 전파해야 합니다. 그리고 이러한 관계는 조인 성능을 저하시킵니다.
온라인 삽입
위에서 설명한 솔루션 중에 적합한 항목이 없으며 클라이언트에서 몇 번의 삽입 작업만을 수행하면 되는 경우에는 응용 프로그램이 서버에서 해당 행을 직접 삽입하도록 할 수도 있습니다. 그러면 새 행이 다운로드되어 다음 동기화 중에 클라이언트에서 삽입됩니다. 기본 키 값은 서버에서 생성되므로 기본 키 충돌은 발생하지 않습니다.