morit****@razil*****
morit****@razil*****
2005年 8月 15日 (月) 13:28:29 JST
> できれば、oldvalue=NULLで、常にnewvalueを指定できるように > なっているとありがたいのですが、その方法はだめなのでしょうか? 正確なoldvalueが必要な理由を説明します。。 更新処理が可能なデータベースや全文検索エンジンは通常、 単語や文字要素をキーとしてレコード識別子のリストを取得するファイルと、 レコード識別子をキーとしてレコードの内容を取得するファイルと、 を備えています。 前者をインデックスファイル、後者を文書ファイルと呼ぶことにします。 更新処理を行う時には、更新前の文書の内容と、更新後の文書の内容とを比較し、 差異が発生した単語(文字要素)に該当するインデックスファイルの箇所を更新します。 例えば、文書Dの内容が、 更新前 "a b c d e f" 更新後 "a b c g h i" だとした場合、インデックスファイルのd, e, fに該当する箇所から文書Dの情報を削除し、 g, h, iに該当する箇所に文書Dの情報を追加するわけです。(a, b, cはそのままです) もし更新前の内容を無視して、新規追加時と同様にa, b, c, g, h, iの情報をインデックスに 登録すると、更新処理後、本来ヒットしてはならないはずの d, e, fで検索したときに、 文書Dがヒットしてしまいます。 これが更新前の内容が必要な理由です。 通常のエンジンでは、更新前の文書の内容を、自前の文書ファイルから取得しますが、 sennaはインデックスファイルのみを管理し、文書ファイルを自前では持っていないために ユーザ側で文書ファイルを管理し、updの引数に更新前の内容を渡すことが必要になります。 sennaで敢えてこうした構成を取っているのは、特にDBMSへの組み込みを想定した場合、 エンジンが自前で文書ファイルを持っていると、DBMSが元々持っている文書ファイルと 同様の内容を冗長に管理することになり、メモリやディスク等の資源を無駄に 消費してしまうのを避けるためです。 とは言え、文書ファイル管理機能をエンジンが持っていないとユーザの負担が増えて しまうのは事実です。将来はオプションとしてsenna内部での文書ファイル管理機能を 追加するかも知れません。 蛇足ですが、文書ファイルの管理は、インデックスファイルの管理と比べると容易であり、 様々な実装の選択肢があると思います。 江渡さんの応用例ですと、 ./test/*.txt に置かれた原本ファイルのコピーを ./test/.cache/*.txt に作成し、インデックスの更新と同時にコピーし直す、といった実装もアリだと思います。 ファイルのコピーを作成する分、ディスク領域を冗長に消費しますが、 エンジン自身が文書ファイルを管理する場合のリソース消費と比較して 実はそれほど大きな差異はないと思います。 -- morita
