2

さまざまな種類のエンティティの大規模なセットがあります。

interface Entity {
}

interface Entity1 extends Entity {
  String field1();
  String field2();
}

interface Entity2 extends Entity {
  String field1();
  String field2();
  String field3();
}

interface Entity3 extends Entity {
  String field12();
  String field23();
  String field34();
}

Set<Entity> entities = ...

タスクは、このセットの全文検索を実装することです。全文検索とは、探している部分文字列を含むエンティティを取得する必要があることを意味します（正確なプロパティ、この部分文字列が存在する場所の正確なオフセットなどを知る必要はありません）。現在の実装では、Entityインターフェースには次のメソッドがありますmatches(String)。

interface Entity {
  boolean matches(String text);
}

各エンティティクラスは、その内部に応じてそれを実装します。

class Entity1Impl implements Entity1 {
  public String field1() {...}
  public String field2() {...}

  public boolean matches(String text) {
    return field1().toLowerCase().contains(text.toLowerCase()) ||
           field2().toLowerCase().contains(text.toLowerCase());
  }
}

このアプローチは本当にひどいものだと思います（ただし、機能します）。新しいセットがあるたびに、Luceneを使用してインデックスを作成することを検討しています。インデックスとは、コンテンツ->IDマッピングを意味します。内容は、私が検討しているすべてのフィールドのほんの些細な「合計」です。したがって、Entity1コンテンツはとの連結にfield1()なりfield2()ます。パフォーマンスについては疑問があります。インデックスの作成は非常にコストのかかる操作であることが多いため、それが役立つかどうかはわかりません。

他に何か提案はありますか？

詳細を明確にするには：

  1. Set<Entity> entities = ...〜10000アイテムです。
  2. Set<Entity> entities = ...DBから読み取られないので、where ...条件を追加するだけでは不十分です。データソースは非常に重要なので、私はその側で問題を解決することはできません。
  3. Entities短い記事のように考える必要があるため、一部のフィールドは最大10KBである場合があり、他のフィールドは最大10バイトである場合があります。
  4. この検索は頻繁に実行する必要がありますが、クエリ文字列と元のセットの両方が毎回異なるため、インデックスを1回だけ作成することはできないようです（エンティティのセットは毎回異なるため）。
4

2 に答える 2

2

LuceneをSOLRで使用することを強く検討します。http://lucene.apache.org/java/docs/index.html

于 2011-09-25T10:46:29.810 に答える
1

このような複雑なオブジェクトドメインの場合、 Compassなどのluceneラッパーツールを使用すると、ORM（休止状態など）と同じアプローチを使用して、オブジェクトグラフをluceneインデックスにすばやくマッピングできます。

于 2011-09-26T10:11:59.777 に答える