あなたが提案するものはすべて、苦痛と失敗した移行のレシピです。このアプローチを使おうとすると、PostgreSQLがどれほどひどく、遅く、信頼性が低いかについて、人々は怒り狂うでしょう。これは、SQL Serverを維持したい人による大きな政治的動きですが、PostgreSQLに移行するための良い方法ではありません。
新しいPgバージョン用の読み取り/書き込み外部データラッパーが登場しますが、最初は他のPostgreSQLサーバーのみをサポートします。 sqlstatesやエラーメッセージ、検索条件などを変換する必要があるため、MS SQLのサポートは非常に困難になるため、ラッパーはかなり制限され、パフォーマンスはそれほど高くありません。あなたが言うように、FDWのサポートはとにかく現時点では未熟すぎます。
このようなハイブリッドを実行しようとすると、失うものがたくさんあります。
-
外部キーの整合性の強制はありません
-
それぞれの側のデータ型は100％同じように動作しない可能性があるため、データは一方の側では問題なく、もう一方の側では問題ない可能性があります。タイムスタンプ/日付を考えてください。
-
効率的な結合には、非常に高度な外部データラッパーが必要です。したがって、通常は、テーブル全体がフェッチされてから、ローカルで結合されます。パフォーマンスはひどいものになります。
-
最も些細な作業以外のことをしていると、クエリを書くことは悪夢になります。関数名が異なるなど。
-
多くのACIDプロパティが失われたり弱くなったりするか、2フェーズコミットを使用する必要があります。これはパフォーマンスを低下させます。
真剣に、これをしないでください。
DBの同期はおそらくさらに悪いです-それが一方向でない限り、それは失われた更新、削除された行が再び現れる、そしてさらに悪いことのレシピになるでしょう。双方向同期は非常にです 難しい。
両方のサーバーで実行できるようにすることで、移動に備えてアプリの準備を開始しますが、一度に1つだけです。アプリをPgで実行する準備ができたら、ライブデータの移行されたコピーを使用して負荷テストと信頼性テストの実行を開始します。 次に 移行を検討しますが、遅延を余儀なくされる直前の問題を見つけた場合に、移動を元に戻す方法を計画します。
アプリにまったく新しいパーツを追加する場合、それらがDB内の他のデータとまったく相互作用しないのであれば、それらをPgに含めるのが合理的かもしれません。ただし、それはほとんどあり得ません。システム管理者は、2つの別々のデータベースにまたがるアトミックスナップショットが必要だと言っても、あなたを嫌います...