下剤

オンライン ビジネス データ (OLTP) の場合、オプション 1 はマイクロサービスの標準的な実践です。このような関連するクエリをオンラインで頻繁に実行する必要がある場合、それは 2 つのサービス (およびその 2 つのライブラリ) の結合が非常に深刻であることを意味します。では、そもそも、なぜわざわざそれらを分離する必要があるのでしょうか?

分析レポートの場合、ソリューション 2 は確かに望ましいソリューションです。検索エンジンを使用するのはやりすぎだと感じる場合は、スレーブ データベースでさまざまなレポート分析操作を実行して、オンラインの A データベースと B データベースをリアルタイムで読み取り専用データベースに同期してから試してみるとよいでしょう。読み取り専用データベースでは、JOIN は一度に実行されます。

マイクロサービスの設計原則の 1 つは、ビジネス間に重複がある場合、ビジネスに関係のないサービスを別のサービスに分離することです。

実際、この種の問題はマイクロサービスで非常に一般的です。たとえば、独自の 2 つのソリューションに加えて、注文と製品がそれぞれ 2 つのマイクロサービスに属している場合、その注文を照会する必要があります。もです

1. データの集約をデータウェアハウスに置き、AとBのデータをリアルタイムで別のデータベース(mysqlである必要はなく、Hbaseでもよい)に集約し、データウェアハウスからレポートのデータを取得します

2. テーブルを設計するとき、いくつかのフィールドを冗長化するのが適切です。あなたが言ったように、AのいくつかのフィールドはBでも予想通り冗長になる可能性があります

。

方法 1 には非常に致命的な欠点があります。ページングが関与すると、この方法を採用することは、データの大きさに応じて異なります。方法 1、速度が遅い場合は、さらにいくつかのスレッドを開いて、対応するデータをバッチで取得できます (ID が多すぎる場合は、それらをバッチで取得し、バッチ クエリはタイムアウトと時間を短縮できる効果的なソリューションです)。データの量が大きい場合は、データ ウェアハウスを使用することをお勧めします。データ ウェアハウスを使用する主な利点は、集計テーブルの生成が Binlog を通じて取得できるため、メイン データベースに負担をかけないことです。レポートは依然としてオフライン データのカテゴリに属しているため、実際に注文のようなものにする必要がある場合、クエリは非常にリアルタイムで非常に効率的で、テーブルのステータスを伴い、非常に多くの検索条件があるため、検索エンジンを使用するのが良い選択です
したがって、実際の状況に応じて方法1と方法3を使用できます

レポートの生成などの要件をビジネス データベース システムに含めるべきではありません。バックエンドに一連のカワウソ集約ライブラリを作成して、複数のサービスからのデータをリアルタイムで同期できます。その後、この集約ライブラリで必要なことを何でも行うことができます。