1

バックエンドのRESTfulWebサービスを使用してWebアプリケーションを構築しています。

私のテーブルの1つはほとんどスタンドアロンです。つまり、行は他の1つのテーブルからのみ参照され、結合なしで幸せに生きることができ、必要な場合にのみ主キーでフェッチできます。ただし、このテーブルには多くの行が含まれており、このテーブルに対して実行された検索はすべて「Lucene」と叫びます。MySQLは、妥当な応答時間でこれらのクエリを処理できません。

したがって、このテーブルの検索にはLuceneを使用したいと思います。過去に私はSolrを幅広く使用したことがあるので、概念と用語に精通しています。上記の状況を考えると、SQLからLuceneへのインデックス同期の代わりに、この特定のエンティティの正規ストレージとしてLuceneを単純に使用するべきではない理由がわかりません。基本的に、この特定のテーブルの現在のHibernateDAO実装を置き換える「LuceneDAO」実装が必要です。

だから私の質問は:

  1. それを避けてSQLからインデックスへの同期に固執する必要がある理由はありますか?
  2. 「LuceneDAO」が実行可能なアプローチである場合、そのようなものの基盤を提供するライブラリはありますか?検索しようとしましたが、見つかりませんでした。
  3. 私はHibernateSearchに出くわしました。それは私が探しているものの半分しか実行しませんが、検索にのみ使用することができます。Hibernate Searchを使用した経験のある人はいますか?

編集:私は今、一見私が探しているもののように見えるコンパスに出くわしました。誰かがそれを使った経験がありますか?


編集#2:Compassは廃止され、まったく同じではないElasticSearchに置き換えられました(コンポーネントではなくサービス)。Hibernate Searchも、私が探しているものではありませんでした。肝心なのは、これは有効なアプローチですが、当面はそのようなDAOを自分で実装する必要があります。

4

1 に答える 1

2

このユース ケースでは SQL を捨てて、チェイサーなしで Lucene をそのまま使用します。

Lucene を使用したクエリは、LIKE の代わりに n グラムを使用して、よりリッチになります。

于 2012-04-28T13:59:56.720 に答える