기본 키 마이그레이션 전략

이 문서에서는 부하 집중 문제를 방지하기 위해 데이터베이스 테이블에서 Spanner로 기본 키를 마이그레이션하는 전략을 설명합니다. 핫스팟은 단일 노드에 작업이 집중되는 현상으로, 전체 쓰기 부하를 Spanner 노드에 분산하는 이점을 활용하지 못하고 쓰기 처리량이 노드 용량으로 낮아집니다. 기본 키의 첫 번째 부분(예: 일반 시퀀스 또는 타임스탬프 포함)으로 단조롭게 증가하거나 감소하는 열을 사용하는 것이 핫스팟의 가장 일반적인 원인입니다.

전체 전략

Spanner에서 행을 2개 이상 저장해야 하는 모든 테이블은 하나 이상의 열을 가진 테이블로 구성된 기본 키가 있어야만 합니다. 테이블의 기본 키는 테이블의 각 행을 고유하게 식별하며 Spanner는 기본 키를 사용하여 테이블 행을 정렬합니다. Spanner는 고도로 분산되므로 다음 기법을 사용하여 고유한 기본 키 값을 생성함으로써 부하 집중의 위험을 줄일 수 있습니다.

Spanner가 지원하는 부하 집중 방지 자동 생성 키 기능 사용하기(자세한 내용은 자동 생성 키 마이그레이션 섹션 참조).
- GENERATE_UUID() 함수(Google SQL ,PostgreSQL)를 사용하여 STRING(36) 데이터 유형으로 범용 고유 식별자(UUID 버전 4) 값을 생성하기. RFC 4122는 UUID 버전 4 형식을 정의합니다.
- 비트 반전 양수 시퀀스(GoogleSQL, PostgreSQL) 사용하기. 이러한 시퀀스는 양의 64비트 숫자 공간에 고르게 분포되도록 이미 고차 비트의 양수 값을 생성합니다.
키 순서를 바꾸어 단조롭게 증가하거나 감소하는 값이 포함된 열이 첫 번째 키 부분이 되지 않게 하기
고유 키의 해시가 포함된 열을 만든 후 이 해시 열을(또는 이 해시 열과 고유 키 열을 함께) 기본 키로 사용하여 고유 키를 해시하고 쓰기를 논리적 샤드에 분산시키기. 이렇게 하면 새로운 행이 키 공간 전체에 보다 균일하게 분산되므로, 부하 집중을 방지할 수 있습니다.

테이블의 기본 키를 지정한 후에는 테이블을 삭제하고 다시 만들어야 나중에 기본 키를 변경할 수 있습니다. 기본 키 지정 방법에 대한 자세한 내용은 스키마 및 데이터 모델 - 기본 키를 참조하세요.

다음은 음악 트랙 데이터베이스에 대한 테이블을 만드는 DDL 문의 예입니다.

GoogleSQL

CREATE TABLE Singers (
  SingerId   INT64 NOT NULL,
  FirstName  STRING(1024),
  LastName   STRING(1024),
  SingerInfo BYTES(MAX),
  BirthDate  DATE,
) PRIMARY KEY(SingerId);

PostgreSQL

CREATE TABLE Singers (
  SingerId   bigint NOT NULL,
  FirstName  varchar(1024),
  LastName   varchar(1024),
  SingerInfo bytea,
  BirthDate  date,
  PRIMARY KEY(SingerId)
);

자동 생성 키 마이그레이션

이 섹션에서는 소스 테이블이 이미 자동 생성된 키 기능을 사용하는 다음 시나리오의 전략 및 예시를 설명합니다.

UUID 기본 키를 사용하는 소스 테이블에서 마이그레이션
순차적 자동 생성 정수 키를 사용하는 소스 테이블에서 마이그레이션. 여기에는 시퀀스(다양한 데이터베이스에서 지원), IDENTITY 열(다양한 데이터베이스에서 지원), PostgreSQL SERIAL 데이터 유형, MySQL AUTO_INCREMENT 열 속성 등이 포함됩니다.
비트 반전 키를 사용하는 소스 테이블에서 마이그레이션. 소스 데이터베이스가 Spanner일 수 있습니다. 이 경우 비트 반전 순차 값 가이드를 사용하여 키 값을 만듭니다.

모든 전략에서 Spanner는 소스 데이터베이스에서 마이그레이션하는 데이터를 변경하지 않는다는 점에 특히 유의하세요. 새 데이터를 생성하는 메서드만 변경합니다.

UUID 키 열 마이그레이션

소스 테이블에서 UUID 열을 사용하는 경우 열을 STRING 유형으로 변환하고 RFC 4122 사양에 따라 값을 소문자로 만들고 GENERATE_UUID() 함수(GoogleSQL, PostgreSQL)를 열 기본값으로 사용합니다. 예를 들면 다음과 같습니다.

GoogleSQL


CREATE TABLE UserAccessLog (
UserId     STRING(36) DEFAULT (GENERATE_UUID()),
...
) PRIMARY KEY (UserId);

PostgreSQL


CREATE TABLE UserAccessLog (
UserId     varchar(36) DEFAULT SPANNER.GENERATE_UUID(),
...
PRIMARY KEY (UserId)
);

순차적 키 열 마이그레이션

소스 데이터베이스 시스템이 키 열에 순차 값을 생성할 경우, Spanner 스키마에서 비트 반전 양수(GoogleSQL, PostgreSQL)를 사용하여 양의 64비트 정수 숫자 공간에 고르게 분포된 값을 생성할 수 있습니다. Spanner 시퀀스에서 마이그레이션된 값과 겹치는 값을 생성하지 않게 하려면 건너뛰기 범위를 정의하면 됩니다. 예를 들어 소스 데이터베이스에서 32비트 정수만 생성하는 경우 다음 두 시퀀스의 범위를 1에서 4,294,967,296(2^32)으로 건너뛸 수 있습니다.

GoogleSQL


CREATE SEQUENCE MyFirstSequence OPTIONS (
  sequence_kind = "bit_reversed_positive",
  skip_range_min = 1,
  skip_range_max = 4294967296
);

ALTER SEQUENCE MySecondSequence SET OPTIONS (
  skip_range_min = 1,
  skip_range_max = 4294967296
);

PostgreSQL


CREATE SEQUENCE MyFirstSequence BIT_REVERSED_POSITIVE
  SKIP RANGE 1 4294967296;

ALTER SEQUENCE MySecondSequence SKIP RANGE 1 4294967296;

비트 반전 키 열 마이그레이션

소스 데이터베이스에서 부하 집중 문제를 방지하기 위해 키 값을 이미 비트 반전한 경우 Spanner 비트 반전 포지티브 시퀀스(GoogleSQL, PostgreSQL)를 생성하여 이러한 값을 계속 생성할 수 있습니다. 중복 값이 생성되지 않도록 하려면 커스텀 번호에서 카운터를 시작하도록 시퀀스를 구성하면 됩니다.

예를 들어 기본 키 값을 생성하기 위해 1에서 1,000 사이의 숫자를 반전한 경우 Spanner 시퀀스는 10,000보다 큰 숫자에서 카운터를 시작할 수 있습니다. 선택적으로 데이터 마이그레이션 후에 소스 데이터베이스에서 발생하는 새 쓰기를 위한 버퍼를 남겨두기 위해 높은 숫자를 선택할 수 있습니다. 다음 예시에서 카운터는 11,000에서 시작합니다.

GoogleSQL


CREATE SEQUENCE MyFirstSequence OPTIONS (
  sequence_kind = "bit_reversed_positive",
  start_with_counter = 11000
);

ALTER SEQUENCE MySecondSequence SET OPTIONS (
  start_with_counter = 11000
);

PostgreSQL


CREATE SEQUENCE MyFirstSequence BIT_REVERSED_POSITIVE
  START COUNTER 11000;

ALTER SEQUENCE MySecondSequence RESTART COUNTER 11000;