8

Java オブジェクトのセットを返す別のシステム上のインターフェースを呼び出して「粗い検索」を実行するシステムがあります。検索結果を受け取ったら、属性の状態を表す特定の基準に基づいて、結果の Java オブジェクトをさらにフィルタリングできるようにする必要があります (たとえば、最初のオブジェクトから xy > z && ab == c のすべてのオブジェクトを返します)。

毎回オブジェクトのセットをフィルタリングするために使用される基準は、部分的にユーザーが構成可能です。つまり、ユーザーは一致する値と範囲を選択できますが、選択できる属性は固定セットになります。

データ セットには、検索ごとに <= 10,000 オブジェクトが含まれる可能性があります。検索は、おそらく 1 日に 2000 回以下 (約)、アプリケーション ユーザー ベースによって手動で実行されます。結果セット内のすべてのオブジェクトは、構造と関係を記述する Hibernate および JPA アノテーションを持つ既知のドメイン オブジェクト クラスであることは、おそらく言及する価値があります。

可能な解決策

頭のてっぺんから、これを行う3つの方法を考えることができます。

  1. 検索ごとに、最初の結果セット オブジェクトをデータベースに保持し、Hibernate を使用して、より細かい基準を使用してそれらを再クエリします。
  2. メモリ内データベース (hsqldb など) を使用して、最初の結果セットをクエリおよび調整します。
  3. 最初の結果セットを反復処理して目的のレコードを引き出すカスタム コードを記述します。

オプション1

オプション 1 では、ネットワークを介して物理データベース (Oracle 10g) に至るまでの往復が多く、ネットワークとディスクのアクティビティが多くなる可能性があります。また、異なる検索が互いに干渉しないようにするために、各検索の結果を他の結果セットから分離する必要があります。

オプション 2

オプション 2 は、メモリ内でより細かいクエリを実行でき、検索が完了した後にのみ破棄される結果データの永続性を必要としないため、原則として良い考えのようです。直感的には、これもかなりパフォーマンスが高い可能性がありますが、メモリ オーバーヘッドが大きくなる可能性があります (これは、JVM が取得するメモリの量にかなり柔軟に対応できるため、問題ありません)。

オプション 3

オプション 3 は非常にパフォーマンスが高い可能性がありますが、作成するコードには非常に慎重なテストが必要であり、柔軟で堅牢なものを実現するのに時間がかかる可能性があるため、避けたいものです。

3 つのアイデアすべてのプロトタイプを作成する時間がないため、上記の 3 つのオプションに関するコメントと、私が検討していないその他のアイデアを探して、どのアイデアが最も適しているかを判断するのに役立てたいと考えています。私は現在、オプション 2 (メモリ内データベース) に傾倒しているので、メモリ内で POJO をクエリした経験のある人からの連絡もお待ちしています。

状況を十分に詳しく説明できれば幸いですが、シナリオをよりよく理解するためにさらに情報が必要な場合は、遠慮なくお尋ねください。

乾杯、

エド

4

4 に答える 4

1

式がそれほど複雑でない場合は、式言語を使用して、Java オブジェクト (POJO) に対する文字列クエリを評価できます。MVEL http://mvel.codehaus.orgをお勧めします。

アイデアは、オブジェクトを MVEL コンテキストに入れることです。次に、MVEL 簡易表記法に従って記述された文字列クエリを提供し、最後に式を評価します。

MVEL サイトからの例:

Map vars = new HashMap();
vars.put("x", new Integer(5));
vars.put("y", new Integer(10));

Integer result = (Integer) MVEL.eval("x * y", vars);
assert result.intValue() == 50;  // Mind the JDK 1.4 compatible code :)

通常、式言語は、オブジェクト グラフ (コレクション) のトラバースと、JSP EL スタイル (ドット表記) でのメンバーへのアクセスをサポートしています。

また、OGNL を参照することをお勧めします (Google で検索してください。複数のリンクを追加することはできません)。

于 2010-05-21T12:45:07.067 に答える
1

オプション 1 と 2 は非常に互換性があります。一方を実装することで、persistence.xml を再構成するだけで他方に置き換えることができます (インメモリ データベースが JPA と互換性がある場合、たとえば JavaDB、Derby など)。

オプション 3 は、サードパーティ ソフトウェア (データベース) と独自のコード (既存の JPA エンティティ) の両方を再実装することです。また、その利点を懸念事項として挙げました。あなたの場合、それは明らかに実現可能性の低いオプションです。オプション 3 を促進するために他に何も考えられません。

ユースケースとその期間を考えると、インメモリデータベースの方が適しているようです。要件が一時的でない要件に発展した場合は、Oracle に切り替えることができます。

于 2010-05-19T05:16:23.767 に答える
0

絞り込み基準はどれくらい複雑ですか？大多数が非常に単純である場合、最初はオプション (3) を選択したくなるでしょうが、適切なインターフェイスの背後にカプセル化されていることを確認してください。その時点でインメモリ DB に切り替えることができます (一時テーブルの設定にオーバーヘッドがある場合は、すべてのクエリに対してホールセールを行うか、複雑なクエリに対してのみ)。

于 2010-05-18T11:20:05.060 に答える
0

必要に応じて 1 と 2 を切り替えることができるため、オプション 2 が適しているようです。3 は、将来のデータ サイズの問題に関しても制限されています。オブジェクトのクエリは、ストレージとクエリのコード構造への依存度が高くなることを意味します。

おそらく、オプション 2 の使用に加えて何らかのキャッシング メカニズム (ehcache/memcache) を含めてから、プロファイルを作成してパフォーマンスの違いを確認することをお勧めします。

于 2010-05-19T08:11:05.293 に答える