共有データベースパターンからのリファクタリング

Question

作業中、集中型SQLサーバにデータベースを持つ複数のアプリケーションがあります。あるアプリケーションが別のアプリケーションのデータを処理する必要がある場合は、そのアプリケーションを照会するか、データベースを介して更新します。私は、これがエンタープライズインテグレーションパターンブック（Hohpe & Woolf）に記載されている「共有データベース」パターンだと考えています。

これらのデータベース間の依存関係により、多くの頭痛が発生しています。これらのうち最大のものは、SQLサーバー上でパフォーマンスの問題に遭遇しており、データベース間の依存関係のためにスケールアウトできないということです。私たちがやるべきことは、EIPの本で説明されているように、シェアードデータベースのパターンからメッセージングシステムに近づくことだと思います。各アプリケーションは自分自身のデータすべてを管理し、そのデータにアクセスしたい他のアプリはサービス（メッセージングバス上）を取得します。

• ここでメッセージングパターンにリファクタリングを開始しますか？
• アプリケーションの1つをリファクタリングして、独自のアプリケーションデータベースを管理することから始めますか？
• 他のアプリケーションは現在、データベースを介して他のアプリケーションと統合されていますか？
• これは、データベースの依存関係を切り離す最善の方法ですか、別の場所から開始するのがいいですか？

Answer 1

私は3相転移を示唆しています。

1. 各アプリケーションにメッセージングレイヤーを追加します。
2. アプリケーション間のデータアクセスをすべて変更し、新しく作成したメッセージングレイヤーを使用します。
3. （現在独立している）データベースを必要に応じてスケールします。

また、3つのアプリケーションがあります。 A、B、およびC

あなたはまた、3つの別々の遷移としてこれを見ることができます：変更はBで& C

に呼び出し

にメッセージを追加

• アプリケーションA

  • アプリケーションB

    • 変更は、変更が& BにCの呼び出しC
    • にメッセージを追加& C

  • アプリケーションC

    • のBに呼び出しをBにメッセージを追加します。

  このプロセスの時点では、結果はフェーズ2の終了時と同じであり、フェーズ3が進むことができます。違いは、単にリファクタリングの一種に集中することやアプリケーションに集中することが生産的であるかどうかだけです。

Answer 2

メッセージングは​​確かによりエレガントな方法の1つになることができます。しかし、それはまた少しの作業を必要とし、各データベースの変更に伴って時間をかけて変更する必要があります。各アプリケーションに他のデータベースへのログオン方法を知らせ、そこから各データベースを照会するだけで簡単にアプローチできました。私たちは、クロスデータベースクエリのほとんどはかなり軽いので、2番目のアプリでは相当なコードベースを持っていないことがわかりました。選択クエリは重複していますが、メッセージングシステムに比べて作業量が少なくなっています。

すべては、データをプッシュしたり引いたりする度合いによって異なります。それが実質的であれば、メッセージングが最善の方法です。それが最小であれば、おそらく他のデータベースへの簡単な新しい接続が必要です。

Answer 3

また、アプリケーションがデータベースをどのように使用するかについても検討します。通常、データベース（両方とも&の実装）は、トランザクション（OLTP）またはレポート（OLAP）の2つのカテゴリに分類されます。

よく設計された（実装された）トランザクションデータベースは、典型的なLOB（Line-Of-Business）アプリケーションのシナリオで優れたパフォーマンスを提供する必要があります。同様に、十分に設計された（実装された）レポートデータベースは、大量のデータの複雑さを照会する際に優れたパフォーマンスを提供する必要があります。

もう1つの重要な違いは、「リアルタイム」と「ほぼリアルタイム」の違いです。

さまざまなアプリケーションでトランザクション（リアルタイム）操作と現在の/古いデータに関するレポートの両方を行う必要があると仮定します。アプリケーションの「リアルタイム」操作をサポートするための操作速度専用に設計されたトランザクショナルと、レポート用に作成される「履歴」データを含むもう1つのデータストアが必要です。

次に、トランザクションデータストアに保存する必要のあるデータ量と、レポートデータストアに移動する時期と方法を把握します。