스키마 업데이트

Spanner를 사용하면 다운타임 없이 스키마 업데이트를 수행할 수 있습니다. 다음과 같은 여러 가지 방법으로 기존 데이터베이스의 스키마를 업데이트할 수 있습니다.

• Google Cloud Console 사용

  Spanner 스튜디오 페이지에서 ALTER TABLE 명령어를 제출합니다.

  Spanner 스튜디오 페이지에 액세스하려면 데이터베이스 개요 또는 테이블 개요 페이지에서 Spanner 스튜디오를 클릭합니다.

• gcloud spanner 명령줄 도구 사용

  gcloud spanner databases ddl update 명령어를 사용하여 ALTER TABLE 명령어를 제출합니다.

• 클라이언트 라이브러리 사용

• projects.instances.databases.updateDdl REST API 사용

• UpdateDatabaseDdl RPC API 사용

지원되는 스키마 업데이트

Spanner에서는 다음과 같은 기존 데이터베이스의 스키마를 업데이트할 수 있습니다.

• 새 테이블 만들기 새 테이블의 열은 NOT NULL일 수 있습니다.
• 테이블을 삭제합니다(테이블 내에 인터리브 처리된 다른 테이블이 없고 보조 색인이 없는 경우).
• 외래 키를 사용하여 테이블을 만들거나 삭제합니다.
• 기존 테이블에서 외래 키를 추가하거나 삭제합니다.
• 모든 테이블에 키 열이 아닌 열을 추가합니다. 새로운 키 열이 아닌 열은 NOT NULL일 수 없습니다.
• 모든 테이블에서 키 열이 아닌 열을 제거합니다(보조 색인, 외래 키, 저장된 생성 열 또는 확인 제약조건에 사용되는 열이 아닌 경우).
• ARRAY 열을 제외하고 키 열이 아닌 열에 NOT NULL을 추가합니다.
• 키 열이 아닌 열에서 NOT NULL을 삭제합니다.
• STRING 열을 BYTES 열로 변경하거나 BYTES 열을 STRING 열로 변경합니다.
• STRING 또는 BYTES 유형(MAX 포함)의 길이 제한을 늘리거나 줄입니다(하위 테이블 한 개 이상에 상속되는 기본 키 열이 아닌 경우).
• 값 열과 기본 키 열에서 커밋 타임스탬프를 사용 설정하거나 중지합니다.
• 보조 색인을 추가하거나 삭제합니다.
• 기존 테이블에서 확인 제약조건을 추가하거나 삭제합니다.
• 저장된 생성된 열을 기존 테이블에서 추가하거나 삭제합니다.
• 새 최적화 도구 통계 패키지를 작성합니다.

스키마 업데이트 성능

Spanner의 스키마 업데이트에는 다운타임이 필요 없습니다. Spanner 데이터베이스에 대해 일괄 DDL 문을 실행하면 Spanner에서 업데이트를 장기 실행 작업으로 적용하는 동안 중단 없이 데이터베이스에서 계속 쓰고 읽을 수 있습니다.

DDL 문을 실행하는 데 걸리는 시간은 업데이트에 기존 데이터 유효성 검사 또는 데이터 백필이 필요한지 여부에 따라 다릅니다. 예를 들어 기존 열에 NOT NULL 주석을 추가하는 경우 Spanner는 열의 모든 값을 읽어 열에 NULL 값이 없는지 확인해야 합니다. 유효성을 검사할 데이터가 많으면 이 단계에 오랜 시간이 걸릴 수 있습니다. 또 다른 예시는 데이터베이스에 색인을 추가하는 경우입니다. Spanner는 기존 데이터를 사용하여 색인을 백필하며 프로세스는 색인 정의와 해당 기본 테이블 크기에 따라 오래 걸릴 수 있습니다. 그러나 테이블에 새 열을 추가하면 유효성을 검사할 기존 데이터가 없으므로 Spanner에서 업데이트를 더욱 빠르게 수행할 수 있습니다.

요약하면 Spanner에서 기존 데이터 유효성을 검사할 필요가 없는 스키마 업데이트는 수분 내에 수행될 수 있습니다. 유효성 검사가 필요한 스키마 업데이트는 유효성을 검사해야 하는 기존 데이터 양에 따라 시간이 오래 걸릴 수 있지만 데이터 유효성 검사는 프로덕션 트래픽보다 낮은 우선 순위로 백그라운드에서 실행됩니다. 다음 섹션에서 데이터 유효성 검사가 필요한 스키마 업데이트를 보다 자세히 설명합니다.

뷰 정의에 대해 검증된 스키마 업데이트

스키마를 업데이트할 때 Spanner는 업데이트에서 기존 뷰를 정의하는 데 사용되는 쿼리를 무효화하지 않는지 확인합니다. 유효성 검사가 성공하면 스키마 업데이트가 성공합니다. 유효성 검사가 실패하면 스키마 업데이트가 실패합니다. 자세한 내용은 뷰 생성 시 권장사항을 참조하세요.

데이터 유효성 검사가 필요한 스키마 업데이트

기존 데이터가 새 제약 조건을 충족하는지 확인해야 하는 스키마 업데이트를 수행할 수 있습니다. 스키마 업데이트에 데이터 유효성 검사가 필요하면 Spanner는 영향을 받는 스키마 항목과 충돌하는 스키마 업데이트를 허용하지 않고 백그라운드에서 데이터 유효성을 검사합니다. 유효성 검사가 성공하면 스키마 업데이트가 성공합니다. 유효성 검사가 실패하면 스키마 업데이트가 실패합니다. 유효성 검사 작업은 장기 실행 작업으로 실행됩니다. 이러한 작업의 상태를 확인하여 작업 성공 또는 실패를 확인할 수 있습니다.

예를 들어 스키마에서 Songwriters 테이블을 정의했다고 가정합니다.

Google SQL

CREATE TABLE Songwriters (
  Id         INT64 NOT NULL,
  FirstName  STRING(1024),
  LastName   STRING(1024),
  Nickname   STRING(MAX),
  OpaqueData BYTES(MAX),
) PRIMARY KEY (Id);

다음 스키마 업데이트는 허용되지만 유효성 검사가 필요하며 기존 데이터 양에 따라 완료하는 데 시간이 오래 걸릴 수 있습니다.

• 키 열이 아닌 열에 NOT NULL 주석을 추가합니다. 예를 들면 다음과 같습니다.

  ALTER TABLE Songwriters ALTER COLUMN Nickname STRING(MAX) NOT NULL;
  

• 열의 길이를 줄입니다. 예를 들면 다음과 같습니다.

  ALTER TABLE Songwriters ALTER COLUMN FirstName STRING(10);
  

• BYTES에서 STRING으로 변경합니다. 예를 들면 다음과 같습니다.

  ALTER TABLE Songwriters ALTER COLUMN OpaqueData STRING(MAX);
  

• 기존 TIMESTAMP 열에 커밋 타임스탬프를 사용 설정합니다. 예를 들면 다음과 같습니다.

  ALTER TABLE Albums ALTER COLUMN LastUpdateTime SET OPTIONS (allow_commit_timestamp = true);
  

• 기존 테이블에 확인 제약조건 추가.

• 저장된 생성 열을 기존 테이블에 추가.

• 외래 키를 사용하여 새 테이블 만들기.

• 기존 테이블에 외래 키 추가.

기본 데이터가 새 제약 조건을 충족하지 않으면 이러한 스키마 업데이트는 실패합니다. 예를 들어 기존 데이터가 새 정의의 NOT NULL 제약 조건을 충족하지 않으므로 Nickname 열에 있는 값이 NULL이면 위의 ALTER TABLE Songwriters ALTER COLUMN Nickname STRING(MAX) NOT NULL 문이 실패합니다.

데이터 유효성 검사는 몇 분에서 몇 시간까지 걸릴 수 있습니다. 데이터 유효성 검사를 완료하는 데 걸리는 시간은 다음에 따라 다릅니다.

• 데이터 세트 크기
• 인스턴스의 컴퓨팅 용량
• 인스턴스의 부하

일부 스키마 업데이트의 경우 스키마 업데이트가 완료되기 전에 데이터베이스에 대한 요청 동작이 변경될 수 있습니다. 예를 들어 열 하나에 NOT NULL을 추가하면 Spanner는 거의 즉각적으로 열의 NULL을 사용하는 새 요청에 대한 쓰기를 거부합니다. 새 스키마 업데이트가 결국 데이터 유효성 검사에 실패하면 이전 스키마에서 허용되었던 쓰기 작업이라도 일정 기간 동안 쓰기가 차단됩니다.

projects.instances.databases.operations.cancel 메서드 또는 gcloud spanner operations를 사용하여 장기 실행 데이터 유효성 검사 작업을 취소할 수 있습니다.

일괄 처리 시 문 실행 순서

Google Cloud CLI, REST API 또는 RPC API를 사용하는 경우 CREATE, ALTER 또는 DROP 문 하나 이상을 일괄 실행할 수 있습니다.

Spanner는 동일한 배치의 문을 순서대로 적용하고 첫 번째 오류에서 중지합니다. 구문 적용 시 오류가 발생하면 해당 국문은 롤백됩니다. 배치에서 이전에 적용된 문의 결과는 롤백되지 않습니다.

Spanner는 여러 배치의 문을 결합하고 재정렬하므로 여러 배치의 문을 데이터베이스에 적용되는 원자적 변경사항 하나에 혼합할 수 있습니다. 각 원자적 변경사항 내에서 서로 다른 배치에 포함된 문은 임의의 순서로 발생합니다. 예를 들어 문 배치 하나에 ALTER TABLE MyTable ALTER COLUMN MyColumn STRING(50)이 포함되어 있고 또 다른 문 배치에 ALTER TABLE MyTable ALTER COLUMN MyColumn STRING(20)이 포함되어 있는 경우 Spanner는 이러한 두 열 중 하나에서 해당 열을 그대로 두지만 특정 상태를 지정하지는 않습니다.

스키마 업데이트 중에 생성되는 스키마 버전

Spanner는 스키마 버전 관리를 사용하므로 스키마를 대규모 데이터베이스로 업데이트하는 동안에는 다운타임이 발생하지 않습니다. Spanner는 스키마 업데이트가 처리되는 동안 읽기를 지원하도록 이전 스키마 버전을 유지합니다. 그런 다음 Spanner는 새 스키마 버전을 하나 이상 만들어 스키마 업데이트를 처리합니다. 각 버전에는 위에 설명된 것처럼 단일한 원자적 변경사항을 구성하는 문 모음의 결과가 포함됩니다.

스키마 버전은 DDL 문 배치 또는 개별 DDL 문과 반드시 일대일로 대응하지는 않습니다. 기존 기본 테이블의 색인 생성 또는 데이터 유효성 검사가 필요한 문과 같은 일부 개별 DDL 문의 경우 스키마 버전이 여러 개 생성됩니다. 다른 경우에는 몇 개의 DDL 문이 단일 버전에서 함께 일괄 처리될 수 있습니다. 이전 스키마 버전은 서버 및 스토리지 리소스를 상당히 소비할 수 있으며, 만료될 때까지 보관됩니다(이전 버전의 데이터를 읽을 필요가 없음).

참고: 여러 색인 추가에 대한 자세한 내용은 대규모 업데이트 옵션을 참조하세요.

다음 표에서는 Spanner에서 스키마를 업데이트하는 데 걸리는 시간을 보여줍니다.

스키마 작업	예상 기간
CREATE TABLE	분
CREATE INDEX	색인 전에 기본 테이블이 생성되는 경우 수 분에서 수 시간 해당 문이 기본 테이블의 CREATE TABLE 문과 동시에 실행되는 경우 수 분
DROP TABLE	분
DROP INDEX	분
ALTER TABLE ... ADD COLUMN	분
ALTER TABLE ... ALTER COLUMN	백그라운드 유효성 검사가 필요한 경우 수 분에서 수 시간 백그라운드 유효성 검사가 필요하지 않은 경우 수 분
ALTER TABLE ... DROP COLUMN	분
ANALYZE	데이터베이스 크기에 따라 수 분에서 수 시간까지

데이터 유형 변경사항 및 변경 내역

변경 스트림으로 감시되는 열의 데이터 유형을 변경하면 레코드의 mods 필드 내에서 old_values JSON 데이터에 수행되는 것처럼 관련 후속 변경 스트림 레코드의 column_types 필드에 새 유형이 반영됩니다.

변경 스트림 레코드의 mods 필드의 new_values는 항상 열의 현재 유형과 일치합니다. 감시된 열의 데이터 유형을 변경해도 이 변경 앞에 수행된 모든 변경 스트림 레코드에는 영향을 주지 않습니다.

BYTES-STRING 변경과 같은 특정 사례에서 Spanner는 스키마를 업데이트할 때 열의 이전 값을 검증합니다. 따라서 Spanner는 이후 변경 스트림 레코드를 기록하는 시간에 이전 BYTES 유형 값을 문자열로 안전하게 디코딩했습니다.

스키마 업데이트 권장사항

다음 섹션에서는 스키마 업데이트 권장사항을 설명합니다.

스키마 업데이트 실행 전 절차

스키마 업데이트를 실행하기 전에 다음을 수행해야 합니다.

• 변경하려는 데이터베이스의 모든 기존 데이터가 스키마 업데이트에 필요한 제약 조건을 충족하는지 확인합니다. 일부 유형의 스키마 업데이트는 현재 스키마뿐만 아니라 데이터베이스의 데이터에 따라서도 성공 여부가 달라지기 때문에 테스트 데이터베이스의 스키마 업데이트에 성공하더라도 프로덕션 데이터베이스의 스키마 업데이트에는 성공하지 못할 수도 있습니다. 다음은 일반적인 몇 가지 예시입니다.

  • 기존 열에 NOT NULL 주석을 추가하는 경우 열에 기존 NULL 값이 없는지 확인합니다.
  • STRING 또는 BYTES 열의 허용 길이를 줄이는 경우, 해당 열에서 기존의 모든 값이 원하는 길이 제약 조건을 충족하는지 확인합니다.

• 스키마 업데이트 중인 열, 테이블 또는 색인에 대해 쓰기를 수행할 경우 쓰는 값이 새 제약 조건을 충족하는지 확인해야 합니다.

• 열, 테이블 또는 색인을 삭제하는 경우 삭제한 열, 테이블 또는 색인에서 계속 읽거나 쓰지 않도록 해야 합니다.

스키마 업데이트의 실행 빈도 제한

단기간에 지나치게 많은 스키마 업데이트를 수행하면 Spanner는 큐에 추가된 스키마 업데이트 처리를 throttle할 수 있습니다. 이는 Spanner가 스키마 버전을 저장할 공간 양을 제한하기 때문입니다. 보관 기간 내에 오래된 스키마 버전이 지나치게 많으면 스키마 업데이트가 제한될 수 있습니다. 최대 스키마 변경 비율은 데이터베이스의 총 열 수를 비롯한 많은 요소에 따라 달라집니다. 예를 들어 2,000개의 열(INFORMATION_SCHEMA.COLUMNS에 대략 2,000개 행)이 있는 데이터베이스는 보관 기간 내에 최대 1500개의 간단한 스키마 변경을 수행할 수 있습니다(스키마 변경 시 여러 버전이 필요한 경우 더 적음). 진행 중인 스키마 업데이트의 상태를 보려면 gcloud spanner operations list 명령어를 사용하고 DATABASE_UPDATE_DDL 유형의 작업으로 필터링합니다. 진행 중인 스키마 업데이트를 취소하려면 gcloud spanner operations cancel 명령어를 사용하고 작업 ID를 지정합니다.

DDL 문이 일괄 처리되는 방식과 각 일괄 처리 내의 순서는 결과 스키마 버전 수에 영향을 미칠 수 있습니다. 일정 기간 동안 수행할 수 있는 스키마 업데이트 수를 극대화하려면 스키마 버전 수를 최소화하는 일괄 처리를 사용해야 합니다. 일부 원칙은 대규모 업데이트에 설명되어 있습니다.

스키마 버전에 설명된 대로 일부 DDL 문은 여러 스키마 버전을 생성하며, 이러한 버전은 각 배치 내의 일괄 처리 및 순서를 고려할 때 중요합니다. 여러 스키마 버전을 만들 수 있는 문 유형에는 다음과 같은 두 가지 주요 유형이 있습니다.

• CREATE INDEX와 같이 색인 데이터를 백필해야 할 수 있는 문
• NOT NULL 추가와 같이 기존 데이터를 검증해야 할 수 있는 문

하지만 이러한 유형의 문이 항상 여러 스키마 버전을 만드는 것은 아닙니다. Spanner는 일괄 처리의 영향을 받는 여러 스키마 버전 사용을 방지하도록 이러한 유형의 문을 최적화할 수 있는 시기를 감지하려고 합니다. 예를 들어 다른 테이블의 개입 문 없이 색인의 기본 테이블의 CREATE TABLE 문과 동일한 배치에서 발생하는 CREATE INDEX 문은 색인 데이터를 백필할 필요가 없습니다. Spanner는 색인이 생성될 때 기본 테이블이 비어 있다고 보장할 수 있기 때문입니다. 대규모 업데이트 섹션에서는 이 속성을 사용하여 여러 색인을 효율적으로 만드는 방법을 설명합니다.

여러 스키마 버전을 만들지 않도록 DDL 문을 일괄 처리할 수 없는 경우 보관 기간 내에 단일 데이터베이스의 스키마에 대해 스키마 업데이트 수를 제한해야 합니다. 새 버전이 생성되기 전에 Spanner에서 이전 버전의 스키마를 삭제할 수 있도록 스키마 업데이트 기간을 늘립니다.

• 일부 관계형 데이터베이스 관리 시스템의 경우, 프로덕션 배포 시마다 데이터베이스에 대해 끊임없이 일련의 업그레이드와 다운그레이드 스키마 업데이트를 수행하는 소프트웨어 패키지가 있습니다. 이러한 유형의 프로세스는 Spanner에 권장되지 않습니다.
• Spanner는 기본 키를 사용하여 멀티테넌시 솔루션의 데이터 파티션을 나누도록 최적화되어 있습니다. 각 고객에 대해 별도의 테이블을 사용하는 멀티테넌시 지원 솔루션으로 인해 완료 시간이 긴 대량의 스키마 업데이트 작업 백로그가 발생할 수 있습니다.
• 각 문이 내부적으로 여러 버전의 스키마를 생성하므로, 유효성 검사 또는 색인 백필이 필요한 스키마 업데이트는 더 많은 서버 리소스를 사용합니다.

대규모 스키마 업데이트를 위한 옵션

테이블과 해당 테이블에서 대규모 색인을 만드는 가장 좋은 방법은 모든 색인을 동시에 만들어 단일 스키마 버전만 만드는 것입니다. DDL 문 목록의 테이블 바로 다음에 색인을 만드는 것이 좋습니다. 데이터베이스를 생성하거나 문의 단일 대규모 일괄 처리에서 테이블과 해당 색인을 만들 수 있습니다. 각각 많은 색인이 있는 테이블을 여러 개 만들어야 하는 경우 모든 문을 단일 배치로 포함할 수 있습니다. 단일 스키마 버전을 사용하여 모든 문을 함께 실행할 수 있는 경우 단일 배치에 수천 개의 문을 포함할 수 있습니다.

문에서 색인 데이터를 백필하거나 데이터 유효성 검사를 수행해야 하는 경우 단일 스키마 버전으로 실행할 수 없습니다. 이는 색인의 기본 테이블이 이미 존재하는 경우 CREATE INDEX 문에 대해 발생합니다. 이전 DDL 문의 배치에서 생성되었거나 여러 스키마 버전이 필요한 CREATE TABLE 및 CREATE INDEX 문 사이의 배치에 명령문이 있었기 때문입니다. Spanner에서는 단일 배치에 이러한 문이 10개 이하여야 합니다. 특히 백필이 필요한 색인 생성은 색인당 여러 스키마 버전을 사용하므로, 하루에 백필이 필요한 새 색인을 3개 이하로 만드는 것이 좋습니다. 일괄 처리의 경우 백필을 피할 수 없는 경우가 이에 해당합니다.

예를 들어 이 문의 배치는 단일 스키마 버전을 사용합니다.

Google SQL

CREATE TABLE Singers (
SingerId   INT64 NOT NULL,
FirstName  STRING(1024),
LastName   STRING(1024),
) PRIMARY KEY (SingerId);

CREATE INDEX SingersByFirstName ON Singers(FirstName);

CREATE INDEX SingersByLastName ON Singers(LastName);

CREATE TABLE Albums (
SingerId   INT64 NOT NULL,
AlbumId    INT64 NOT NULL,
AlbumTitle STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId);

CREATE INDEX AlbumsByTitle ON Albums(AlbumTitle);

반대로 이 배치에서는 여러 스키마 버전을 사용합니다. 그 이유는 UnrelatedIndex에 기본 테이블이 이미 있어야 하므로 백필이 필요하며 다음 모든 색인에서는 백필이 필요합니다(기본 테이블과 동일한 배치에 있는 경우 포함).

Google SQL

CREATE TABLE Singers (
SingerId   INT64 NOT NULL,
FirstName  STRING(1024),
LastName   STRING(1024),
) PRIMARY KEY (SingerId);

CREATE TABLE Albums (
SingerId   INT64 NOT NULL,
AlbumId    INT64 NOT NULL,
AlbumTitle STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId);

CREATE INDEX UnrelatedIndex ON UnrelatedTable(UnrelatedIndexKey);

CREATE INDEX SingersByFirstName ON Singers(FirstName);

CREATE INDEX SingersByLastName ON Singers(LastName);

CREATE INDEX AlbumsByTitle ON Albums(AlbumTitle);

스키마 버전을 최소화하려면 UnrelatedIndex 생성을 해당 배치의 끝이나 다른 배치로 이동하는 것이 좋습니다.

API 요청이 완료될 때까지 대기

projects.instances.databases.updateDdl(REST API) 또는 UpdateDatabaseDdl(RPC API) 요청을 실행하는 경우, 각각 projects.instances.databases.operations.get(REST API) 또는 GetOperation(RPC API)을 사용하여 각 요청이 완료될 때까지 기다린 후 새 요청을 시작합니다. 각 요청이 완료되기를 기다리면 애플리케이션에서 스키마 업데이트의 진행 상황을 추적할 수 있습니다. 그러면 대기 중인 스키마 업데이트의 백로그를 관리 가능한 크기로 유지할 수도 있습니다.

일괄 로드

테이블 작성 후 테이블에 데이터를 일괄 로드하는 경우, 데이터가 로드된 후 색인을 작성하는 것이 일반적으로 더 효율적입니다. 여러 색인을 추가하는 경우 대규모 업데이트 옵션에서 설명한 대로 초기 스키마의 모든 테이블과 색인을 사용하여 데이터베이스를 생성하는 것이 더 효율적일 수 있습니다.