PostgreSQL에서 Spanner로 마이그레이션(PostgreSQL 언어)

이 페이지에서는 오픈소스 PostgreSQL 데이터베이스(지금부터 PostgreSQL이라고 함)를 Spanner PostgreSQL 언어 데이터베이스(지금부터 Spanner)로 마이그레이션하는 방법을 설명합니다.

Spanner 및 GoogleSQL 언어로의 마이그레이션에 대한 자세한 내용은 PostgreSQL에서 Spanner로 마이그레이션(GoogleSQL 언어)을 참조하세요.

마이그레이션 제약조건

Spanner는 특정 개념을 다른 엔터프라이즈 데이터베이스 관리 도구와 다르게 사용하므로 기능을 최대한 활용하려면 애플리케이션의 아키텍처를 조정해야 할 수 있습니다. 또한 요구사항을 충족하기 위해 Google Cloud의 다른 서비스로 Spanner를 보완해야 할 수도 있습니다.

저장 프로시저 및 트리거

Spanner는 데이터베이스 수준에서 사용자 코드 실행을 지원하지 않으므로, 마이그레이션의 일환으로 데이터베이스 수준 저장 프로시저 및 트리거로 구현된 비즈니스 로직을 애플리케이션으로 이동해야 합니다.

시퀀스

Spanner에서는 UUID 버전 4를 기본 방법으로 사용하여 기본 키 값을 생성하는 것이 좋습니다. GENERATE_UUID() 함수(GoogleSQL, PostgreSQL)는 STRING 유형으로 표시되는 UUID 버전 4 값을 반환합니다.

정수 값을 생성해야 하는 경우 Spanner는 비트 반전 포지티브 시퀀스(GoogleSQL, PostgreSQL)를 지원하며, 이러한 시퀀스는 양의 64비트 숫자 공간에 균등하게 분산되는 값을 생성합니다. 부하 집중 문제를 방지하기 위해 이러한 수치를 사용할 수 있습니다.

자세한 내용은 기본 키 기본값 전략을 참조하세요.

액세스 제어

Spanner에서는 테이블 및 열 수준에서 세분화된 액세스 제어를 지원합니다. 뷰에 대한 세분화된 액세스 제어는 지원되지 않습니다. 자세한 내용은 세분화된 액세스 제어 정보를 참조하세요.

이전 프로세스

마이그레이션에는 다음 작업이 포함됩니다.

• PostgreSQL 스키마를 Spanner 매핑
• SQL 쿼리 변환
• Spanner 인스턴스, 데이터베이스, 스키마 만들기
• Spanner 데이터베이스를 사용하도록 애플리케이션 리팩터링
• 데이터 마이그레이션
• 새 시스템을 확인하여 프로덕션 상태로 전환

1단계: PostgreSQL 스키마를 Spanner에 매핑

데이터베이스를 오픈소스 PostgreSQL에서 Spanner로 전환하는 첫 단계는 스키마에서 변경해야 하는 사항을 결정하는 것입니다.

기본 키

Spanner에서 행을 2개 이상 저장해야 하는 모든 테이블은 하나 이상의 열을 가진 테이블로 구성된 기본 키가 있어야만 합니다. 테이블의 기본 키는 테이블에 있는 각 행을 고유하게 식별하고 Spanner는 기본 키를 사용해서 테이블 행을 정렬합니다. Spanner는 고도로 분산되어 있으므로 데이터 증가에 맞춰 확장되는 기본 키 생성 기술을 선택하는 것이 중요합니다. 자세한 내용은 기본 키 마이그레이션 전략을 참조하세요.

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

색인

PostgreSQL b-tree 색인은 Spanner의 보조 색인과 유사합니다. Spanner 데이터베이스에서 보조 색인으로 일반적으로 자주 검색되는 열의 색인을 생성해 성능을 개선하고 테이블에 지정된 모든 UNIQUE 제약조건을 대체합니다. 예를 들어 PostgreSQL DDL에 다음 문이 있는 경우

 CREATE TABLE customer (
    id CHAR (5) PRIMARY KEY,
    first_name VARCHAR (50),
    last_name VARCHAR (50),
    email VARCHAR (50) UNIQUE
 );

Spanner DDL에서 이 문을 사용합니다.

CREATE TABLE customer (
   id VARCHAR(5) PRIMARY KEY,
   first_name VARCHAR(50),
   last_name VARCHAR(50),
   email VARCHAR(50)
   );

CREATE UNIQUE INDEX customer_emails ON customer(email);

psql에서 \di 메타 명령어를 실행하면 PostgreSQL 테이블에 대한 색인을 찾을 수 있습니다.

필요한 색인을 결정한 후 CREATE INDEX 문을 추가하여 색인을 만듭니다. 보조 색인의 안내를 따르세요.

Spanner는 색인을 테이블로 구현하므로 단조롭게 증가하는 열(예: TIMESTAMP 데이터가 있는 열)의 색인을 생성하면 부하 집중이 발생할 수 있습니다. 부하 집중을 피하는 방법에 대한 자세한 내용은 Spanner에 대해 DBA가 알아야 하는 것-파트1: 키와 색인를 참조하세요.

Spanner는 테이블과 동일한 방식으로 보조 색인을 구현하므로, 색인 키로 사용할 열 값에는 테이블의 기본 키와 동일한 제약조건이 있습니다. 이는 또한 색인의 일관성이 Spanner 테이블과 동일하게 보장됨을 의미합니다.

보조 색인을 사용한 값 조회는 테이블 조인을 사용하는 쿼리와 실제로 동일합니다. INCLUDE 절을 사용하여 보조 색인에 원래 테이블의 열 값을 복사하여 저장함으로써 커버링 색인을 만들 수 있으므로, 색인을 사용하여 쿼리 성능을 향상시킬 수 있습니다.

Spanner의 쿼리 최적화 도구는 색인 자체가 쿼리되는 모든 열을 저장하고 있는 경우에만(적용되는 쿼리) 보조 색인을 자동으로 사용합니다. 원래 테이블의 열 쿼리 시 색인을 사용하게 만들려면 SQL 문에서 FORCE INDEX 지시문을 사용해야 합니다. 예를 들면 다음과 같습니다.

SELECT *
FROM MyTable /*@ FORCE_INDEX=MyTableIndex */
WHERE IndexedColumn=$1;

다음은 Albums 테이블에 대한 보조 색인을 만드는 DDL 문의 예입니다.

CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);

데이터가 로드된 후에 추가 색인을 만들면 색인을 채우는데 다소 시간이 걸릴 수 있습니다. 추가 속도를 하루에 평균 3회로 제한하는 것이 좋습니다. 보조 색인 만들기에 대한 자세한 내용은 보조 색인을 참조하세요. 색인 생성 시 제한사항에 대한 자세한 내용은 스키마 업데이트를 참조하세요.

뷰

Spanner 뷰는 읽기 전용입니다. 데이터 삽입, 업데이트, 삭제에는 뷰를 사용할 수 없습니다. 자세한 내용은 뷰를 참조하세요.

생성된 열

Spanner는 생성된 열을 지원합니다. 문법 차이와 제한사항은 생성된 열 만들기 및 관리를 참조하세요.

테이블 인터리브 처리

Spanner에는 테이블 2개를 일대다 상위-하위 관계로 정의할 수 있는 기능이 있습니다. 이 기능은 스토리지의 상위 행 옆에 있는 하위 데이터 행을 인터리브 처리하므로, 상위 테이블과 하위 테이블을 함께 쿼리하면 테이블이 미리 효과적으로 결합되어 데이터 검색 효율성이 향상됩니다.

하위 테이블의 기본 키는 상위 테이블의 기본 키 열로 시작해야 합니다. 하위 행에서 볼 때 상위 행의 기본 키는 외래 키입니다. 상위-하위 관계를 최대 6단계까지 정의할 수 있습니다.

하위 테이블에 대한 ON DELETE 작업을 정의하여 상위 행이 삭제되면 수행할 작업을 결정할 수 있습니다. 즉, 모든 하위 행을 삭제하거나 하위 행이 존재하는 동안에 상위 행 삭제를 차단할 수 있습니다.

다음은 앞에서 정의한 상위 Singers 테이블에 인터리브 처리된 Albums 테이블을 만드는 예입니다.

CREATE TABLE Albums (
 SingerID      bigint,
 AlbumID       bigint,
 AlbumTitle    varchar,
 PRIMARY KEY (SingerID, AlbumID)
 )
 INTERLEAVE IN PARENT Singers ON DELETE CASCADE;

자세한 내용은 인터리브 처리된 테이블 만들기를 참조하세요.

데이터 유형

다음 표에는 Spanner용 PostgreSQL 인터페이스가 지원하지 않는 오픈소스 PostgreSQL 데이터 유형이 나와 있습니다.

참고: HarbourBridge는 대신 사용하세요. 열에 나열된 일부 변환을 자동으로 수행할 수 있습니다. 자세한 내용은 HarbourBridge: Spanner 평가 및 마이그레이션을 참조하세요.

데이터 유형	대신 사용하세요.
bigserial,serial8	bigint, int8
bit [ (n) ]	-
bit varying [ (n) ], varbit [ (n) ]	-
box	-
character [ (n) ], char [ (n) ]	character varying
cidr	text
circle	-
inet	text
integer, int4	bigint, int8
interval [fields] [ (p) ]	bigint
json	jsonb
line	-
lseg	-
macaddr	text
money	numeric, decimal
path	-
pg_lsn	-
point	-
polygon	-
realfloat4	double precision, float8
smallint, int2	bigint, int8
smallserial, serial2	bigint, int8
serial, serial4	bigint, int8
time [ (p) ] [ 시간대 제외 ]	text, HH:MM:SS.sss 표기법 사용
time [ (p) ] (시간 zonetimetz 포함)	text, HH:MM:SS.sss+ZZZZ 표기법 사용. 또는 두 개의 열 사용.
timestamp [ (p) ] [ 시간대 제외 ]	text 또는 timestamptz
tsquery	-
tsvector	-
txid_snapshot	-
uuid	text 또는 bytea
xml	text

2단계: 모든 SQL 쿼리 변환

Spanner에는 변환 부담을 줄이는 데 도움이 되는 여러 오픈소스 PostgreSQL 함수가 있습니다.

Google Cloud 콘솔의 Spanner 스튜디오 페이지에서 SQL 쿼리를 프로파일링하여 쿼리를 실행할 수 있습니다. 일반적으로 큰 테이블에 전체 테이블 검색을 수행하는 쿼리의 비용이 비싸므로 아껴서 사용해야 합니다. SQL 쿼리 최적화에 대한 자세한 내용은 SQL 권장사항 문서를 참조하세요.

3단계: Spanner 인스턴스, 데이터베이스, 스키마 만들기

PostgreSQL 언어로 인스턴스를 만들고 데이터베이스를 만듭니다. 그런 다음 PostgreSQL 데이터 정의 언어(DDL)를 사용하여 스키마를 만듭니다.

pg_dump를 사용하여 PostgreSQL 데이터베이스의 객체를 정의하는 DDL 문을 작성한 후 다음 섹션에 기술된 대로 문을 수정하세요. DDL 문을 업데이트한 후 이 DDL 문을 사용하여 Spanner 인스턴스에 데이터베이스를 만듭니다.

자세한 내용은 다음을 참고하세요.

• 인스턴스 만들기 및 관리
• 데이터베이스 생성 및 관리
• 스키마 정보

4단계: 애플리케이션 리팩터링

수정된 스키마 및 수정된 SQL 쿼리를 설명하고 프로시저 및 트리거와 같은 데이터베이스 상주 로직을 대체하는 애플리케이션 로직을 추가합니다.

5단계: 데이터 이전하기

데이터를 마이그레이션하는 방법에는 2가지가 있습니다.

• Harbourbridge 사용

  Harbourbridge는 스키마 및 데이터 마이그레이션을 모두 지원합니다. pg_dump 파일 또는 CSV 파일을 가져오거나 오픈소스 PostgreSQL 데이터베이스에 대한 직접 연결을 통해 가져올 수 있습니다.

• COPY FROM STDIN 명령어 사용

  자세한 내용은 데이터를 가져오기 위한 COPY 명령어를 참조하세요.