소스 데이터베이스에서 Spanner로 스키마를 마이그레이션하려면 자동화 도구와 수동 분석 및 미세 조정을 결합하는 여러 단계의 프로세스가 필요합니다. 다음 단계는 권장되는 접근 방식을 간략하게 설명합니다.
스키마 추출: 소스 데이터베이스에서 스키마 정의(DDL)를 추출합니다.
초기 변환: 많은 기본 데이터 유형 매핑 및 구조 변환을 처리할 수 있는 자동 스키마 변환 도구(예: Spanner 마이그레이션 도구(SMT))를 사용하는 것을 고려해 볼 수 있습니다.
상세 스키마 검토 및 미세 조정: 모든 것을 한 번에 변경할 때의 위험성을 줄이기 위해 개별적으로 테스트하고 최적화할 수 있는 소규모의 신중한 변경을 통해 Spanner와 더 잘 호환되는 소스 데이터베이스 스키마를 변환하는 것을 고려하세요.
- 데이터 유형 매핑: SMT에서 생성한 데이터 유형 매핑을 검토하고 미세 조정합니다. Spanner 데이터 유형이 해당 소스 데이터베이스 유형의 범위, 정밀도, 시맨틱을 정확하게 나타내는지 확인합니다.
- 기본 키 및 인터리브 처리: Spanner의 인터리브 처리된 테이블을 사용하여 소스 데이터베이스 스키마에 존재하는 상위-하위 관계를 모델링할 수 있는 기회를 식별합니다. UUID 사용과 같은 Spanner에 적합한 기본 키 전략을 선택합니다. SMT를 사용하면 적절한 기본 키 전략을 선택할 수 있습니다. 데이터 지역 제어 및 부하 집중 방지에 미치는 영향을 고려하세요. 소스 데이터베이스에서 외래 키 제약조건이 사용되는 방식을 평가하고 Spanner에서 이를 처리하는 방법을 결정합니다. 자세한 내용은 상위-하위 테이블 관계를 참조하세요.
- 색인 최적화: 소스 데이터베이스의 기존 색인을 분석하고 Spanner 색인을 설계하여 쿼리 성능을 최적화하세요 자주 사용하지 않는 색인을 삭제하는 것이 좋습니다.
- 비호환성 삭제: Spanner에서 지원되지 않는 소스 데이터베이스의 특정 기능을 삭제하거나 재작성합니다. 예를 들어 Spanner는 저장 프로시저나 트리거를 지원하지 않습니다. 이 경우 애플리케이션 코드를 리팩터링해야 할 수 있습니다.
스키마 배포: Spanner 스키마를 개발 또는 스테이징 환경에 배포합니다.
반복 테스트 및 개선: 샘플 데이터를 로드하고 대표적인 애플리케이션 상호작용으로 스키마를 테스트합니다. 실적을 모니터링하고 개선이 필요한 영역을 파악합니다. 테스트 결과를 바탕으로 스키마를 미세 조정합니다. 스키마가 애플리케이션의 성능 및 기능 요구사항을 충족할 때까지 이 프로세스를 반복합니다.
스키마 검증: 소스 데이터베이스와 Spanner 스키마의 구조를 비교하여 변환이 올바르게 실행되었는지 확인하는 스크립트 또는 프로시저를 개발합니다.
최종 스키마 배포: 검증되고 미세 조정된 스키마를 Spanner 프로덕션 인스턴스에 배포합니다.
소스별 가이드
- MySQL: MySQL 스키마 마이그레이션