私は、いくつかの属性に基づいて人々を検索するツールを構築しています。これらの属性の値は、複数のシステムに分散しています。
例として、dateOfBirthはシステムABCの一部としてSQLServerデータベースに保存されます。その人の販売地域の割り当ては、いくつかの恐ろしいレガシーデータベースに保存されています。その他の属性は、XMLWebサービスを介してのみアクセス可能なシステムに格納されます。
さらに悪いことに、レガシーデータベースとWebサービスは非常に遅くなる可能性があります。
これらすべてのシステムに検索を実装するには、どのような戦略とヒントを検討する必要がありますか？
注：私は回答を投稿しましたが、それが素晴らしい回答であるとは確信していません。他の誰もより良い洞察を与えない限り、私は自分の答えを受け入れるつもりはありません。
インデックス作成メカニズムを使用して、すべてのシステムのデータを取得してローカルにインデックスを作成し、インデックスに対して検索を実行することを検討できます。検索は非常に高速で信頼性が高くなります。
もちろん、これは問題をシステムのある部分から別の部分に移すだけです。今では、インデックスメカニズムは障害や異種システムを処理する必要がありますが、それは解決しやすい問題かもしれません。
もう1つの要因は、データが変更される頻度です。非常に迅速に古くなるデータをリアルタイムでクエリする必要がある場合は、インデックス作成が実用的でない可能性があります。
制限付き検索を回避できる場合は、最速のデータソースに対応する検索条件に基づいてリストを返すことから始めます。次に、それらのレコードを他のシステムと結合し、検索条件に一致しないレコードを削除します。
ORロジックを実装する必要がある場合、このアプローチは機能しません。
実際の答えではありませんが、これにより、少なくとも途中で実行可能なソリューションが得られる可能性があります。以前の雇用主でも同様の状況がありました。多くのデータソース、それらのデータソースにアクセスするさまざまな方法、さまざまなアクセス許可、軍/政府/民間のソースなどです。Muleを使用しました。、エンタープライズサービスバスの概念に基づいて構築されており、これらのデータソースをアプリケーションに接続します。私は実際の実装者ではなく、単なるインテグレーターであったため、詳細は少し大雑把ですが、私たちが行ったのはMuleでチャネルを定義することでした。次に、チャネルとデータソース、およびアプリケーションとチャネルの間を行き来する簡単な統合ピースを作成します。統合ピースは実際のクエリを作成し、結果をフォーマットする作業を行うため、データベースにアクセスするための汎用SQL統合ピースがあり、Webサービスなどには、共通の機能を実装する基本クラスがいくつかありました。統合部分のカスタマイズは、思ったよりもはるかに少ない作業でした。次に、アプリケーションは、さまざまなデータソースへのアクセスを処理するチャネルにクエリを実行できます。
これは私たちの状況にとって多くの利点がありました。既存のクエリの新しいデータソースをチャネルに接続するだけで含めることができます。アプリケーションは、チャネルからのデータのみを参照するため、そこにあるデータソースを認識したり気にしたりする必要はありませんでした。データはチャネルからプッシュまたはプルできるため、たとえば更新されたときに、データソースにアプリケーションを更新させることができます。
構成して機能させるにはしばらく時間がかかりましたが、一度実行すると、かなり成功しました。デモのセットアップでは、4つまたは5つのアプリケーションがデータのプロデューサーとコンシューマーの両方として機能し、おそらく10のデータソースに接続することになりました。
Pentaho / Kettleを使用して、検索して表示できるすべてのデータフィールドをローカルのMySQLデータベース
http://www.pentaho.com/products/data_integration/にコピーします。
毎晩実行するバッチスクリプトを作成し、ローカルコピーを更新します。多分毎時ですら。次に、ローカルのMySQLデータベースに対してクエリを記述し、結果を表示します。
YQLを見たことがありますか？それは完璧な解決策ではないかもしれませんが、私はあなたに仕事の出発点を与えるかもしれません。
データを別の構造に移動することを考えましたか？
たとえば、Luceneは、検索対象のデータをスキーマのない反転インデックスに格納します。さまざまなソースすべてからデータを取得し、それらをLuceneインデックスに配置する別のプログラムを作成できます。検索はこのインデックスに対して機能する可能性があり、検索結果には一意の識別子とそれが由来するシステムが含まれる可能性があります。
http://lucene.apache.org/java/docs/ （他の言語でも実装されています）
まず、クエリをさまざまなシステムに並列化します。そうすれば、クエリ時間を最小限に抑えることができます。
また、処理を高速化するために、後続のクエリの検索属性をキャッシュして集約することも検討してください。
クエリ用の単一のインターフェイスを提供できるように、すべての異なるシステムを集約する集約サービスまたはミドルウェアを作成するオプションがあります。そうすれば、これは私が前述のキャッシュを実行し、最適化を並列化する場所です。
ただし、これらすべてを考慮すると、古いレガシーデータベースをより高速で最新のデータベースに移行することに対する取り組みの開発時間/展開時間/長期的なメリットを比較検討する必要があります。これらのデータベースが他のシステムにどのように結びついているかについてはまだ述べていないため、短期的にはあまり実行可能なオプションではない可能性があります。
編集：データが古くなったことに応じて。データが常にデータベースとリアルタイムで一致する必要がない場合は、データのキャッシュを検討できます。また、一部のデータがあまり頻繁に変更されない場合（たとえば、生年月日）、それらをキャッシュする必要があります。キャッシュを使用する場合は、キャッシュに含めるまたはキャッシュから除外するテーブル/列についてシステムを構成可能にし、全体的なデフォルトで各テーブル/列にパーソナライズ可能なキャッシュタイムアウトを与えることができます。