Previous Next

ベストプラクティス

フィールド名

Zend_Search_Lucene では、フィールド名に関する制限は特にありません。

しかし、できれば 'id' および 'score' という名前は使用を控えるようにしましょう。 これらを使用すると、QueryHit のプロパティ名と区別しにくくなります。

Zend_Search_Lucene_Search_QueryHit のプロパティ idscore はそれぞれ、Lucene ドキュメントが内部で使用する ID、検索結果の スコア を表します。もしドキュメントでこれらと同じ名前のフィールドを使っているのなら、 そのフィールドにアクセスするには getDocument() メソッドを使う必要があります。

$hits = $index->find($query);

foreach ($hits as $hit) {
    // 'title' フィールドを取得します
    $title = $hit->title;

    // 'contents' フィールドを取得します
    $contents = $hit->contents;

    // Lucene ドキュメントの内部 ID を取得します
    $id = $hit->id;

    // 検索結果のスコアを取得します
    $score = $hit->score;

    // 'id' フィールドを取得します
    $docId = $hit->getDocument()->id;

    // 'score' フィールドを取得します
    $docId = $hit->getDocument()->score;

    // 'title' フィールドもこの方法で取得できます
    $title = $hit->getDocument()->title;
}

インデックス作成のパフォーマンス

インデックス作成のパフォーマンスは、 リソースの消費量と所要時間、 そしてインデックスの品質との兼ね合いで決まります。

インデックスの品質とは、要するにインデックスセグメントの数のことです。

各インデックスセグメントはデータ部とは独立しています。 つまり、インデックスに含まれるセグメントが多くなればなるほど 検索に要するメモリと時間は増加します。

インデックスの最適化を行うと、 複数のセグメントをまとめて新しいひとつのセグメントを作成します。 完全に最適化されたインデックスは、セグメントひとつだけで構成されます。

インデックスの最適化を行うには optimize() メソッドを使用します。

$index = Zend_Search_Lucene::open($indexPath);

$index->optimize();

インデックスの最適化はデータストリーム上で行われるので、 それほどメモリは消費しません。ただ、CPU リソースをかなり消費し、時間もかかります。

Lucene のインデックスセグメントは、その性質上 更新はできません (更新するには、 セグメントファイルを新たに作りなおす必要があります)。 したがって、新しいドキュメントがインデックスに追加されるたびに 新しいセグメントが作成されることになります。 その結果、インデックスの品質は下がっていきます。

セグメントが作成されるたびにインデックスの自動最適化が行われ、 一部のセグメントは自動的にマージされます。

自動最適化の設定は、次の 3 つのオプションで変更できます (インデックスの最適化 を参照ください)。

  • MaxBufferedDocs は、メモリ内のバッファに保持されるドキュメントの最大数です。 この数を超えると、新しいセグメントを作成して ハードディスクに書き込みます。

  • MaxMergeDocs は、自動最適化によって新しいセグメントへのマージを行う基準となる ドキュメント数です。

  • MergeFactor は、自動最適化を行う頻度を指定します。

Note:

これらのオプションはすべて Zend_Search_Lucene オブジェクトのプロパティであり、インデックスのプロパティではありません。 したがって、この設定は現在使用中の Zend_Search_Lucene オブジェクトに対してのみ働くようになり、 スクリプトによって設定は異なります。

MaxBufferedDocs は、 スクリプトを一回実行するたびにひとつのドキュメントしか扱わない場合は 何の影響も及ぼしません。 逆に、バッチ処理の場合にはこの設定が非常に重要になります。 値を大きくするとインデックス作成の速度が上がりますが、 同時に大量のメモリを消費するようになります。

MaxBufferedDocs パラメータの値として最適なものを計算する公式はありません。 これはドキュメントのサイズや解析器、使用できるメモリ量などに依存するからです。

最適な設定値を取得するには、 扱うであろうドキュメントの中で最もサイズが大きいものを用いて 何度かテストをしてみましょう [1] memory_get_usage()memory_get_peak_usage() 。 使用可能なメモリのうち半分を超えない程度のメモリ消費量に抑えておくことをお勧めします。

MaxMergeDocs はセグメントの大きさ (これはドキュメントの大きさによって決まります) を制限します。 これにより、自動最適化の時間を短縮することができます。 つまり、addDocument() メソッドが ある時間以上は実行されなくなります。 これは、対話的なアプリケーションで重要になります。

MaxMergeDocs の設定値を小さくすると、 バッチ処理のパフォーマンスもあがります。 インデックスの自動最適化は対話的な処理であり、 ひとつひとつ順を追って実行していきます。 小さなセグメントたちがひとつの大きなセグメントにまとめられ、 さらにまたそれが他のセグメントとまとまってより大きなセグメントになり、 といった具合です。インデックスの最適化を完全に行うと、 処理が非常に効率的になります。

セグメントのサイズを小さくするとインデックスの品質が下がり、 大量のセグメントができあがってしまいます。場合によっては、OS の制限に引っかかって "オープンしているファイルが多すぎる" というエラーが発生するかもしれません [2] Zend_Search_Lucene

したがって、バックグラウンドでのインデックスの最適化は対話モードで行い、 バッチ処理用の MaxMergeDocs はあまり小さくしすぎないようにしなければなりません。

MergeFactor は自動最適化の頻度に影響を及ぼします。 値を小さくすると、最適化されていないインデックスの品質が上がります。 値を大きくするとインデックス作成の策度が上がりますが、 セグメントの数も増えます。何度も言いますが、これは "オープンしているファイルが多すぎる" エラーの原因となりえます。

MergeFactor は、以下の条件を満たす大きさで インデックスセグメントをグループ化します。

  1. MaxBufferedDocs 以下

  2. MaxBufferedDocs より大きいが MaxBufferedDocs*MergeFactor を超えない

  3. MaxBufferedDocs*MergeFactor より大きいが MaxBufferedDocs*MergeFactor*MergeFactor を超えない

  4. ...

Zend_Search_Lucene は、addDocument() をコールするたびにセグメントの状況を調べ、 いくつかのセグメントをまとめて次のグループの新しいセグメントに移動できるかどうかを確認します。 できる場合はマージを行います。

つまり、N 個のグループからなるインデックスには MaxBufferedDocs + (N-1)*MergeFactor のセグメントが含まれ、少なくとも MaxBufferedDocs*MergeFactor(N-1) のドキュメントが存在することになります。

この式で、インデックス内のセグメントの概数を求めることができます。

NumberOfSegments <= MaxBufferedDocs + MergeFactor*log MergeFactor (NumberOfDocuments/MaxBufferedDocs)

MaxBufferedDocs は、使用できるメモリ量によって決まります。 MergeFactor を適切に設定することで、セグメントの数を調整することができます。

バッチ処理においては、MergeFactor パラメータを調整するほうが MaxMergeDocs を調整するよりも効率的です。しかし、微調整はできず大雑把なものとなります。 そこで、まず上の公式をもとに MergeFactor を調整し、 それから MaxMergeDocs を微調整してパフォーマンスを最適化しましょう。

インデックスの終了時処理

Zend_Search_Lucene オブジェクトは、 終了時にちょっとした作業を行います。 これは、インデックスにドキュメントが追加されたけれども 新しいセグメントに書き込まれていないという場合に行われます。

また、場合によっては自動最適化も行います。

インデックスオブジェクトは、自分自身および QueryHit オブジェクトがすべてスコープ外に出た時点で自動的に終了処理を行います。

インデックスオブジェクトがグローバル変数に格納されている場合は、 スクリプトの終了時に破棄されます [3]

PHP の例外処理もここで終了します。

これは通常のインデックス終了処理を妨げることはありませんが、 何かエラーが発生した際に正しいエラー情報を取得できなくなる可能性があります。

この問題を回避する方法はふたつあります。

まずは、強制的にスコープ外に出す方法です。

$index = Zend_Search_Lucene::open($indexPath);

...

unset($index);

そしてもうひとつは、スクリプトの終了前にコミット操作を行うことです。

$index = Zend_Search_Lucene::open($indexPath);

$index->commit();
これについては、このドキュメントの "応用: 静的プロパティとしてのインデックスの使用" でも説明しています。

一意な ID によるドキュメントの取得

ドキュメントの一意な ID、たとえば URL やパス、データベース上の ID などをインデックスに保存しておくとよいでしょう。

Zend_Search_Lucene には termDocs() というメソッドがあり、指定した単語を含むドキュメントを取得することができます。

これは find() メソッドよりも効率的です。

// find() メソッドでクエリ文字列を指定することによるドキュメントの取得
$query = $idFieldName . ':' . $docId;
$hits  = $index->find($query);
foreach ($hits as $hit) {
    $title    = $hit->title;
    $contents = $hit->contents;
    ...
}
...

// find() メソッドでクエリ API を使用することによるドキュメントの取得
$term = new Zend_Search_Lucene_Index_Term($docId, idFieldName);
$query = new Zend_Search_Lucene_Search_Query_Term($term);
$hits  = $index->find($query);
foreach ($hits as $hit) {
    $title    = $hit->title;
    $contents = $hit->contents;
    ...
}

...

// termDocs() メソッドによるドキュメントの取得
$term = new Zend_Search_Lucene_Index_Term($docId, idFieldName);
$docIds  = $index->termDocs($term);
foreach ($docIds as $id) {
    $doc = $index->getDocument($id);
    $title    = $doc->title;
    $contents = $doc->contents;
    ...
}

メモリの使用法

Zend_Search_Lucene は、比較的メモリを消費するモジュールです。

各種の情報をキャッシュしたり、検索やインデックス作成の速度を上げたりするために、メモリを使用しています。

メモリに関する挙動は、モードによって異なります。

単語辞書のインデックスは、検索時にメモリに読み込まれます。 これは、実際の辞書に登録されている単語が 128件 [4]Zend_Search_Lucene に達するごとに作成されます。

したがって、単語の数が増えれば増えるほどメモリの消費量も増加します。 トークン化していないフレーズをフィールドの値として使用したり、 テキスト以外の情報を大量にインデックスとして使用したりすると、 単語の数が増えることになります。

最適化されていないインデックスは、複数のセグメントで構成されます。 これも、メモリ消費量の増加の要因となります。 各セグメントは独立しているので、それぞれ独自に単語辞書と辞書インデックスを持っています。 ひとつのインデックスの中に N 個のセグメントがあったとすると、 メモリの消費量は最悪で N 倍になってしまいます。 インデックスの最適化を行ない、セグメントをひとつにまとめましょう。

インデックスは、検索処理とドキュメントのバッファリングに同じメモリを使用します。 このメモリの使用量は、パラメータ MaxBufferedDocs で指定します。

インデックスの最適化 (完全最適化、部分最適化の両方) はストリーム上で行なわれるので、あまりメモリを消費しません。

エンコーディング

Zend_Search_Lucene は、内部で UTF-8 文字列を使用しています。 したがって、Zend_Search_Lucene が返す文字列は、すべて UTF-8 でエンコードされています。

単なる ASCII データのみを扱うのであればエンコーディングを気にする必要はありません。 しかしそれ以外の場合は要注意です。

間違ったエンコーディングを使用すると、 エンコーディングの変換時にエラーが発生したりデータを失ってしまったりする可能性があります。

Zend_Search_Lucene は、ドキュメントやクエリのエンコーディングとしてさまざまなものに対応しています。

フィールドを作成するメソッドで、エンコーディングをオプションのパラメータによって指定することができます。

$doc = new Zend_Search_Lucene_Document();
$doc->addField(Zend_Search_Lucene_Field::Text('title',
                                              $title,
                                              'iso-8859-1'));
$doc->addField(Zend_Search_Lucene_Field::UnStored('contents',
                                                  $contents,
                                                  'utf-8'));
エンコーディングの指定をはっきりさせるという意味で、これが最も良い方法です。

このエンコーディング指定を省略すると、現在のロケールをもとに判断を行ないます。 ロケールの指定時に、言語だけでなく文字セットも指定することができます。

setlocale(LC_ALL, 'fr_FR');
...

setlocale(LC_ALL, 'de_DE.iso-8859-1');
...

setlocale(LC_ALL, 'ja_JP.UTF-8');
...

クエリ文字列のエンコーディングも、同じ方式で指定します。

エンコーディングを何らかの方法で指定しなかった場合は、 現在のロケールにもとづいて判断を行ないます。

検索の前にクエリのパースを行なう場合、 エンコーディングはオプションのパラメータとして指定することができます。

$query =
    Zend_Search_Lucene_Search_QueryParser::parse($queryStr, 'iso-8859-5');
$hits = $index->find($query);
...

デフォルトのエンコーディングを指定するには setDefaultEncoding() メソッドを使用します。

Zend_Search_Lucene_Search_QueryParser::setDefaultEncoding('iso-8859-1');
$hits = $index->find($queryStr);
...
空の文字列は、'現在のロケール' を意味します。

正しいエンコーディングを指定すれば、解析器はそれを正しく処理することができます。 実際の挙動は、使用する解析器によって異なります。詳細は 文字セット についての説明を参照ください。

インデックスの保守

まずはっきりさせておくべきなのは、Zend_Search_Lucene やその他の Lucene 実装は決して "データベース" ではないということです。

つまり、データを保存するものとして使用してはいけません。 通常のデータベース管理システムのように、バックアップ/リストア やジャーナル処理、ログの記録、トランザクションといった機能は持っていません。

しかし、Zend_Search_Lucene はインデックスの一貫性を保持するための機能は持っています。

インデックスのバックアップ/リストアは、オフラインでインデックスフォルダをコピーすることで行ないます。

何らかの理由でインデックスが壊れてしまった場合は、 インデックスをリストアするか再構築しなければなりません。

そこで、大きなインデックスは、どこかに手動でバックアップしておき、 何かあったときに手動で復元できるようにしておきましょう。 そうすれば、障害からの復旧にかかる時間が短縮できます。

[1] や で、メモリの使用量を確認します。
[2] は、セグメントファイルをずっとオープンしたままにしておきます。 これによって検索の効率を上げています。
[3] インデックスや QueryHit オブジェクトが複合データ型から参照されている場合にもこれは起こりえます。 たとえば、循環参照を含むオブジェクトはスクリプトの終了時まで破棄されません。
[4] Lucene のファイルフォーマットでは、この件数を変更することもできます。しかし の API ではそれをサポートしていません。 別の Lucene 実装を使用してインデックスをサポートすれば、 この値を変更することも可能です。
Previous Next
Introduction to Zend Framework
概要
インストール
Zend_Acl
導入
アクセス制御の洗練
高度な使用法
Zend_Amf
導入
Zend_Amf_Server
Zend_Application
導入
Zend_Application クイックスタート
Theory of Operation
コア機能
利用できるリソースプラグイン
Zend_Auth
導入
データベースのテーブルでの認証
ダイジェスト認証
HTTP 認証アダプタ
LDAP 認証
Open ID 認証
Zend_Cache
導入
キャッシュの仕組み
Zend_Cache のフロントエンド
Zend_Cache のバックエンド
Zend_Captcha
導入
Captcha の方法
CAPTCHA アダプタ
Zend_CodeGenerator
導入
Zend_CodeGeneratorサンプル
Zend_CodeGeneratorリファレンス
Zend_Config
導入
動作原理
Zend_Config_Ini
Zend_Config_Xml
Zend_Config_Writer
Zend_Config_Writer
Zend_Console_Getopt
導入
Getopt の規則の宣言
オプションおよび引数の取得
Zend_Console_Getopt の設定
Zend_Controller
Zend_Controller クイックスタート
Zend_Controller の基本
フロントコントローラ
リクエストオブジェクト
標準のルータ
ディスパッチャ
アクションコントローラ
アクションヘルパー
レスポンスオブジェクト
プラグイン
モジュラーディレクトリ構造の規約の使用
MVC での例外
以前のバージョンからの移行
Zend_Currency
Zend_Currency について
通貨の操作方法
以前のバージョンからの移行
Zend_Date
導入
動作原理
基本メソッド
Zend_Date API の概要
日付の作成
日付関数全般用の定数
動作例
Zend_Db
Zend_Db_Adapter
Zend_Db_Statement
Zend_Db_Profiler
Zend_Db_Select
Zend_Db_Table
Zend_Db_Table_Row
Zend_Db_Table_Rowset
導入
Zend_Db_Table_Definition
Zend_Debug
変数の出力
Zend_Dojo
導入
Zend_Dojo_Data: dojo.data エンベロープ
Dojo ビューヘルパー
Dojoフォーム要素とデコレーター
Zend_Dojo build layer support
Zend_Dom
導入
Zend_Dom_Query
Zend_Exception
例外の使用法
Zend_Feed
導入
フィードの読み込み
ウェブページからのフィードの取得
RSS フィードの使用
Atom フィードの使用
単一の Atom エントリの処理
フィードおよびエントリの構造の変更
独自のフィードクラスおよびエントリクラス
Zend_Feed_Reader
Zend_File
Zend_File_Transfer
Zend_File_Transfer 用のバリデータ
Filters for Zend_File_Transfer
以前のバージョンからの移行
Zend_Filter
導入
標準のフィルタクラス群
フィルタチェイン
フィルタの書き方
Zend_Filter_Input
Zend_Filter_Inflector
前バージョンからの移行
Zend_Form
Zend_Form
Zend_Form クイックスタート
Zend_Form_Element を用いたフォーム要素の作成
Zend_Form によるフォームの作成
Zend_Form_Decorator による独自のフォームマークアップの作成
Zend Framework に同梱されている標準のフォーム要素
Zend Framework に同梱されている標準のデコレータ
Zend_Form の国際化
Zend_Form の高度な使用法
Zend_Gdata
導入
AuthSub による認証
Using the Book Search Data API
ClientLogin による認証
Google Calendar の使用法
Google Documents List Data API の使用法
Using Google Health
Google Spreadsheets の使用法
Google Apps Provisioning の使用法
Google Base の使用法
Picasa Web Albums の使用法
YouTube Data API の使用法
Gdata の例外処理
Zend_Http
導入
Zend_Http_Client - 高度な使用法
Zend_Http_Client - 接続アダプタ
前バージョンからの移行
Zend_Http_Cookie および Zend_Http_CookieJar
Zend_Http_Response
Zend_InfoCard
導入
Zend_Json
導入
基本的な使用法
Zend_Json の高度な使用法
XML から JSON への変換
Zend_Json_Server - JSON-RPCサーバー
Zend_Layout
導入
Zend_Layout クイックスタート
Zend_Layout の設定オプション
Zend_Layout の高度な使用法
Zend_Ldap
導入
API概要
利用シナリオ
ツール
Zend_Ldap_Nodeを使用してLDAPツリーへのオブジェクト指向アクセス
LDAPサーバから情報を取得
LDIFへ、または、からのLDAPデータシリアライズ
Zend_Loader
ファイルやクラスの動的な読み込み
The Autoloader
Resource Autoloaders
プラグインのロード
Zend_Locale
導入
Zend_Locale の使用法
正規化および地域化
日付および時刻の扱い
サポートするロケール
以前のバージョンからの移行
Zend_Log
概要
ライター
フォーマッタ
フィルタ
Zend_Mail
導入
SMTP 経由での送信
SMTP 接続による複数のメールの送信
異なる転送手段の使用
HTML メール
ファイルの添付
受信者の追加
MIME バウンダリの制御
追加のヘッダ
文字セット
エンコーディング
SMTP 認証
セキュアな SMTP トランスポート
メールメッセージの読み込み
Zend_Measure
導入
計測値の作成
計測値の出力
計測値の操作
計測値の型
Zend_Memory
概要
メモリマネージャ
メモリオブジェクト
Zend_Mime
Zend_Mime
Zend_Mime_Message
Zend_Mime_Part
Zend_Navigation
導入
画面
Containers
Migrating from Previous Versions
Zend_OpenId
導入
Zend_OpenId_Consumer の基本
Zend_OpenId_Provider
Zend_Paginator
導入
使用法
設定
高度な使用法
Zend_Pdf
導入
PDF ドキュメントの作成および読み込み
PDF ドキュメントへの変更内容の保存
ページの操作
描画
Interactive Features
ドキュメントの情報およびメタデータ
Zend_Pdf モジュールの使用例
Zend_ProgressBar
Zend_ProgressBar
Zend_Queue
導入
使用例
フレームワーク
アダプタ
Zend_Queueのカスタマイズ
Stomp
Zend_Reflection
導入
Zend_Reflectionサンプル
Zend_Reflectionリファレンス
Zend_Registry
レジストリの使用法
Zend_Rest
導入
Zend_Rest_Client
Zend_Rest_Server
Zend_Search_Lucene
概要
インデックスの構築
インデックスの検索
クエリ言語
クエリ作成用の API
文字セット
拡張性
Java Lucene との相互運用
応用
ベストプラクティス
Zend_Server
導入
Zend_Server_Reflection
Zend_Service
導入
Zend_Service_Akismet
Zend_Service_Amazon
Zend_Service_Amazon_Ec2
Zend_Service_Amazon_Ec2: Instances
Zend_Service_Amazon_Ec2: Windows Instances
Zend_Service_Amazon_Ec2: Reserved Instances
Zend_Service_Amazon_Ec2: CloudWatch Monitoring
Zend_Service_Amazon_Ec2: Amazon Machine Images (AMI)
Zend_Service_Amazon_Ec2: Elastic Block Stroage (EBS)
Zend_Service_Amazon_Ec2: Elastic IP Addresses
Zend_Service_Amazon_Ec2: Keypairs
Zend_Service_Amazon_Ec2:リージョンおよび利用可能ゾーン
Zend_Service_Amazon_Ec2: Security Groups
Zend_Service_Amazon_S3
Zend_Service_Amazon_Sqs
Zend_Service_Audioscrobbler
Zend_Service_Delicious
Zend_Service_Flickr
Zend_Service_Nirvanix
Zend_Service_ReCaptcha
Zend_Service_Simpy
導入
Zend_Service_StrikeIron
Zend_Service_StrikeIron: バンドルされているサービス
Zend_Service_StrikeIron: 応用編
Zend_Service_Technorati
Zend_Service_Twitter
Zend_Service_Yahoo
Zend_Session
導入
基本的な使用法
高度な使用法
グローバルセッションの管理
Zend_Session_SaveHandler_DbTable
Zend_Soap
Zend_Soap_Server
Zend_Soap_Client
WSDLアクセッサ
自動検出
Zend_Tag
導入
Zend_Tag_Cloud
Zend_Test
導入
Zend_Test_PHPUnit
Zend_Test_PHPUnit_Db
Zend_Text
Zend_Text_Figlet
Zend_Text_Table
Zend_TimeSync
導入
Zend_TimeSync の動作
Zend_Tool_Framework
導入
CLIツールの使用
アーキテクチャ
Zend_Tool_Frameworkを利用してプロバイダを作成する
出荷されたシステムプロバイダー
Extending and Configuring Zend_Tool_Framework
Zend_Tool_Project
導入
プロジェクトを作成
Zend Toolプロジェクトプロバイダー
Zend_Translate
導入
Zend_Translate のアダプタ
翻訳アダプタの使用法
ソースファイルの作成
翻訳用の追加機能
Plural notations for Translation
以前のバージョンからの移行
Zend_Uri
Zend_Uri
Zend_Validate
導入
標準のバリデーションクラス群
バリデータチェイン
バリデータの書き方
検証メッセージ
Zend_Version
Zend Framework のバージョンの取得
Zend_View
導入
コントローラスクリプト
ビュースクリプト
ビューヘルパー
Zend_View_Abstract
以前のバージョンからの移行
Zend_Wildfire
Zend_Wildfire
Zend_XmlRpc
導入
Zend_XmlRpc_Client
Zend_XmlRpc_Server
Zend Framework のシステム要件
導入
Zend Framework PHP 標準コーディング規約
概要
PHP ファイルの書式
命名規約
コーディングスタイル
Zend Framework Documentation Standard
Overview
Documentation File Formatting
Recommendations
Zend Framework MVC アプリケーションのために推奨されるプロジェクト構造
概要
推奨されるプロジェクト・ディレクトリ構造
モジュール構造
リライト設定ガイド
Zend Framework Performance Guide
導入
クラスの読み込み
Zend_Dbパフォーマンス
国際化(i18n)とローカライズ(l10n)
ビューのレンダリング
著作権に関する情報