2

私はいつもデータベースに問い合わせてきたので、ZendSearchLuceneのようなアプリ/クラスに出くわしたことはありません。

Zend_Search_Luceneは、インデックス作成用のアトミックオブジェクトとしてドキュメントを操作します。ドキュメントは名前付きフィールドに分割され、フィールドには検索可能なコンテンツが含まれています。

ドキュメントはZend_Search_Lucene_Documentクラスで表され、このクラスのこのオブジェクトには、ドキュメントのフィールドを表すZend_Search_Lucene_Fieldのインスタンスが含まれています。

インデックスに任意の情報を追加できることに注意することが重要です。アプリケーション固有の情報またはメタデータをドキュメントフィールドに保存し、後で検索中にドキュメントとともに取得できます。

つまり、これは基本的にデータベースを含むすべてに適用できるということです。ここで重要なのは、検索用のインデックスを作成することです。

私が把握しようとしているのは、アプリケーションのどこにインデックスを正確に保存する必要があるかということです。たとえば、データベース、メーカー、モデルに電話を保存している場合、インデックスをどのように分類する必要がありますか？

たとえば、明らかに公開したくないアドレスを使用してユーザーのインデックスを作成している場合、すべてがどのように連携して機能するかについて混乱しています。既知の欠点がある場合は、使用中に知っておくべき落とし穴があります。それ。

4

1 に答える 1

3

Luceneインデックスはデータベースの外部に保存されます。コントローラ、モデル、ビューの姉妹として「データ」ディレクトリに保存します。ただし、どこにでも保存できます。クエリ用のインデックスを開くときにパスを指定する必要があります。

これは基本的にデータベースに保存されているドキュメントの冗長コピーであり、自分で同期を保つ必要があります。これは欠点の1つです。データベースに対するクエリの結果に基づいてLuceneインデックスにデータを入力するコードを作成する必要があります。データベースにデータを追加するときは、Luceneインデックスも更新する必要があります。

外部フルテキストインデックスソリューションを使用する利点は、RDBMSの作業負荷を軽減できることです。ドキュメントを見つけるには、LuceneAPIを使用して検索を実行します。結果には、主キー値を含むフィールドが含まれている必要があります（ドキュメントの一部として、FT検索用に分析する必要はありません）。Lucene検索を実行するとこのフィールドが返されるため、データベースでそれぞれの行を検索できます。

それはあなたの質問に答えるのに役立ちますか？

最近、MySQL大学で全文検索ソリューションを比較するプレゼンテーションを行いました：http： //forge.mysql.com/wiki/Practical_Full-Text_Search_in_MySQL

スライドはhttp://www.SlideShare.net/billkarwinでも公開しています。

于 2009-12-12T21:16:49.107 に答える