| Su | Mo | Tu | We | Th | Fr | Sa |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
Webサーフィンしてたら面白いモノを見つけた。NAMAANの中身を詳説した卒業論文である。NAMAANは最近山ほど公開されているblog検索エンジンの一つで、新しく投稿されたblogが検索結果に反映されるまでの時間が最短1分と短いことをアピールポイントにしている。NAMAANを作っているのはアフィリエイトプログラム「電脳卸」をやっているウェブシャークという会社で、この会社に技術者なんて居るのかなあよくblog検索エンジンなんて作るなあと思っていたんだけど、学生が作っていたんだ。
論文の筆者の「大崎健吾」という名前に覚えがあり、ceekz氏に「ほら前に新宿でしゃぶしゃぶ食べたことがあるじゃないですかあの時に大崎健吾っていう立命館の学生が来ませんでしたっけ」と聞くとその通りとの仰せ。おお、オフラインで合ったことがあるとは。あの時の彼がこんなことをやっていたんだとか思いながら論文を拝読させていただきました。非常に面白かった。
以下、論文の概要について簡潔にまとめる。より詳しく知りたければ論文のpdfがWebにあるのでそちらを参照のこと。一通り読めばNAMAANの中身はだいたい分かるようになっています。ちなみに僕の作った「もぶろげっと」の中身について書いた論文が来月(2006.6)の電子情報通信学会論文誌(D-I)に載るので、こういうのに興味がある人はぜひそちらも参照して頂きたい、などと宣伝をしつつ。
構成図は以下。
処理の流れは以下。まず、直近に更新されたblogのリストをpingサーバから取得する。続いてリスト内のblogからRSSを収集する。収集したRSSからエントリー(blog記事)のURLのリストを取り出し、HTML文書を収集する。エントリーのHTML文書から広告等を削除し、本文のみを残し、Namazuによりインデックスを作成する。この際、複数台のマシンにインデックスを分散して持つということをしているがこれについては後述する。ユーザが検索インタフェースにアクセスし、検索したいキーワードを打ち込むと、インデックスに対して全文検索を行い、結果を時刻順に並べて提示する。
システムで使っているハードウェアは以下。
クローリング対象となるblogのリストはpingサーバを定期的に巡回することにより取得する。システムではRSSを取得・解析することによってblogの更新を判別するが、pingサーバから得られるのはblogのトップページのURLのみであるため、トップページを取得し、linkタグを解析することによってRSSのURLを取り出す。この際、blogごとにトップページのURLとRSSのURLをデータベースに保存する。また、RSSを吐かないblogはシステムの処理対象とはしない。
blogには更新頻度に差があるため、blogごとに更新をチェックする間隔を設定している。初期値として24時間を与え、以後、クローリングの度に新しいエントリーがあれば1.5倍、なければ0.5倍することで間隔を調整する。
個々のblogへのクローリングとしては、まずRSSを取得し、新着エントリーがあればそのHTML文書を取得する。取得したHTML文書からは本文の抽出を行う。本文の抽出にはdescription要素とのマッチングおよび同じblogから収集されたHTML同士の比較をしている。
クローラは自作のものを使っている。実装言語はperl。
インデックスの作成にはNamazuを使っている(ただし、論文中では将来的にHyper Estraierへの移行を予定していると述べられている)。また、インデックスを複数台のマシンの分散して保持している。
上図の通り、システムの全文検索部分は、インデックスを持ち、また自分の持つインデックスに対して全文検索を行う「検索サーバ」と、複数台の検索サーバに検索要求を出し、その結果をマージする「検索ゲートウェイ」から構成される。また、検索結果は検索ゲートウェイサーバによってキャッシュされる。
システムでは、検索結果の並べ方として時刻順のみを提供し、スコア順を提供していないが、これはインデックスを分散させているため。namazuはTF/IDFにより文書をスコアリングする機能を持つが、IDFの値が文書集合(インデックスに登録された全文書)に依存するため、異なるインデックス間でTF/IDF値を単純に比較することはできず、よってスコア順で検索結果を並べることは無理。
論文中に明示的に書かれているわけではないが、おそらく検索サーバでの全文検索にはnamazuのパッケージに添付されているCGIプログラムを、検索ゲートウェイでは自作のプログラムを使っていると思われる。
AND検索、OR検索、NOT検索、フレーズ検索を利用可能。また、検索結果をRSSで受け取ることもできる。blog検索エンジンとして、ごく標準的な検索機能を揃えている。
blog検索エンジンとしては非常にオーソドックスな構成で、素直に設計したらこうなるだろう、というものであると思う。
一つ気になるのはバックグラウンドにnamazuを使っているにも関わらずKWIC(キーワードの出現位置の周辺を要約として提示すること。代表例はgoogleのWeb検索)の機能を持っていることで、確かnamazuはKWICをサポートしていなかったと思うのだけど、どうやってるんだろう。自分で実装したなら素晴らしい。
また、NAMAANでは「最短1分で検索結果に反映」ということを売りにしているが、この構成で本当にそれが実現できるのかは、似たようなシステムを作った経験から、疑問に感じる。インデックスの分け方にも依るのだろうが、namazuのインデックス作成は他の全文検索エンジンに比べても遅いし、クローリングの方法にも特に工夫があるわけでもない。この構成では、他のblog検索エンジンに比べても、インデックスへの反映速度が優れているとは思われない。
以上、僕の読解力・理解力の低さから誤読している箇所があったら申し訳ありません。

