日記
blogmap新着全文検索 (13:51)Edit

2004/4/16

というわけで、新着全文検索を復活。データ収集先サイト（blog）と、そこでリンクを張られていたサイト（news）でそれぞれ別に検索できるようにしました。Estraierって同じディレクトリに一つのCGI設定ファイルしかおけないのかな？　まあいいけど。

随時収集しているデータについて、毎日朝1回だけindexを生成しています。んで、リアルタイム性はあまりありません。あと、更新されたサイトはどんどんデータが上書きされていきますし、データを取得してからある程度（3日ほど）経ったデータはばりばり削除していきます。

というわけで、とても狭い範囲（blog界隈およびそこで話題になったニュース）と狭い期間（更新されて、もしくは話題にされて3日以内）に対して全文検索をかけてみたいという方はご利用ください。

2004/3/12

「ベイジアンなRSS Aggregator from blog.bulknews.net」で書いた「blogmapにもなにかその系統（記事中に含まれる特徴的なキーワードを利用する）の機能をつけてみようかなー」というネタ。一番ひねりがない機能をつけてみた。単にクロールしたページにインデックスを張って全文検索するだけ。しかもEstraierを試しに使ってみたりしたら、応用の仕方（独自UIを作る方法）がよくわからなかったりして、UIまで既成のもののまんまだし。Estraierで自前のUIから検索機能だけを使う（コマンドラインとかでもいいけど）方法ってないのかな。なければやっぱりNamazu＋Chasenにして、PHP用のNamazuモジュールでも試しに使ってみようかな。

2004/3/13

いろいろ試行錯誤をした結果、なんとかそれなりに使えるようになったかな。

Namazuに移行しようかとindexを作ってみたんだけど、やっぱりEstraierのrelatedとかdetailとかの機能に魅力を感じたんで、できる限りEstraierで行く方針に。でも、Estraierには専用のCGI以外の検索クライアントがないっぽいし、専用CGIも見た目のカスタマイズ以外はほとんどできない。

一番痛いのはローカルで別名をつけたファイルに対してindexを張っておいて、検索結果には動的にエイリアスの元URLを表示する、ってことができないこと。リダイレクタを介したりすればリンクの解決自体は何とかなるけど、検索結果とかにリダイレクタのURL文字列が表示されるってのはちょっと我慢ならない。

ローカルで別名をつけるのをやめて、URLをurlencodeしたファイル名を使えば、decurlオプションを使ってなんとかなるかなーと思ったんだけど、そっちはそっちで別の問題が生じた。というのは、index生成コマンドのestindexが、長いファイル名のファイルが大量にあるときに全部のファイルを見てくれない。数千ファイルあるディレクトリに対してestindex registerをやっても250ファイルくらいしかindexが作られなかった。なんとなくファイル一覧を保持するバッファの制限とかがあるんじゃなかろうか（ソースは読んでない）。findと組み合わせたりいろいろやってみてもだめだったんで、URLをurlencodeしたファイル名を使う方法もあきらめ。

で、結局PHPでプロキシーを作ってestsearch.cgiにプロキシー経由アクセスし、ブラウザに返す前にリダイレクタのURLを元々のURLに置換して返す、というローテクというか強引な方法を採用。なんかあほらしい気がするけど、ひとまずほかの方法が思いつかないし。php4_namazuもインストールしたから、単に全文検索機能だけならそっち経由でもいけるんだけど。

あああと、Estraierのindex生成が速いのは対象のファイル数がある程度少ない間だけみたいだ。数千ファイルを越えたらNamazu＋kakasiよりもずいぶん遅くなってしまった。現状でこのくらいindex生成の負荷が高いとなると、安定運用させるためのバランスを取るのが結構大変そうだな。この機能だけのために1台専用サーバーが必要なくらいかも。

2004/3/14

あれー、なんかindexが壊れてた。ちゃんと二重化して更新しているし、logには正常終了した形跡が残っているんだけどなー。よくわからん。ひとまずデータ量をできるだけ削減する方向に設定を変更して、最初からもう一度回してみよう。

2004/3/16

なんとかそれなりに回るようになったかな。でもさすがに運用コストが高いなー。取得してから24時間経過したドキュメントは破棄しているんだけど、それでも現時点で15000件くらいはインデクシング対象に入っているし、まだまだ増えていきそうだしなー。常設できるバランス点を見つけることができるかなー。

多少なりとも負荷を減らすために、今まで内部でestsearch.cgiを使っていたところを、estserver（専用検索サーバー）を使うように切り替えてみた。それなりに負荷は減っただろうけど、インデックス更新にかかっている負荷を考えると、この程度の対処じゃあんまり意味がないかもなー。現時点ではさほど検索を使っている人が多いとは思えないし。

今のところあまりこの機能を使うあてが思いつかないんだけど、唯一related検索はちょっと楽しい。related検索ってのは、bulkfeedsでいうところのSimilaritySearchみたいなもの。検索結果の最後の方にある「related」ってリンクをたどると、似た話題を扱っているページをたどることができる。なんとなく似たような趣味のページを探すときに使えるかも。

2004/4/14

blogmap新着全文検索は、index更新負荷があまりに大きくなりすぎて、ほかに影響が出始めたんで止めちゃいました。indexを分割して復活しようかと思ってたんですが、なんかあんまりいい感じにならなそうなんで、そのまま放置中です。

というわけで、現在blogmap新着全文検索は死んでます。うまい方法（それなりの負荷で、それなりに使える情報が得られる運用パターン）を思いつくまでたぶん復活はなさそうな感じです。

2004/4/15

昨日、 >>というわけで、現在blogmap新着全文検索は死んでます。うまい方法（それなりの負荷で、それなりに使える情報が得られる運用パターン）を思いつくまでたぶん復活はなさそうな感じです。 とか言っておきながら、なんとなくめどがついたかも。

Estraierのindex作成処理を観察してみたところ、indexのファイルサイズ（対象ドキュメント数）がある程度以上大きくなると、速度が急激に遅くなるようだ。ってことはEstraierのドキュメントにも書いてあるんだけど、ドキュメントに書かれている「数万件」って目安は、想定マシンパワーか運用パターンがずいぶん俺とは違っているっぽい。

毎日1万件程度更新される1万件オーバーのドキュメントに対して、Celeron 1.8GHz/512M RAM程度のマシンで、他にもたくさんプロセスが走っているのを妨げない程度にindex生成を実行するとなると、一度に作成するindexの対象ドキュメントは1000件程度に抑えた方が良さそうだ。

ちなみにEstraierでindexを作成する場合の負荷ってのは、

  • ある程度巨大になったindexファイルに対して登録作業を行う
  • index更新作業が終わった後にファイルシステムにsyncをかける

って二つの要素が大きいようで、特に後者はindexサイズが大きくなるとものすごく莫大な負荷になる模様。

幸いEstraierには、大量のドキュメントを指定数以内に分割してindexを作成し、最終的に一つのindexにmergeするスクリプト（estautoreg）が用意されているんで、それのunit（1度に対象とするドキュメント）数を変更すれば、そのあたりがずいぶん調整できる。

1万件弱のドキュメントに対してindexを作成した場合、分割せずに実行しようとすると3時間かかっても完了しなかったけど、512件ごとに分割して作成した場合は、1時間以内で完了した。作成中にかかる負荷もずいぶんましな模様。

もうちょっと状況を見てみないとわからないけど、現状程度だったらそこそこの頻度（1日1〜2回程度）でindex更新かけてもなんとかなるかもな。

Published At2004-03-12 00:00Updated At2004-03-12 00:00