이 페이지에서는 Relational Migrator 데이터 마이그레이션 벤치마크 결과를 설명하고 해당 결과를 기반으로 한 권장 사항을 제공합니다. 결과 및 권장 사항을 사용하여 마이그레이션 일정을 예상하고, 적절한 인프라 구성을 선택하고, 관계형에서 MongoDB 로의 마이그레이션 위한 리소스 요구 사항을 계획할 수 있습니다.
벤치마크 개요
Relational Migrator 벤치마크는 다음 요인을 기반으로 마이그레이션 성능을 측정했습니다.
스키마 매핑 복잡성
관계형 데이터베이스 크기
관계형 데이터베이스 저장 유형
Relational Migrator 인스턴스 구성
MongoDB Atlas 구성
벤치마크는 MongoDB Atlas 와 AWS 인프라를 사용했습니다. 그러나 성능 패턴과 권장 사항은 다른 클라우드 공급자들과 온프레미스 배포서버들에 광범위 적용. 벤치마크에 사용된 인프라에 대해 자세히 학습 벤치마크 구성을참조하세요.
스키마 매핑 복잡성
Relational Migrator 사용하면 관계형 스키마 document model 로 변환할 수 있습니다. 다음 용어는 벤치마크에서 사용되는 다양한 MongoDB 스키마 매핑 복잡성을 설명합니다.
복잡성 수준 | 설명 |
|---|---|
일대일 | 관계형 스키마 와 일치하는 MongoDB 스키마 : 각 테이블은 단일 MongoDB 컬렉션 에 매핑되고 각 행은 단일 문서 에 매핑됩니다. 고급 기능의 사용을 최소화합니다. |
임베디드 매핑 | 내장된 배열 또는 내장된 문서를 포함하는 MongoDB 스키마 입니다. 중첩된 문서는 최대 2단계까지 가능합니다. |
고급 | 마이그레이션 시간을 늘릴 수 있는 여러 고급 기능을 사용하는 MongoDB 스키마 입니다. 고급 기능의 몇 가지 예는 다음과 같습니다.
고급 스키마 에는 최대 3개의 중첩된 문서 수준이 있습니다. |
관계형 데이터를 MongoDB 스키마에 매핑하는 방법에 대해 자세히 학습하려면 데이터 모델링을 참조하세요.
벤치마크 구성
다음 표에서는 벤치마크 테스트에 사용된 각 구성 요소의 구성에 대해 설명합니다.
구성 요소 | 구성 |
|---|---|
소스 데이터베이스(Oracle) |
Oracle 인스턴스 격리되었으며 Relational Migrator 인스턴스 에서만 트래픽을 수신했습니다. |
Relational Migrator |
|
대상 데이터베이스(MongoDB Atlas) |
|
벤치마크 결과
다음 표는 벤치마크 테스트의 결과를 보여줍니다. 벤치마크에서는 Atlas UI 또는 mongostat 를 사용하여 문서 지표 모니터 . Average Throughput (MB/s) 열은 소수점 둘째 자리에서 반올림됩니다. Cluster Documents/s 열은 초당 가장 가까운 1만 문서로 반올림됩니다. 장기 실행 One-to-one 마이그레이션의 경우 Cluster Documents/s 열은 벤치마크 중 속도 변화로 인해 관찰된 하한과 상한을 제공합니다.
참고
Oracle 데이터베이스 벤치마크 테스트에서 상당한 CPU 또는 RAM 사용량을 보이지 않았습니다.
데이터베이스 크기 | 매핑 복잡성 | Oracle RDS 저장 유형 | Atlas 클러스터 계층 | 마이그레이션 기간 | 평균 처리량(MB/s) | 클러스터 문서/초 |
|---|---|---|---|---|---|---|
10GB | 일대일 | gp2 | M60 | 15 분 | 11.11 | 80,000 (insert) |
10GB | 임베디드 매핑 | gp2 | M60 | 37 분 | 4.50 | 80,000 (insert), 40,000 (update) |
10GB | 고급 | gp2 | M60 | 47 분 | 3.55 | 90,000 (insert), 40,000 (update) |
100 GB | 일대일 | gp3 | M60 | 2 시간 31 분 | 11.04 | 80,000 ~ 100,000 (삽입) |
100 GB | 임베디드 매핑 | gp3 | M80 | 16 시간 25 분 | 1.69 | 90,000 (insert), 40,000 (update) |
100 GB | 고급 | gp3 | M140 | 15 시간 47 분 | 1.76 | 90,000 (insert), 40,000 (update) |
1 TB | 일대일 | IOPS SSD | M60 | 30 시간 50 분 | 9.01 | 85,000 ~ 100,000 (삽입) |
Relational Migrator 항상 루트 문서를 쓰기 (write) 위한 일련의 insert 작업으로 시작합니다. 그런 다음 update 연산을 사용하여 내장된 문서 또는 내장된 배열을 삽입합니다. 결과적으로 One-to-one 벤치마크 결과에는 삽입 작업만 포함되고 Embedded Mappings 및 Advanced 결과에는 삽입 및 업데이트 작업이 모두 포함됩니다.
성능 추정치
벤치마크 결과에 따르면 Relational Migrator 다음과 같이 마이그레이션 할 수 있습니다.
일대일 스키마의 경우 시간당21 GB.
최대 2단계의 내장된 매핑이 있는 스키마의 경우 시간당7 GB 입니다.
일대일 스키마의 데이터베이스 마이그레이션 속도는 거의 선형입니다. 예시 들어, 일대일 100 GB 마이그레이션 일대일 10 GB 마이그레이션 보다 약 10 시간이 걸립니다.
더 복잡한 스키마의 마이그레이션 속도는 데이터베이스 크기에 선형적으로 확장하다 하지 않습니다. 스키마 에 내장된 문서, 내장된 배열 및 기타 기능이 많을수록 마이그레이션 속도가 느려집니다.
권장 사항
권장 구성
다음 표에는 소스 데이터베이스 크기 및 매핑 복잡성에 따라 권장되는 Atlas 클러스터 계층 및 AWS RDS 저장 유형이 나와 있습니다.
소스 데이터 세트 크기 | 매핑 복잡성 | 권장 Atlas 클러스터 계층 | 권장 AWS RDS 저장 유형 |
|---|---|---|---|
0-50 GB | 일대일 | M60 | gp2 |
0-50 GB | 임베디드 매핑 | M60 | gp2 |
0-50 GB | 고급 | M60 | gp2 |
50 GB-300 GB | 일대일 | M60 | gp3 |
50 GB-300 GB | 임베디드 매핑 | M80 | gp3 |
50 GB-300 GB | 고급 | M80 | gp3 |
300 GB-1 TB | 일대일 | M60 | gp3 |
300 GB-1 TB | 임베디드 매핑 | M140 | IOPS SSD |
300 GB-1 TB | 고급 | M140 | IOPS SSD |
1 TB+ | 일대일 | M60 | IOPS SSD |
1 TB+ | 임베디드 매핑 | M200 | IOPS SSD |
1 TB+ | 고급 | M200 | IOPS SSD |
이 표에는 MongoDB Atlas 및 AWS RDS 구성이 명시되어 있지만, 이러한 권장 사항을 다른 클라우드 공급자 및 자체 관리형 배포에 적용 할 수 있습니다. 특정 MongoDB Atlas cluster 계층 과 관련된 인프라 구성에 대해 자세히 학습 보려면 클라우드 공급자를 참조하세요. AWS RDS 저장 유형에 대해 자세히 학습 보려면 AWS RDS 저장 유형 문서를 참조하세요.
네트워크 지연 시간 최적화
네트워크 지연 시간 최소화하려면 소스 데이터베이스, Relational Migrator 및 대상 클러스터 동일한 데이터 센터 에서 실행 중인지 확인합니다.
병목 현상 모니터
마이그레이션 성능을 최적화하려면 지표 모니터 성능 병목 현상을 식별합니다. 성능 병목 현상을 식별할 때 데이터 흐름을 따르는 것이 가장 좋습니다. 즉, 소스 데이터베이스 모니터링 으로 시작한 다음 Relational Migrator 로 이동하여 마지막으로 대상 클러스터 로 이동합니다.
소스 데이터베이스 병목 현상
낮은(< 50) 읽기 IOPS가 관찰되면 소스 데이터베이스 병목 현상이 발생할 수 있습니다. 소스 데이터베이스 성능을 개선하려면 다음 조치를 취하는 것이 좋습니다.
AWS RDS:
Provisioned IOPS를 사용하거나 저장 유형을 업그레이드 .온프레미스: 성능을 향상시키기 위해 물리적 저장 업그레이드 또는 더 성능이 뛰어난 저장 솔루션으로 마이그레이션 해야 할 수 있습니다.
Relational Migrator 병목 현상
Relational Migrator 인스턴스 의 CPU와 RAM 완전히 활용되는 경우 Relational Migrator 병목 현상을 일으킵니다. 마이그레이션 성능을 개선하려면 인스턴스 크기를 늘리는 것이 좋습니다.
다음 테스트 결과는 Relational Migrator 인스턴스 vCPU 수 및 RAM 증가가 마이그레이션 성능에 영향 보여줍니다.
소스 데이터베이스 크기 | 매핑 복잡성 | 16 vCPU, 32 GB RAM 기간 | 32 vCPU, 64 GB RAM 기간 | 개선 |
|---|---|---|---|---|
10GB | 일대일 | 15 분 | 15 분 | 0% |
10GB | 임베디드 매핑 | 50 분 | 37 분 | 26% |
10GB | 고급 | 63 분 | 47 분 | 25.40% |
100 GB | 일대일 | 3 시간 34 분 | 2 시간 31 분 | 29.44% |
100 GB | 임베디드 매핑 | 18 시간 24 분 | 16 시간 25 분 | 10.78% |
100 GB | 고급 | 16 시간 35 분 | 15 시간 47 분 | 4.82% |
1 TB | 일대일 | 45 시간 20 분 | 30 시간 50 분 | 31.99% |
Relational Migrator 인스턴스 병목 현상이 발생한 경우 vCPU 수와 RAM 늘리면 25~30%의 성능 향상이 나타났습니다.
대상 데이터베이스 병목 현상
벤치마크 결과 표에 비해 문서 삽입 또는 업데이트 속도가 낮으면 MongoDB 클러스터 병목 현상이 발생한 것일 수 있습니다. 마이그레이션 성능을 개선하려면 다음 조치를 취하는 것이 좋습니다.
프로비저닝된 IOPS 증가
vCPU 또는 RAM 증가
클러스터 계층 증가
복제 지연 으로 인해 업데이트가 제한된 경우 프로비저닝된 IOPS를 늘리는 것이 마이그레이션 성능에 가장 큰 영향 미칩니다.