Factors to consider when migrating#

移行の分析と計画を行うときは、次の要素を検討する必要があります。

  • スキーマ

  • データ

  • インフラストラクチャ

  • アプリケーション

  • オペレーション

  • サーバーのサイジング

スキーマの移行の考慮事項#

スキーマはデータベースの構造を定義します。スキーマには、テーブルと、シーケンス、インデックス、制約、ビューなどの他の構造の定義が含まれます。これらのオブジェクトを作成するためにPostgresが提供する構文は、多くの場合Oracleの構文と似ているまたは同一ですが、移行時に対処する必要がある違いがあります。 OracleとPostgresがスキーマオブジェクトを編成および保存する方法にも違いがあるため、理解することが重要です。

データ型は、テーブルおよびデータベースで使用されるその他のオブジェクトで使用されます。移行の場合、Oracleのデータ型とPostgresのデータ型をどのようにマッピングするかについて考える必要があります。

データベーススキーマには、パッケージ、プロシージャ、ファンクション、トリガーを含むコードオブジェクトも含まれており、データベースに直接書き込まれます。 Oracleでは、コードオブジェクトはOracleのPL/ SQL言語で作成されます。 PostgreSQLには、Oracleのものと互換性のない独自のビルトインプログラミング言語があります。ただし、 EDB Postgres Advanced Serverは、SPLとして知られるPL/ SQLのビルトイン実装を提供します。 EDBのSPLは、最も一般的に使用されるOracle PL/ SQLコンストラクトの大部分をカバーしていますが、Oracleコンストラクトの完全なセットを実装しているわけではありません。その結果、 EDB Postgres Advanced Serverで動作するように一部のOracleコードオブジェクトを変換する必要がある場合があります。

多くの場合、ソースデータベースとターゲットデータベースがデータと対話する方法には構文の違いがあります。 Oracleには、Postgresでサポートされていない情報を選択、挿入、更新、削除するために構造化照会言語SQLのバージョンで使用する特定の規則とキーワードがあることに注意する必要があります。

データ移行の考慮事項#

スキーマは構造を提供しますが、データはデータベースのコンテンツです。検討する必要があるのは、データをターゲットデータベースに移動する方法です。この方法は、移動する必要があるデータの量と、どれだけのダウンタイムが許容できるかによって異なります。大量のロードが自分にとって適切であるかどうか、つまりソースシステムからデータのスナップショットを取得し、ターゲットシステムに転送し、そこから続行するかどうかを判断する必要があります。または、データをターゲットデータベースに移行している間、ソースアプリケーションとデータベースを実行したままにする必要がある場合があります。ソースデータベースはまだ更新を受信しているため、そのデータをターゲットデータベースに継続して移動できるようにする必要があります。

フォールバックは別の考慮事項です。移行プロセスを進めると、最終的に移行が完了します。移行したシステムのテストを最終決定するときは、移行が完全に成功しなかった場合に備えて、フォールバックポジションが必要になることがよくあります。古いデータベースが、移行されたデータベースに適用されるデータの変更との同期が維持されている場合、移行したシステムで操作を開始した後、元のソースデータベースとソースアプリケーションに簡単にフォールバックできます。フォールバック計画では、移行したデータベースに入力された新しいデータがタイムリーに元のソースデータベースに戻せることを保証する必要があります。

データを移行する場合、ソースデータベースからターゲットデータベースにデータをプッシュするために提供するコアツールに加えて、より複雑な抽出-変換-ロードETLニーズなど、より高度なデータ移行シナリオをサポートするツールを使用することもできます。 。これらのツールは、ソースデータベースからデータを取得して変換し、ターゲットデータベースにロードします。

データがターゲットシステムに配置されたら、ターゲットシステムに配置したデータがソースシステムのデータと一致することを検証する必要があります。

インフラストラクチャの考慮事項#

データベースはインフラストラクチャ上にあるため、ソースデータベースのホスティング環境とターゲット環境がどのようなものかを検討する必要があります。たとえば、現在のデータベースがオンプレミスで展開されている場合、同様にオンプレミスで実行されている別のデータベースに移行することを決定する場合があります。しかし、ますます多くの組織が、データベースのオンプレミス展開からクラウドベースの展開への移行を検討しています。クラウドベースの展開が最終的な目標である場合、オンプレミスで実行されているデータベースからクラウドで実行されているデータベースに直接移行することにする場合があります。または、最初にデータベースをオンプレミスで実行されているものに移行し、次に、移行したデータベースをクラウドに移動することもできます。

最終状態またはクラウドへの足がかりとしてオンプレミスデータベースに移行する場合、移行を実行およびテストし、運用データベースと関連ツールをホストするためのサーバーリソースを手元にあることを確認する必要があります。クラウドに移行する場合、ニーズは同様ですが、移行プロセスをサポートするために、必要に応じてサーバーを追加および削除する柔軟性が高くなります。

考慮すべきもう1つの要素は、多くの古いアプリケーションデータベースが専用のハードウェアとオペレーティングシステムに展開されていることです。サーバーオプションをターゲットとする可能性が高いことを考えると、この要素は、移行に使用されるツールの種類とアプローチに影響を与える可能性があります。使用する予定のツールがこれらのシステムに展開できるか、それらにアクセスして移行する情報を取得できることを確認する必要があります。

オンプレミスリソースへの移行を検討する場合、 EDB Postgres Advanced Serverで使用可能な展開オプションは次のとおりです。

・ 物理サーバー

  • 仮想マシン

  • KubernetesのクラウドネイティブのPostgresコンテナ

  • プライベートクラウドインスタンス

通常、データベースは物理サーバーにインストールして、パフォーマンスを最適化します。時間の経過とともに、仮想化テクノロジーが向上するにつれて、データベースが仮想マシンにインストールされることがより一般的になりました。 ここ数年、コンテナはデータベース展開の実行可能なオプションとして浮上し始めており、特に業界がオーケストレーションフレームワークとしてKubernetesで多かれ少なかれ標準化が進み、EDBのようなデータベースベンダーがコンテナにデータベースを展開および維持するためのKubernetesオペレーターを開発しているため、 。

クラウドへの移行の場合、以下はEDB Postgres Advanced Serverの展開オプションです。

  • BigAnimalクラスター

  • クラウドベースのサーバーインスタンスにインストールされた自己管理EDB Postgres Advanced Server

  • クラウドネイティブPostgreSQLCNP

ますます多くの組織が、管理対象データベースサービスDBaaSとしても知られ、このサービスが企業に提供するメリットを利用することに関心を持っています。 BigAnimalは、主要な商用クラウドで利用可能なEDB Postgres DBaaSオファリングであり、PostgreSQLまたはEDB Postgres Advanced Serverデータベースクラスターを簡単に展開するオプションを提供します。クラウドに移行したいが、データベースインスタンスと基になるサーバーの管理をより詳細に制御したい場合は、クラウドベースのサーバーインスタンスにEDB Postgres Advanced Serverを自分でインストールおよび管理できます。 EDBのクラウドネイティブPostgreSQLCNPを使用すると、KubernetesオーケストレーションコンテナにPostgreSQLまたはEDB Postgres Advanced Serverクラスターを展開および管理できます。データベース用のコンテナの広範な採用は、まだ初期段階です。しかし、アプリケーションがマイクロサービスに移行するにつれて、データベース用のコンテナの使用が増加しています。 Kubernetesクラスターは、クラウドで立ち上げることができます。実際、大手クラウドプロバイダーもマネージドKubernetesサービスを提供しています。

異なるソースインフラストラクチャとターゲットインフラストラクチャがある場合、インフラストラクチャに基づいてソースシステムを最適化している可能性を検討してください。ターゲットシステムに移動するときは、別の手法を使用して同様の最適化を実行する必要がある場合があります。

アプリケーションの移行の考慮事項#

アプリケーションは、データベースに情報を送信し、データベースから情報を取得します。 OracleやPostgresなどのリレーショナルデータベース管理システムRDBMSバックエンドを使用するほとんどのアプリケーションは、構造化照会言語SQLでデータベース照会を発行します。 SQL標準の重要なコンポーネントは、すべての主要なリレーショナルデータベースに採用されました。ただし、それぞれは標準から逸脱し、互いに異なる機能を持っています。そのため、移行作業の一部として、静的または動的に生成された、アプリケーションコードに埋め込まれたSQLコードの何らかの変換が必要になる可能性があります。

さらに、アプリケーションは通常、古いデータベースシステムとオペレーティング環境で動作するように適切にパフォーマンスするように調整および構成されます。古いシステムから新しいシステムに移動するときは、新しいデータベースとオペレーティング環境に対する正常な実行をサポートするために、アプリケーションにいくつかの変更を加える必要がある場合があります。

運用上の考慮事項#

古いデータベースを新しいデータベーステクノロジーに移行すると、新しいデータベースと連携するように運用プロセスとツールを更新する必要があります。 OracleからPostgresへの移行の場合、使用されているOracle固有のツールはPostgres固有のツールに置き換える必要があります。考慮すべき主な運用面には、高可用性、バックアップとリカバリー、監視と管理、セキュリティ、暗号化が含まれます。

また、古いデータベースが古い専用のハードウェアとオペレーティングシステムで実行されている場合、データベースの移行には、基になるホストシステムを最新のプラットフォームとオペレーティングシステムに移行することも必要になる場合があります。オンプレミスの移行の場合、これにより、新しいサーバープラットフォームとオペレーティングシステムで動作するように運用とメンテナンスの手順とツールを変更する必要がある場合があります。クラウドへの移行の場合、運用とメンテナンスアクティビティの一部はクラウドサービスプロバイダーが処理しますが、その他は引き続きお客様の責任です。おそらく、これらのアクティビティには、現在使用しているものとは異なるツールと手順が必要です。

サイズ設定と構成の考慮事項#

「どれくらいの大きさのサーバーが必要ですか?」

この質問は、OracleからPostgresへの移行を検討するときによく起こります。最短の答えは「場合によって」ですが、これは良い答えではありません。より良い方法は、「1:1対応つまり同じ数のコア、RAMなどで開始し、そこから行くことです。」

それはなぜでしょうか？

PostgresとOracleは、内部的には大きく異なり、 SQLプランニングが異なり、ストレージとアクセスパターンが異なります。バージョン管理とトランザクションの分離でさえ、別の方法で実装されます。そのため、Oracleの構成とアーキテクチャの考えられるすべての順列をカバーする単純な式を設定することが困難になっています。すべてのデータベースは、実行中のワークロードに対してそれぞれ異なる応答をします。

EDB Postgres Advanced Serverに移行したEDBの顧客は、同様のハードウェアを使用する場合、Oracleと同等のパフォーマンスを見つけました。場合によっては、ワークロードによっては、Oracleを上回るパフォーマンスを発揮する場合もあります。移行したすべてのお客様は、少なくともOracleのパフォーマンスに匹敵し、可能であれば、同等のハードウェアで、または必要に応じてリソースを追加することにより、それを超えることを目指していました。また、特定のワークロードを使用してベンチマークを実行して、システムがパフォーマンスの期待を満たしていることを確認し、それに応じて生産を計画することをお勧めします。

ベストプラクティスの考慮事項#

次に、OracleからPostgresデータベースアプリケーションの移行を計画する際に考慮するベストプラクティスをいくつか示します。

  • 移行手順の手順をスキップまたは流し読みしないでください。

  • 計画を立てます。

  • 機能的要件と非機能要件を特定して理解します。

  • 早期にソリューションデザインを完了して、ITリソースのニーズを理解します。

  • 開発環境とテスト環境を使用して、運用環境に移行する前に、移行の問題を特定および解決します。

  • 移行の早い段階でアプリケーション開発者とシステム管理者を参加させて、データベースチームと協力します。

  • 運用環境と使用法に近い方法で、データベースを使用してアプリケーションをテストできる環境をセットアップします。

  • データベーススキーマを移行する場合、データの移行後までインデックスと制約のロードを遅延します。

  • より複雑な移行については、移行の専門家とPostgreSQLの専門家の助けを借ります。

  • 移行後の操作の前に、運用担当者が新しいシステムに関するトレーニングを受けていることを確認します。