ホーム ＞ HTMLに役立つヒント＞
全文検索ソフトについてホーム ＞ HTMLに役立つヒント＞
全文検索ソフトについて
全文検索システム（エンジン/ソフト）の解説というか基礎知識です。全文検索システムを選ぶときに知っておいた方がいいと思うことが書かれています。
あちこちでいってますが、僕はサーバについてもperlについてもシロートなので、このページには間違いが含まれているかもしれません。
2001/8/7作成。
ホームページをやっているとほしくなるものとしては、まずは訪問者をカウントするカウンター、次に訪問者とコンタクトをとるための掲示板システム、さらにすすんで全文検索ソフト（全文検索システム、全文検索エンジン、サーチエンジンともいうらしい）という順番だろうと思います。
全文検索システムの用途や規模は人によってさまざまで、掲示板の発言内容や過去ログを検索させたいとか、自分のホームページの中から必要なhtmlに一発でたどり着きたいとか、僕のようにデータの中から条件に該当するものを拾い出したいとか。
てなわけで僕の目的は「コンパクトカメラデータ」に効率的な全文検索機能を付けることです。現時点でコンパクトカメラのデータは600を越していて、個人用途としてはやや規模が大きくなりつつあります。小規模と中規模の間にいる感じで、全文検索システムの選定に苦労しています。このページを含む「HTMLに役立つヒント/全文検索システム編」は、その副産物です。
検索システムといっても、いろいろと種類があります。最初はこれがわからなかった(^^; 検索エンジン＝全文検索ソフトだと思っていたんです。
gooやYahoo!も検索システムの一つなんですね。こんな高機能のものは必要ないし、んじゃ、分類するとどんな種類のものがあるのか、ちょっとやってみました。あくまで自分流の分類です。
速度 目的 規模 タイプ 具体例 高
速
↑
↓
低
速web検索サービスの提供（検索エンジン） すんげー大規模 ロボット型 goo、googleなど ディレクトリ登録型 yahooなど 中・小規模 スクリプト言語・ディレクトリ登録型 スマン、いろいろいあるけど該当ソフトは絞り込んでない<(_ _)> 例：ギャラリーリンク
簡易データベースでもある。自動登録型リンク集などが代表例。高
速
↑
↓
低
速サーバ内検索（全文検索エンジン） 大規模・中規模 コンパイル言語・インデックス作成型 NAMAZUなど 中規模・小規模 スクリプト言語・インデックス作成型 msearch、Splendid Search、KISS-Search、pnamazuなど 小規模 スクリプト言語・grep型 wwwsrch、WASearchなど
こんなんでました。目的で大きく分けると、web検索サービスを提供しようとするもの（検索エンジン）と、自分のサーバ内を検索しようとするもの（全文検索エンジン）に分けられると思います。大分類では両者とも「検索エンジン」になるらしいです。
web検索エンジンの方は、gooなどのタイプはまずシロートの手に負えません。サーバからして違います。外国ものではスパイダー（ロボットのこと）つきでこの手のフリーソフト（言語を忘れた<(_ _)>）が出回っているのを見たことがありますが、スパイダーの巡回先を限定しないと個人ではまず無理でしょう。
一方のディレクトリ型でスクリプト言語で書かれたものは、Yahooもどきを提供しようといういわば簡易データベースのようなものです。個人のページでデータベースや限定された検索サービスを提供するためのものです。登録型データベースなどとも呼ばれます。自己登録型のリンク集などで使われているのを目にします。ここではいずれも目的が違うので取り上げません。
僕ら個人ユースで、自分のホームページ内を検索させようという用途には、上の表で言う「サーバ内検索」ということになります。
サーバ内検索を分けると、サーバ1個丸ごと検索するような大・中規模なものと、サーバの中の一領域だけを検索するような中規模・小規模なものとに分類できるでしょう。ただ、大規模・中規模・小規模をどこで区切ればいいのか、正直わかんないっす。
作成言語によって処理スピードがちがうので、現状に合わせてここで区切るといいでしょう。C言語など、コンパイルして使うものはコンパイル済みですから処理スピードは速いです（そのかわり設置が難しい）。
perlなどスクリプト言語で書かれたものは、いちいちスクリプトを翻訳しながら処理していきますから、処理スピードは遅くなります（そのかわり設置は簡単）。
次に、インデックスを作って検索するタイプ（インデックス型）と、検索の都度、検索対象ファイルの中味をすべて調べていくタイプ（grep型）とに分けられます。
検索対象となるファイルの要素をあらかじめ抽出しておき（このファイルをインデックスという）、このファイルを検索するタイプをインデックス型といいます。インデックス型は検索効率がよく、高速に検索できます。ただし、対象ファイルそのものではなく、インデックスを検索しますから、インデックスを作った後に対象ファイルに変更があると、内容にズレが生じます。ファイルに変更があるたびにインデックスを作り直さなくてはいけません。このため、検索スピードだけでなく、インデックスの更新のしやすさは大事なポイントとなります。
また、インデックスタイプはインデックスを作成する部分と、それを検索する部分の2つで構成されるのが普通です。インデックス型には高度な日本語形態素解析を使ったものが多く、このアルゴリズムとその辞書のできいかんで効率が大きく違うそうです。
まとめると、コンパイル言語でインデックスタイプがもっとも高速、次にスクリプト言語でインデックスタイプ、もっとも低速なのがスクリプト言語ですべてなめるタイプ（grep型）ということになります。
| コ ラ ム |
|
余談ですが、スクリプト言語では、そのうちRubyで書かれたものもでてくるんじゃないでしょうか。そのうちそのうち、サーバサイドJAVA（サーブレット）で書かれた検索システムもでてきそうです。ちょっと興味あります（ああ、イカン。これでは全文検索フェチではないか）。
検索対象ファイル数が多い場合は、処理速度の速いコンパイル言語・インデックス型が有利です。代表選手のNAMAZUはほんっっっとに高速です。
しかし、NAMAZUはサーバシステムにインストールするため、サーバの管理者権限（SU権限/root権限）が必要になります。僕らのようにプロバイダのサーバ領域にホームページを持つ身としては、はなはだうらやましい存在なんですね。プロバイダの自分の領域にインストールすることも可能ですが、そのためには相当高い技量が必要になります。
最近、無目的に「ともかくNAMAZUを設置したい」という人が増えているように思います。用途・規模・あなたの技量をふまえて、本当にNAMAZUが必要なのか考えた方がいいと思います。
実際、対象ファイルが100程度しかないのに、わざわざローカルマシンにNAMAZUをインストールし、サーバではpnamazuを使って検索しているという例を知っています。この程度ならgrepタイプで十分です。ローカルマシンでINDEXを作成し、それをFTPでアップロードするという管理の手間を考えると、無駄な努力といえます。
ってわけで僕のようなプロバイダユーザーならスクリプト型から選ぶとよいでしょう。たいていperlで書かれていて、インデックス型とgrep型があります。コンパイル言語・インデックス型に比べるとスピード的に見劣りします。
でも、インデックス型ならスクリプト言語でもかなり高速です。せいぜい1日数十回程度の検索頻度でしょうから、サーバ負荷の点からも合格でしょう。
grep型も小規模なら実用的です。200、300程度のファイル数であれば、これで十分のはずです。サーバの負荷状況によってはもっとファイル数が多くても対応できると思います。
僕は現在、コンパクトカメラ掲示板検索はNAMAZU（対象ファイル数約12,000。検索回数300回/日）、コンパクトカメラデータはmsearch（対象ファイル数667。サブシステムとしてwwwsrchも併用。データ検索用はmsearch、wwwsrch合わせて検索回数20〜30回/日、一覧表示用はmsearchで検索回数30〜50回/日）、コンパクトカメラ用語辞典、おもちゃデジカメはwwwsrch（対象ファイル数は数十ファイル。検索回数10回/日）と、対象ファイル数・検索頻度によって使い分けています。
僕が今一番興味を持っているのは、スクリプト言語・インデックス型の検索エンジンです。中・小規模向きと思われる、これらスクリプト言語・インデックス型の特徴をそれぞれあげて比較してみます。あ、pnamazuについては「検索テスト」や「マニュアルに書いてないNAMAZU」を参照してください。
| 分類 | 項目 | pnamazu | Splendid Search 1.7β2 | msearch 1.3 |
| 基本機能 | 検索スピード | ○ | △ | ○ |
| 対象ファイルの種類 | ◎ 拡張子なし、txt、HTML、PDF、ワード、一太郎、エクセルetc （付属のtiny_mknmz.cgiを使った場合はplain text, html, mailのみ） |
△ HTML （txtについては未テストです） |
△ HTML （txtについては未テストです） |
|
| スケーラビリティ（ファイル数が多くなった場合に対応できるか） | △ | × | △ | |
| 導入 | 設置の容易さ | △ 手元にローカルサーバがいること、NAMAZUをインストールする必要があること。（pnamazuにはperlで書かれたインデクサが付属するようになりましたが、スピードからして本家NAMAZUでインデックスした方が断然高速です） | ○ スクリプトファイルの設置のみ。 | ○ スクリプトファイルの設置のみ。 |
| 運用 | インデックスの手軽さ | △ 手元で作成したインデックスをプロバイダのサーバにアップロードしなくてはならない。 | △ インデックスはブラウザから作成・更新可能。ただしスピードが遅い。 | ◎ インデックスはブラウザから作成・更新でき、スピードも速い。telnetから作成・更新することも可能。手元のマシンで作成し、アップすることも可能。 |
具体的にもっと詳しく知りたいという方は、「HTMLに役立つヒント」に戻って、各導入記を読んでやってください。NAMAZUをはじめ、いくつかの全文検索システムの導入記があります。
「検索テスト」ではこれまでのところ、「検索スピード」を主眼としてテストをしていますが、本来、検索結果が妥当かどうかまで含めてテストするべきだろうと思っています。ヒットしたファイルが、その人が見たがっていたファイルかどうかという問題ですね。今後の課題です。
本来、サーバ負荷は我々プロバイダ加入者ではなく、プロバイダの管理者自身が判定することです。サーバの負荷状態を判断するには、多くの要因が存在しています。回線状態、アクセス状況、時間帯による違い、cgiの処理時間、etc。すべてを見てトータルに判断するのが「サーバ負荷」です。どれか一つの要因を取り出して判断することはできないのです。
「わしらプロバイダユーザーはテキトーにcgi設置してりゃええねん。負荷が高くなったら、それはサーバ管理者が見ていて警告してくるじゃろ」という考え方もあります。実際、こちらでサーバ負荷を把握しようがないですから、判断はサーバ管理者にゆだねる以外にありません。
しかし、現実にサーバ負荷を高めるcgiを設置する以上、我々プロバイダ利用者としても無関心ではいられません。サーバの負荷をそれほど高くしない目安のようなものがあればいいのですが、前述のようにサーバ負荷はトータルで判断するものなので、一つの要因だけを取り出してもしかたない=>そんな目安はない、というのが現状です。
で、まるで全然まったくほんとーになんにも根拠はないのですが、僕は、cgi処理に1秒以上かかったり、1秒間に3〜5回以上cgiの操作が集中するような場合は、サーバ負荷が高くなっていると判断しても良いのではないかと思っています。
ここには2つの判断ポイントがあります。
一つはcgi自身の処理スピードで、1秒というのは甘すぎるかもしれません。0.5秒程度であればアクセス頻度が高くなる深夜でもなんとかいけそーかな、と思います。
もう一つはそのcgiの利用頻度です。1日に10回程度しか検索されないような場合、サーバ負荷にはほとんど関係ないと言っていいでしょう。反対に1日に何万回もアクセスされるようなら、検索スピードが0.1秒でもそうとう負荷が高くなっているはずです。
僕はよくcgiにCPU消費時間の表示やログの出力機能を自分で追加しますが、上のような利用状況を把握することが目的です。興味のある方はcgiを改造して、利用しているサーバで実行してみてください（オウンリスクでお願いします）。
全文検索関係の話題は「マニュアルに書いてない掲示板」でお願いします。
ホーム ＞HTMLに役立つヒント＞
全文検索ソフトについて