Zend：Zend_search_luceneのインデックス生成と長所と短所

Question

Zend Search Luceneのようなアプリ/クラスに出会ったことはありませんでした。

Zend_search_luceneは、インデックス作成の原子オブジェクトとしてドキュメントで動作します。ドキュメントは名前付きフィールドに分割され、フィールドには検索できるコンテンツがあります。

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

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

したがって、これは基本的に、これをデータベースを含むものに適用できると言っています。ここで重要なことは、検索のインデックスを作成することです。

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

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

Answer 1

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

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

外部フルテキストインデックスソリューションを使用する利点は、RDBMSのワークロードを減らすことができることです。ドキュメントを見つけるには、Lucene APIを使用して検索を実行します。結果には、プライマリキー値を含むフィールドを含める必要があります（ドキュメントの一部としてが、FT検索のために分析する必要はありません）。 Lucene検索を行うときにこのフィールドを取り戻すため、データベースのそれぞれの行を調べることができます。

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

最近、MySQL大学でフルテキスト検索ソリューションを比較したプレゼンテーションを行いました。http://forge.mysql.com/wiki/practical_full-text_search_in_mysql

スライドも公開します http://www.slideshare.net/billkarwin.