このページでは、Relational Migrator のデータ移行ベンチマーク結果を説明し、その結果に基づいて推奨事項を提供します。結果と推奨事項を使用して、移行タイムラインを見積もり、適切なインフラストラクチャ構成を選択し、 リレーショナルMongoDBへの移行のリソース要件を計画できます。
ベンチマーク概要
Relational Migratorベンチマークは、次の要素に基づいて測定された移行パフォーマンスを測定します。
スキーママッピングの複雑さ
関係データベースのサイズ
関係データベースのストレージの種類
Relational Migratorインスタンスの構成
MongoDB Atlas の構成
ベンチマークにはMongoDB AtlasとAWSインフラストラクチャが使用されました。ただし、パフォーマンス パターンと推奨事項は、他のクラウドプロバイダーやオンプレミス配置にも広く適用されます。ベンチマークで使用されるインフラストラクチャの詳細については、ベンチマーク構成 を参照してください。
スキーママッピングの複雑さ
Relational Migrator を使用すると、リレーショナルスキーマをドキュメントモデルに変換できます。以下の用語は、ベンチマークで使用されるさまざまなMongoDBスキーママッピングの複雑さについて説明しています。
複雑度レベル | 説明 |
|---|---|
1 対 1 | リレーショナルスキーマに一致するMongoDBスキーマ。各テーブルは単一のMongoDBコレクションにマップされ、各行は単一のドキュメントにマップされます。高度な機能の使用を最小限に抑える。 |
埋め込みマッピング | いくつかの埋め込み配列または埋め込みドキュメントを含むMongoDBスキーマ。ネストされたドキュメントの最大 2 レベル。 |
高度な | 移行時間を増やす可能性のある多数の高度な機能を使用するMongoDBスキーマ。高度な機能の例には、次のようなものがあります。
高度なスキーマには、最大 3 レベルのネストされたドキュメントが含まれます。 |
リレーショナル データをMongoDBスキーマにマッピングする方法の詳細については、データ モデリング を参照してください。
ベンチマーク構成
以下の表は、ベンチマーク テストで使用される各コンポーネントの構成を説明したものです。
コンポーネント | 構成 |
|---|---|
移行元のデータベース（Oracle） |
Oracleインスタンスは分離され、 Relational Migratorインスタンスからのみトラフィックを受信しました。 |
Relational Migrator |
|
ターゲット データベース（MongoDB Atlas） |
|
ベンチマーク結果
次の表に、ベンチマーク テストの結果を示します。このベンチマークでは、Atlas UIまたは mongostat を使用してドキュメントメトリクスをモニターできます。Average Throughput (MB/s) 列は小数点以下2桁に丸められます。Cluster Documents/s 列は、1 秒あたりの最も近いドキュメント数に丸められます。長時間実行されている One-to-one 移行の場合、ベンチマーク中の速度の変更により、Cluster Documents/s 列は観察された下限と上限を提供します。
注意
Oracleデータベースは、ベンチマーク テスト中に CPU またはRAM の大きな使用量を示しませんでした。
データベース サイズ | マッピングの複雑さ | Oracle RDS ストレージ タイプ | Atlas クラスター階層 | 移行期間 | 平均スループット（MB/s） | クラスター ドキュメント/s |
|---|---|---|---|---|---|---|
10 GB | 1 対 1 | gp2 | M60 | 15 分 | 11.11 | 80,000 (insert) |
10 GB | 埋め込みマッピング | gp2 | M60 | 37 分 | 4.50 | 80,000 (insert), 40,000 (update) |
10 GB | 高度な | gp2 | M60 | 47 分 | 3.55 | 90,000 (insert), 40,000 (update) |
100 GB | 1 対 1 | 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 | 1 対 1 | IOPS SSD | M60 | 30 時間、50 分 | 9.01 | 85,000 から 100,000（挿入） |
Relational Migrator は、ルート ドキュメントを書き込むために常に一連の insert 操作で起動します。次に、update操作を使用して埋め込みドキュメントまたは埋め込み配列を挿入します。その結果、One-to-one ベンチマークの結果には挿入操作のみが含まれ、Embedded Mappings と Advanced の結果には挿入操作と更新操作の両方が含まれます。
パフォーマンスの推定値
ベンチマーク結果に基づいて、 Relational Migrator は約次を移行できます。
1 対 1 スキーマの場合は21 GB/時
7 GB/時 最大 2 レベルの埋め込みマッピングを持つスキーマの場合、。
1 対 1 のスキーマのデータベース移行速度はほぼ線形です。例、1 対 1 の 100 GB の移行には、1 対 1 の 10 GB の移行に比べて約 10 回かかります。
より複雑なスキーマの移行速度は、データベースのサイズに応じて直線的に増やすできません。スキーマ内の埋め込みドキュメント、埋め込み配列、およびその他の機能が多いほど、移行速度は遅くなります。
推奨事項
推奨構成
次の表は、ソースデータベースのサイズとマッピングの複雑性に基づいて、推奨される Atlas クラスター階層とAWS RDSストレージの種類を示しています。
Source Dataset サイズ | マッピングの複雑さ | 推奨 Atlas クラスター階層 | 推奨AWS RDS ストレージ タイプ |
|---|---|---|---|
0-50 GB | 1 対 1 | M60 | gp2 |
0-50 GB | 埋め込みマッピング | M60 | gp2 |
0-50 GB | 高度な | M60 | gp2 |
50 GB-300 GB | 1 対 1 | M60 | gp3 |
50 GB-300 GB | 埋め込みマッピング | M80 | gp3 |
50 GB-300 GB | 高度な | M80 | gp3 |
300 GB-1 TB | 1 対 1 | M60 | gp3 |
300 GB-1 TB | 埋め込みマッピング | M140 | IOPS SSD |
300 GB-1 TB | 高度な | M140 | IOPS SSD |
1 TB+ | 1 対 1 | M60 | IOPS SSD |
1 TB+ | 埋め込みマッピング | M200 | IOPS SSD |
1 TB+ | 高度な | M200 | IOPS SSD |
この表はMongoDB AtlasとAWS RDS の構成を指定していますが、これらの推奨事項は他のクラウドプロバイダーと自己管理型配置に適用できます。特定のMongoDB Atlasクラスター層に関連付けられているインフラストラクチャ構成の詳細については、クラウドプロバイダーを参照してください。AWS RDSストレージタイプの詳細については、AWS RDS ストレージ タイプ ドキュメントを参照してください。
ネットワーク レイテンシの最適化
ネットワークレイテンシ を最小限に抑えるには、 ソースデータベース、 Relational Migrator 、およびターゲット クラスターが同じデータセンターで実行中いることを確認します。
ボトルネックのモニター
移行パフォーマンスを最適化するために、 メトリクスをモニターしてパフォーマンスのボトルネックを特定します。ベストプラクティスとして、パフォーマンスのボトルネックを特定するときは、データの流れに従うこと。つまり、 ソースデータベース のモニタリングから開始され、次にRelational Migrator、次にターゲット クラスターの順に移動します。
ソース データベースのボトルネック
読み取り IOPS が低い（ 50 未満）場合は、ソースデータベースがボトルネックになっている可能性があります。ソースデータベースのパフォーマンスを向上させるには、次のアクションの実行を検討してください。
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 の保存期間 | 改善点 |
|---|---|---|---|---|
10 GB | 1 対 1 | 15 分 | 15 分 | 0% |
10 GB | 埋め込みマッピング | 50 分 | 37 分 | 26% |
10 GB | 高度な | 63 分 | 47 分 | 25.40% |
100 GB | 1 対 1 | 3 時間、34 分 | 2 時間、31 分 | 29.44% |
100 GB | 埋め込みマッピング | 18 時間、24 分 | 16 時間、25 分 | 10.78% |
100 GB | 高度な | 16 時間、35 分 | 15 時間、47 分 | 4.82% |
1 TB | 1 対 1 | 45 時間、20 分 | 30 時間、50 分 | 31.99% |
Relational Migratorインスタンスがボトルネックになっている場合、vCPU 数とRAMを増やすと 25-30% のパフォーマンスが向上しました。
ターゲット データベースのボトルネック
ベンチマーク結果テーブルと比較して、ドキュメント挿入または更新率が低い場合は、 MongoDBクラスターがボトルネックになる可能性があります。移行のパフォーマンスを向上させるために、次のアクションの実行を検討してください。
プロビジョニングされた IOPS を増やす
vCPU またはRAMを増やす
クラスター階層の増加
レプリケーションラグによりアップデートが制限されたことが観察され、プロビジョニングされた IOPS の増加が移行パフォーマンスに最も影響を与えます。