ホーム > HTMLに役立つヒント> 検索テスト
[改定日: 05/03/25 16:35] あなたはここへ来た、 24501番目の人です。(2001/8/2から)
いくつかの全文検索エンジン(perlで書かれたもの)をテストしています。いずれのCGIも改造版のため、オリジナルよりも時間がかかっているはずです。とくにwwwsrch.cgi、msearch.cgiの改造はかなりなものです。このページのテスト結果は「ここのサーバではこうだったのね」と、目安程度に考えてください。
また、「感想」についても、僕の目的が「コンパクトカメラデータの検索」という特殊なものであるため、日本語を検索させようという普通の目的と外れていますので、その点割り引いて読んでください。
各検索CGIの詳細については「HTMLに役立つヒント/全文検索システム編」をご覧ください。
なお、検索対象となっている「コンパクトカメラデータ」ページは、かなり頻繁にデータを更新しているため、下記のテストを追試しようとしても、すでにデータが変更されていると思われます。よーするに下のテスト通りにはならないはずです。KISS-SearchとSplendid Search、pnamazuのインデックス更新は、思い出したようにしかしてませんし。
|
2002/10/1にプロバイダがサーバマシンの入れ替え(ハード自体を入れ替えた)を行いました。したがって、第9回までのテスト環境と、それ以後のテスト環境は異なります。ご注意ください。 同時にCGIラッパーが導入され、KISS-Searchが動作しなくなってしまいました(;_;) |
とほほさんのwwwsrch.cgiは現在では3.13になっています。僕のページでは、長らく3.09をベースに改造したcgiを使っていましたが、いいかげんにバージョンが開いてきたので3.13ベースの改造品 macwwwsrch.cgi ver.3.13m0.10 を作りました。今回はこの改造品のテスト。
なお、この間のバージョンの違いはバグ取りによるもので、スピードがアップしたとはとほほさんはおっしゃっていません。単に僕がテストしてみたかったというだけですので誤解なきよう。
両者ともむちゃくちゃ改造してあるので、オリジナルのwwwsrch.cgiの方がスピードは速いはずです。この結果は目安と考えてください。
検索対象:コンパクトカメラデータディレクトリ
検索対象ファイル数:755ファイル
|
検索単語 |
macwwwsearch.cgi (とほほさんのwwwsrch.cgi3.09の改造版) |
macwwwsearch.cgi (とほほさんのwwwsrch.cgi3.13の改造版) |
|
| 1単語 | 性能表 | ヒット数:763※1 CPU秒:1.188 |
ヒット数:763※1 CPU秒:1.125 |
| 28mm/ | ヒット数:93 CPU秒:1.422 |
ヒット数:92 CPU秒:1.398 |
|
| 単焦点 | ヒット数:344 CPU秒:1.125 |
ヒット数:344 CPU秒:1.070 |
|
| 2単語 AND検索 |
28mm/ 単焦点 | ヒット数:43 CPU秒:1.094 |
ヒット数:43 CPU秒:1.141 |
| 3倍ズーム 現行品 | ヒット数:77 CPU秒:1.148 |
ヒット数:77 CPU秒:1.141 |
|
| 3単語 AND検索 |
28mm/ 単焦点 現行品 | ヒット数:23 CPU秒:1.211 |
ヒット数:23 CPU秒:1.219 |
※1しまった。検索させたいファイルは755だけなんですが、このディレクトリの中にmsearch.cgiのスキン見本用.htmlファイルがあったんだった。この見本用ファイルの分だけ増えてます。後ほど.htmlから.htmにファイル名を変更して検索しないようにしておきます。
結果はご覧の通り互角です。若干の違いはありますが、誤差の範囲でしょう。両方とも10回くらいテストして平均を取ると違いはなくなりそうです。
ASSが1.7β3にアップしました。
最初にテストしたときはASSは余分なhtmファイルも拾ってしまい、インデックス数は756あったため、正しくインデックスを作り直して再度テストしました。
なお、どちらもページあたり20件で検索しています。
また、参考のためβ2の時のデータも再掲しますが、対象ファイル数が異なっていますからあくまで参考値です。
検索対象:コンパクトカメラデータディレクトリ
検索対象ファイル数:729ファイル
|
検索単語 |
msearch.cgi 1.4 (Katsushi Matsudaさんのmsearch.cgiのconfig.dat変更版) |
Splendid Search1.7b3 |
Splendid Search1.7b2 |
macwwwsearch.cgi (とほほさんのwwwsrch.cgi3.09の改造版) |
|
| 1単語 | 性能表 | ヒット数:729 CPU秒:0.1015625 |
ヒット数:729 CPU秒:1.805 |
ヒット数:708 CPU秒:2.023 |
ヒット数:729 CPU秒:1.117 |
| 28mm/ | ヒット数:83 CPU秒:0.109375 |
ヒット数:96 ※1 CPU秒:0.664 |
ヒット数:93(93) CPU秒:0.859(0.898) |
ヒット数:83 CPU秒:1.305 |
|
| 単焦点 | ヒット数:325 CPU秒:0.1015625 |
ヒット数:325 CPU秒:1.203 |
ヒット数:318 CPU秒:1.438 |
ヒット数:325 CPU秒:1.031 |
|
| 2単語 AND検索 |
28mm/ 単焦点 | ヒット数:37 CPU秒:0.1328125 |
ヒット数:40 ※1 CPU秒:1.273 |
ヒット数:38(38) CPU秒:1.562(1.484) |
ヒット数:37 CPU秒:1.008 |
| 3倍ズーム 現行品 | ヒット数:73 CPU秒:0.109375 |
ヒット数:164 ※2 CPU秒:1.422 |
ヒット数:154 CPU秒:1.641 |
ヒット数:73 CPU秒:1.016 |
|
| 3単語 AND検索 |
28mm/ 単焦点 現行品 | ヒット数:19 CPU秒:0.140625 |
ヒット数:22 ※1 CPU秒:1.289 |
ヒット数:73(18) CPU秒:1.195(1.523) |
ヒット数:19 CPU秒:1.203 |
※1で検索数が違っていますが、「28mm/」で検索しても、「/」を無視して「28mm」と解釈するためです。
※2で検索数が著しく違っていますが、これはASSが内部で「3」「倍ズーム」「現行品」と分解して検索しているためです。
ASSはβ2で指摘したストップワードについて、ストップワードは無視されるようになりました。上記のように「28mm/」と検索しても「28mm」と検索しても同じ結果がでます。つまり、「/」を無視しています。「/」を検索してもヒット0となります。
てーことは、「検索できない記号が存在する」というわけで、検索できないものは何か、ユーザーに教える必要があるでしょう。
ストップワードについてはyabitsu.plの中に「# ストップワードの扱い(0:区切りと見なさない、1:区切りと見なす)」という設定があり、デフォルト通り1のままです。また、全体にβ2より高速になっているようです。しかし、ほとんどの検索で1秒以上の時間を要しています。もしやと思って、急きょとほほ氏のwwwsearchのテストを追加しました。
結果は思った通り、ほとんどの検索でwwwsearchの方が速いです(テストではver3.09ベースの改造版を使用しています。現在wwwsearchはver3.11にアップしています)。
う〜ん、なんか、ASSとwwwsearchの対決みたいになってしまった(^^;
msearch.cgiが1.4にバージョンアップしました。cgiに手を入れなくてもHTMLを知っていれば簡単に画面デザインを変更できるようになりました。画面データファイル(config.dat)は断りなしに再配布が可能ですから、いいデザインができたらお教えください。
ここでは検索スピードの点でこれまでの1.33とどれだけ違いがあるのか、テストしてみます。
ところで、「五郎とゴロー」ってウルトラQなんですけど、知らないだろうなぁ…。いいんですけど(^_^)
1.4の()内は表示されたままの数値です。桁が多いので小数点第4位を四捨五入したものを()の前に付記しています。()の後ろは1.3÷1.4で、どの程度速くなったかを表します。
参考としてpnamazuの最新版の結果も付記しました。インデックスには743のファイルが登録されています。インデックスにはnamazu(ver2.07)を使いました。検索の仕様に違いがあるため(第4回参照)、直接比較はできません。
検索対象:コンパクトカメラデータディレクトリ
検索対象ファイル数:729ファイル
|
検索単語 |
msearch.cgi 1.3 (Katsushi Matsudaさんのmsearch.cgiの改造版) |
msearch.cgi 1.4 (Katsushi Matsudaさんのmsearch.cgiのconfig.dat変更版) |
pnamazu 2001.12.01 |
|
| 1単語 | 性能表 | ヒット数:729 CPU秒:0.125 |
ヒット数:729 CPU秒:0.109(0.109375)1.15倍 |
ヒット数:729 CPU秒:0.414 |
| 28mm/ | ヒット数:83 CPU秒:0.281 |
ヒット数:83 CPU秒:0.102(0.1015625)2.75倍 |
ヒット数:100 ※1 CPU秒:0.227 |
|
| 単焦点 | ヒット数:325 CPU秒:0.125 |
ヒット数:325 CPU秒:0.117(0.1171875)1.07倍 |
ヒット数:329 CPU秒:0.273 |
|
| 2単語 AND検索 |
28mm/ 単焦点 | ヒット数:37 CPU秒:0.281 |
ヒット数:37 CPU秒:0.117(0.1171875)2.4倍 |
ヒット数:329 ※1 CPU秒:0.250 |
| 3倍ズーム 現行品 | ヒット数:73 CPU秒:0.133 |
ヒット数:73 CPU秒:0.102(0.1015625)1.11倍 |
ヒット数:158 ※2 CPU秒:0.375 |
|
| 3単語 AND検索 |
28mm/ 単焦点 現行品 | ヒット数:19 CPU秒:0.281 |
ヒット数:19 CPU秒:0.125(0.125)2.25倍 |
ヒット数:26 ※1 CPU秒:0.273 |
●感想
ver1.4ではいずれの検索でも0.2秒かかったものがありません。スゲー!「28mm/」「28mm/ 単焦点」「28mm/ 単焦点 現行品」で顕著にスピードアップしています。これは「英文字の混じった検索ではスピードアップ」の効果でしょう。英文字がキーワードに入っている場合はいずれも倍以上にスピードアップしています。
また、検索語数に関係なく2倍以上になっている点にも注目。「mserach導入記」ではこれとは別に特にスピードアップしたという「全角1文字の検索」と「英文字が含まれた検索」の比較をしていますので、あわせてご覧ください。「全角1文字の検索」も恐ろしくスピードアップしていることがわかります。
着々と弱点を克服しつつありますねー。もはや検索スピードの点ではなーんも心配する必要がないって感じです。が、Katsushi Matsudaさんはこれでも満足していないご様子。まだスピードアップする余地があるのかなぁ(?_?)
Afri Splendid Searchが1.7β2となりました。wwwsearch、msearchと対決させてみました。はたしてASSがどれだけ強化されているか、興味のあるところです。
次のような検索条件で検索しています。
・ASS 1.7β2 表示件数:20、検索対象:文書全体、ソート条件:URL、内容表示:一致箇所、検索方法:索引検索のみ
・msearch 1.3 表示件数:20
なお、Splendid Searchの対象ファイル数は.htmまで含んでしまうため733となっています。wwwsearchとmsearchでは.htmlのみのため706ファイルとなっています。また、wwwsearchは常に全件表示となりますのでその点不利です。
検索対象:コンパクトカメラデータディレクトリ
検索対象ファイル数:706ファイル ASSでは733ファイル
|
検索単語 |
macwwwsearch.cgi (とほほさんのwwwsrch.cgi3.09の改造版) |
msearch.cgi 1.3 (Katsushi Matsudaさんのmsearch.cgiの改造版) |
Splendid Search1.7b2 |
|
| 1単語 | 性能表 | ヒット数:706 CPU秒:0.969 |
ヒット数:706 CPU秒:0.125 |
ヒット数:708 CPU秒:2.023 |
| 28mm/ | ヒット数:80 CPU秒:1.242 |
ヒット数:80 CPU秒:0.242 |
ヒット数:93(93) ※1 CPU秒:0.859(0.898) |
|
| 単焦点 | ヒット数:313 CPU秒:1.023 |
ヒット数:313 CPU秒:0.125 |
ヒット数:318 CPU秒:1.438 |
|
| 2単語 AND検索 |
28mm/ 単焦点 | ヒット数:35 CPU秒:0.969 |
ヒット数:35 CPU秒:0.273 |
ヒット数:38(38) ※1 CPU秒:1.562(1.484) |
| 3倍ズーム 現行品 | ヒット数:66 CPU秒:1.047 |
ヒット数:66 CPU秒:0.109 |
ヒット数:154 ※2 CPU秒:1.641 |
|
| 3単語 AND検索 |
28mm/ 単焦点 現行品 | ヒット数:15 CPU秒:1.078 |
ヒット数:15 CPU秒:0.273 |
ヒット数:73(18) ※1、※2 CPU秒:1.195(1.523) |
●感想
ヒット数がずれるのは、対象ファイル数の違いによるものと、検索方式の違いによるものがあるようです。
※1 「28mm/ 単焦点」や「28mm/ 単焦点 現行品」ではヒット数は0となりました。ところが、試しに「単焦点 28mm/」「単焦点 現行品 28mm/」とすると表のようにヒットしました。語順によってヒットする/しないがあります。
マニュアル(インストールガイド)には「/」という文字はストップワードの一つとして取り扱われるとなっています。そのため「索引成分の対象外となります」となっているのですが、よーするに「/」は検索できないってことなんでしょうか? 追加でテストしてみました。()内が「28mm」でテストした結果です。やはり「/」は無視されるようですね。
このテストで発見しました。「/」がないと「28mm 単焦点」という語順でもヒットします。語順によってヒットする/しない現象は「/」がイタズラをしているわけです。1.6のユーザーマニュアル(manual.pdf)では、ストップワードは単に検索できないというように読めます。しかし、実際にはストップワードが検索語にはいると上記のように検索制限になりかねません。ストップワードが検索語句に入った場合、ストップワードを完全に無視するようにすべきではないでしょうか。1.7β2を使用する場合はこの点に注意が必要です。※2 「3倍ズーム 現行品」ではヒット件数のズレが大きすぎます。これは「3」「倍ズーム」「現行品」と分割されて検索される結果と思われます。試しに「3 倍ズーム 現行品」で検索すると、やはり154件でした。同様のことが「28mm/ 単焦点 現行品」の検索でも起こっていると思われます。
※2の問題は日本語の分解方法に関わることで、どちらがよいとはいえません。しかし、※1は、ストップワードが検索語句に入った場合の処理が不十分なようです。「1.7b2メモ」で言及している使い勝手の悪い部分もあり、「やはりβ版だなぁ」というのが率直な感想です。
なお、ASS1.7β2では、検索方法を「索引検索で絞り込み後、文書内容検索」にすると、インデックスを検索した後、該当ファイルをもう一度grep検索するため、β1の時のようにスピードはがた落ちします。
検索スピードからして、このサーバでは733ファイルというのはASSの実用限界のようです。また、インデックススピードも733ファイルで11分ほどかかっていることからして、全体としては小規模向けといえるでしょう。
grepタイプのwwwsrchとの比較でいうと、スピード的にはやや劣り、ソートの指定や内容表示の有無などが選択できる点で勝ります。
さて、今回はスコア表示をしてくれるというWASearchと定番wwwsrchの対決です。どちらもgrepタイプです。
検索対象:コンパクトカメラデータディレクトリ
検索対象ファイル数:667ファイル
|
検索単語 |
macwwwsearch.cgi (とほほさんのwwwsrch.cgi3.09の改造版) |
WASearch2.22 (鷲崎 弘宜さんのWASsearch.cgiのCPU時間表示・EUC改造版) |
|
| 1単語 | 性能表 | ヒット数:667 CPU秒:1.031 |
ヒット数:667 CPU秒:1.977 |
| 28mm/ | ヒット数:76 CPU秒:1.266 |
ヒット数:76 CPU秒:1.352 |
|
| 単焦点 | ヒット数:292 CPU秒:1.000 |
ヒット数:292 CPU秒:1.508 |
|
| 2単語 AND検索 |
28mm/ 単焦点 | ヒット数:32 CPU秒:1.008 |
ヒット数:32 CPU秒:3.102 |
| 3倍ズーム 現行品 | ヒット数:66 CPU秒:1.023 |
ヒット数:66 CPU秒:3.164 |
|
| 3単語 AND検索 |
28mm/ 単焦点 現行品 | ヒット数:13 CPU秒:1.008 |
ヒット数:13 CPU秒:4.102 |
キーワード数が1つの場合はwwwsrchに迫るスピードを持っています。スコアで順位付けまでやっているのですから相当の実力の持ち主です。が、ご覧のようにキーワードが複数になると3倍から4倍のスピードがかかるようになります。
さて、実はこれだけのテストではWASearchの特徴をうまく出せません。次にカテゴリをすべて「キヤノン」にして同様のテストをしてみます。macwwwsrchは以下のテストでキーワードに「キヤノン/」を付け加えています。
キヤノン+
検索単語macwwwsearch.cgi
(とほほさんのwwwsrch.cgi3.09の改造版)WASearch2.22
(鷲崎 弘宜さんのWASsearch.cgiのCPU時間表示・EUC改造版)1単語 性能表 ヒット数:39
CPU秒:0.852ヒット数:39
CPU秒:0.12528mm/ ヒット数:3
CPU秒:0.914ヒット数:3
CPU秒:0.102単焦点 ヒット数:16
CPU秒:0.922ヒット数:16
CPU秒:0.0942単語
AND検索28mm/ 単焦点 ヒット数:0
CPU秒:1.016ヒット数:0
CPU秒:0.2113倍ズーム 現行品 ヒット数:7
CPU秒:1.102ヒット数:7
CPU秒:0.1953単語
AND検索28mm/ 単焦点 現行品 ヒット数:0
CPU秒:1.133ヒット数:0
CPU秒:0.273
「WASearch導入記」にも書いたとおり、WASearchの場合は「カテゴリわけ=検索対象ディレクトリわけ」という構造になっています。カテゴリを指定するということは、検索対象ファイル数を少なくするということなのです。
上のテストで言えば、macwwwsrchが検索ごとに667ファイルを見て回るのに対し、WASearchはたった39ファイルしか見ていません。これがスピードの差となって現れています。
このように、カテゴリを分けて検索する場合、WASearchは圧倒的に有利な側面を持っています。そのような検索を前提としている場合はWASearchをお薦めします。
また、スコアによってソートされる点も見逃せません。スコアはキーワードの出現回数によって決められるようです。
なお、オリジナルのWASearchはSJISファイルを検索対象ファイルとしていますが、テストに使ったものは、EUCファイルを検索対象にするように改造してあります。僕のところのファイルが全部EUCなもんで(^^;
WASearchとの比較でいうと、全ファイルからの絞り込みで有利となります。コンパクトカメラデータの検索が目的なので、メーカーで絞り込むこと(カテゴリで絞り込むに相当)も、メーカーではなくカメラの性能で絞り込むこともあります。
ログを観察している限りでは、3:2くらいの割合で、性能から絞り込むケースが多いようです。同時にキーワードは簡単検索機能のおかげで複数設定されることがほとんどで、1キーワードだけというケースは少ないです。
というような現状を見る限り、うちの場合はmacwwwsrch有利ということになります。
ああ、ログって大事。
今回はwwwsrch、msearchとpnamazuの対決です。知らない人がいるかもしれないので、まずはpnamazuの簡単な解説から。
●pnamazuの使い方
NAMAZUは、インデックスをつくって検索するタイプの全文検索エンジンで、非常に高速、かつ比較的取り扱いが容易なことから現在主流となっています。
しかし、本家NAMAZUをサーバにインストールするには、通常su権限が必要になります。早い話、サーバの管理者グループでないとインストールできません。
プロバイダなどで、自分に割り当てられた領域にインストールすることも可能ではありますが、パッケージそのままでは成功率は低く、サーバ環境に合わせてカスタマイズしてインストールする必要があります。これにはかなりの技量が必要となります。
そこで登場するのがpnamazuです。本家NAMAZUは大きく分けてインデックスを作る部分と検索をする部分とがあります。pnamazuはperlで書かれた「検索部分」です。
手元にWindowsかMAC(OS Xが必要)があれば、そのマシンにサーバ環境を構築し、本家NAMAZUをインストールすることはそう難しくありません。
手元のマシンにNAMAZUをインストールして、このマシンでインデックスを作ります。そのインデックスとpnamazuをプロバイダの自分の割り当て領域にアップロードすると、本家NAMAZUと同様の検索が可能となります。この方法だと、サーバに本家NAMAZUをインストールするよりもはるかに楽に検索システムを構築できます。なんせインデックスとpnamazuを転送するだけですから。
●pnamazuの特徴
pnamazuは、perlで書かれているために(本家NAMAZUはCで書かれている)本家よりも低速です。
しかし、本家にはない検索機能も併せ持っていること(携帯電話モードまである!)、設置が本家より容易であることから利用者も多いことと思います。
反面、手元で作成したインデックスを、サーバにアップしなくてはならないという面倒な側面も持っています。本家NAMAZUはsu権限を持つユーザー=サイト管理者によって利用され、pnamazuはプロバイダを利用している一般ユーザーに多く使われているのではないかと推測します。
同時に、su権限を持つユーザーはかなり大規模なサイトを構築・検索させようとしているのに対し、pnamazuのユーザーは個人利用の、比較的規模の小さなサイトを検索させようとしていると思われます。●msearch登場
となると、僕のような個人ユーザーとしては、インデックスを作成した上でそれをアップしなくてはならないpnamazuより、サーバ上でインデックスを作れる他の高速検索システムがあれば、そっちの方がいいという選択肢もでてきます。
最近までそうした選択肢に魅力はなかったんですが、msearchの登場によって事情が変わりました。msearchは、本家NAMAZUのように何万件という規模の用途には向かないと思われますが、1300ファイル程度であれば高速に検索してくれます(msearch導入記参照)。個人規模であれば十分な実力を持っています。
で、pnamazuと比べて実際どうやねんっっっってわけでテストであります。あー、前ふりが長かった。
例によってテストに使用したのはすべて改造版です。msearchはオリジナルにいくつか機能を付け加えてあります。pnamazu(2001.06.27版)はCPU消費時間を出力するように改造してあります。当然無改造のものの方が速いはずです。
なお、pnamazuは手元のMACでNAMAZU2.0.5を使ってインデックスを作り、サーバにアップしました。
pnamazuは全件表示ができないため、両者ともページあたり20件の表示でテストしています。逆に、macwwwsrchは全件表示しかできません。このあたり不公平なテストです。
検索対象:コンパクトカメラデータディレクトリ
検索対象ファイル数:655ファイル
|
検索単語 |
macwwwsearch.cgi (とほほさんのwwwsrch.cgi3.09の改造版) |
msearch.cgi 1.21 (Katsushi Matsudaさんのmsearch.cgiの改造版) |
pnamazu 2001.0.27 |
|
| 1単語 | 性能表 | ヒット数:655 CPU秒:0.883 |
ヒット数:655 CPU秒:0.797 |
ヒット数:655 CPU秒:0.398 |
| 28mm/ | ヒット数:75 CPU秒:1.172 |
ヒット数:75 CPU秒:0.172 |
ヒット数:88 ※1 CPU秒:0.211 |
|
| 単焦点 | ヒット数:286 CPU秒:0.945 |
ヒット数:286 CPU秒:0.375 |
ヒット数:286 CPU秒:0.234 |
|
| 2単語 AND検索 |
28mm/ 単焦点 | ヒット数:32 CPU秒:0.852 |
ヒット数:32 CPU秒:0.109 |
ヒット数:35 ※1 CPU秒:0.250 |
| 3倍ズーム 現行品 | ヒット数:66 CPU秒:0.914 |
ヒット数:66 CPU秒:0.180 |
ヒット数:144 ※2 CPU秒:0.359 |
|
| 3単語 AND検索 |
28mm/ 単焦点 現行品 | ヒット数:13 CPU秒:1.078 |
ヒット数:13 CPU秒:0.117 |
ヒット数:16 ※1 CPU秒:0.242 |
※1 「/」などの記号は取りこぼすのが仕様である(本家NAMAZUも同様)ため「28mm/」ではなく「28mm」で検索しています。特に「/」という記号は正規表現の区切りとして用いられるため、なおさら無理な検索です。ちなみに「28mm/」で検索するとヒットは0となります。
※2 pnamazuでは「3倍ズーム」ではなく「3」「倍ズーム」と分かち書きされて検索されるためヒット数が異なる。
仕様の違いがあって、pnamazuにはちょっと不利なテストでした。とゆーのも、「※1」にも書いてありますが、pnamazuでは「/」といった記号検索は取りこぼしが発生するんです(バグではなく、仕様)。検索させているのが「コンパクトカメラのデータ」なので、焦点距離の28mmを検索したい場合は、ボディの大きさを示す28mmと区別するために、「28mm/」で検索するようにデータが作ってあります。つまりデータがpnamazu向きではないんですね。
「28mm」で検索すると、焦点距離の28mmの他に、ボディサイズの28mmまで拾ってしまうため、ヒット数が他とずれる結果となります。
「3倍ズーム」が分解されて検索されるのはちょっと予想外でした。データの中に、単焦点、2倍ズーム、3倍ズーム、4倍ズームといったキーワードが埋め込んであります。2、3、4倍ズームの全部に「倍ズーム」がヒットし、そのファイルの中に3があったらヒットしてしまうわけです。
pnamazuの特徴である部分一致検索、フレーズ検索といった高機能な検索のテストをしていません。データの検索にこれらの機能は必要ないからです(だって文章がないから(^^;)。逆に、文章を検索させたいんだぁぁぁという用途には、テストしていないこれらの機能は大きな魅力になるでしょう。
注目したいのは、検索キーワードの数やヒット数の増減によって、それほど時間の「振れ」がない点です。対象ファイル数が2,000、3,000といった規模でもこの程度の時間で済んでしまうのではないかと予感させてくれます。
もう一つ懺悔。インデックスしたファイル数が658ファイルになっていて、3ファイル何かが紛れ込んでます。ま、影響はそれほどないでしょう(^^;
なお、インデックスの容量は約1.5MBでした。
上のような事情があるために、同じ単語でもヒット数が違ってしまい、単純比較ができなくなっていますが、ほとんどの検索でpnamazuを上回っています。規模といい、用途といい、うちの場合はやはりこれがベストな感じです。
どうやら、ヒット数が多いと検索スピードが遅くなるようですね。
インデックスの大きさは1,201kb、つまり1.17MB(計算合ってる?)でした。話がそれますが、作者のKatsushi Matsudaさんとメールでお話しさせていただきました。「or検索は宿題にさせて」ということでしたので、or検索が必要な方は要望をメールしてみるとよいでしょう。
データ数が増えたせいか、混んでいる時間帯でサーバの負荷が高いせいか、前回の検索スピードより若干落ちています。が、単語数が増えても検索時間がほとんど変わらないというのはやはりすごいです。
(2001/8/28追記)
msearchが1.3にバージョンアップしたので、直接テストした比較ではありませんが、参考として比較表を載せます。pnamazuは上のテストの丸写しです(対象ファイル数658)。msearchは対象ファイル数が690に増えています。「msearch導入記/1.3を使うコツ」の表中、20件表示の写しです。検索の条件が全然あってません<(_ _)>
|
検索単語 |
msearch.cgi 1.3 (Katsushi Matsudaさんのmsearch.cgiの改造版) |
pnamazu 2001.0.27 |
|
| 1単語 | 性能表 | ヒット数:690 CPU秒1.21:0.883 CPU秒1.3:0.133 |
ヒット数:655 CPU秒:0.398 |
| 28mm/ | ヒット数:78 CPU秒1.21:0.195 CPU秒1.3:0.250 |
ヒット数:88 ※1 CPU秒:0.211 |
|
| 単焦点 | ヒット数:303 CPU秒1.21:0.430 CPU秒1.3:0.102 |
ヒット数:286 CPU秒:0.234 |
|
| 2単語 AND検索 |
28mm/ 単焦点 | ヒット数:33 CPU秒1.21:0.148 CPU秒1.3:0.250 |
ヒット数:35 ※1 CPU秒:0.250 |
| 3倍ズーム 現行品 | ヒット数:66 CPU秒1.21:0.164 CPU秒1.3:0.141 |
ヒット数:144 ※2 CPU秒:0.359 |
|
| 3単語 AND検索 |
28mm/ 単焦点 現行品 | ヒット数:14 CPU秒1.21:0.125 CPU秒1.3:0.242 |
ヒット数:16 ※1 CPU秒:0.242 |
1.3ではヒット数が多くなっても時間がかからなくなっています。また、1.21よりも全体的に遅くなっていますが、検索スピードがヒット数によって「振れない」というのはpnamazuの持つ特性に近い気がします。
なお、msearch 1.3の限界については「msearch導入記/msearchの限界?」でテストしています。
さて、今回はmacwwwsrch.cgiと大型新人全文検索エンジンmsearch.cgiとの対決です。msearch.cgiはインデックスタイプで、非常に高速です。テストに使用したcgiは、例によって両者ともかなり改造してありますので、オリジナルはもっと速いはずです。
今回、KISS-Search、Splendid Searchはテストしていません。下のデータを見ると明らかですが、この二つは現在のところwwwsrch.cgi、msearch.cgiにかなり水をあけられているからです。
検索対象:コンパクトカメラデータディレクトリ
検索対象ファイル数:619ファイル
|
検索単語 |
macwwwsearch.cgi (とほほさんのwwwsrch.cgi3.09の改造版) |
msearch.cgi 1.21 (Katsushi Matsudaさんのmsearch.cgiの改造版) |
|
| 1単語 | 性能表 | ヒット数:619 CPU秒:0.906 |
ヒット数:619 CPU秒:0.734 |
| 28mm/ | ヒット数:69 CPU秒:1.047 |
ヒット数:69 CPU秒:0.148 |
|
| 単焦点 | ヒット数:272 CPU秒:0.891 |
ヒット数:272 CPU秒:0.383 |
|
| 2単語 AND検索 |
28mm/ 単焦点 | ヒット数:29 CPU秒:0.875 |
ヒット数:29 CPU秒:0.133 |
| 3倍ズーム 現行品 | ヒット数:66 CPU秒:0.883 |
ヒット数:66 CPU秒:0.180 |
|
| 3単語 AND検索 |
28mm/ 単焦点 現行品 | ヒット数:12 CPU秒:0.969 |
ヒット数:12 CPU秒:0.109 |
●感想
ご覧のように、さすがインデックスタイプという感じです。速い速い。だいたいmacwwwsrch.cgiの7倍から8倍のスピードです。改造してなければもっと速いでしょう。
msearch.cgiはインデックスタイプにも関わらず、設置が非常に容易です。インデックススピードも、619ファイルで20秒から30秒程度で、KISS-Search、Splendid Searchよりもはるかに高速です。原因は不明ですが、msearch.cgiではとりこぼしが発生することがあります。詳しくは「msearch導入記」をご覧ください。ただし、これはおそらくデータか使い方の方に原因があると思われます(2001/7/31追記:バージョン1.21で治っています)。
通常の検索であれば、msearch.cgiは今のところベストの選択といえると思います。
対象ファイル数が1,000、2,000となるとどうなるのか興味がありますが(msearch導入記で1300ファイルでテストしています)、僕程度の小規模であればNAMAZUよりも全然お手軽に設置できて、インデックスの作成も簡単、検索も高速と、いうことないです。人によってはor検索がない点が唯一の欠点です。
インデックスを作る手間がいやだという方はwwwsrch.cgiにするとよいでしょう。
とほほさんのwwwsrchが3.09にアップし、Splendid Searchも1.7b1にアップしましたので再テストしてみました。テストは単純で、いくつか単語を入れて検索させ、処理時間とヒット数を見ただけです。なお、Splendid Search1.7b1はページあたり20ファイルの表示、ソート条件はタイトルとして検索しています。
検索対象:コンパクトカメラデータディレクトリ
検索対象ファイル数:540ファイル(前回より64ファイル増えています)
|
検索単語 |
macwwwsearch.cgi (とほほさんのwwwsrch.cgi3.09の改造版) |
KISS-Search β3 (ナンバリング・消費CPU時間表示の改造版) |
Splendid Search1.7b1 (消費CPU時間表示の改造版) |
|
| 1単語 | 性能表 | ヒット数:540 CPU秒:0.820 |
ヒット数:540 CPU秒:8.914 |
ヒット数:540 CPU秒:7.267 |
| 28mm/ | ヒット数:57 CPU秒:0.945 |
ヒット数:57 CPU秒:8.703 |
ヒット数:57 CPU秒:17.767 |
|
| 単焦点 | ヒット数:231 CPU秒:0.773 |
ヒット数:231 CPU秒:3.477 |
ヒット数:231 CPU秒:9.100 |
|
| 2単語 AND検索 |
28mm/ 単焦点 | ヒット数:23 CPU秒:0.805 |
ヒット数:23 CPU秒:3.477 |
ヒット数:23 CPU秒:16.517 |
| 3倍ズーム 現行品 | ヒット数:63 CPU秒:0.836 |
ヒット数:63 CPU秒:3.430 |
ヒット数:63 CPU秒:9.550 |
|
| 3単語 AND検索 |
28mm/ 単焦点 現行品 | ヒット数:12 CPU秒:0.812 |
ヒット数:12 CPU秒:1.398 |
ヒット数:12 CPU秒:11.183 |
●感想
注目はwwwsrch.cgi 3.09でしょう。下の表と見比べてください。検索単語が一つの場合は大きな差はありません。しかし、複数の単語を組み合わせて検索させても1秒以内で検索するようになりました。これは強い。すべてのテストで最速です。すげー。とほほさんのページでは「検索の高速化やバグ修正など」と淡々と書いてあったので、これほど速くなっているとは予想できず、驚きました。
なお、例によって上のテストは3.09のメチャメチャ改造版なので、オリジナルはもっと速いはずです。旧バージョンのユーザーは、是非バージョンアップしましょう。KISS-Searchはバージョンアップがありませんから、対象ファイル数が増えた分だけ若干遅くなっています。
Splendid Search 1.7b1は取りこぼしがなくなりました。良かった良かった。しかし、代わりに検索スピードが大幅にかかるようになりました。1単語ではR1.6で0.5秒〜6.3秒だったのに、R1.7b1では7.2秒〜17.7秒となりました。同様に2単語、3単語でもかなり遅くなっています。
う〜ん、しかし、wwwsrch.cgi 3.09、いいなぁ。当分これを使い続けることになりそうだなぁ。
テストは単純で、いくつか単語を入れて検索させ、処理時間とヒット数を見ただけです。
検索対象:コンパクトカメラデータディレクトリ
検索対象ファイル数:476ファイル
|
検索単語 |
macwwwsearch.cgi (とほほさんのwwwsrch.cgiの改造版) |
KISS-Search β3 (ナンバリング・消費CPU時間表示の改造版) |
Splendid Search1.61 (消費CPU時間表示の改造版) |
|
| 1単語 | 性能表 | ヒット数:476 CPU秒:0.703 |
ヒット数:476 CPU秒:8.211 |
ヒット数:31 CPU秒:0.570 |
| 28mm/ | ヒット数:55 CPU秒:0.797 |
ヒット数:55 CPU秒:7.953 |
ヒット数:55 CPU秒:6.383 |
|
| 単焦点 | ヒット数:204 CPU秒:2.961 |
ヒット数:204 CPU秒:3.156 |
ヒット数:42 CPU秒:1.703 |
|
| 2単語 AND検索 |
28mm/ 単焦点 | ヒット数:23 CPU秒:4.539 |
ヒット数:23 CPU秒:3.148 |
ヒット数:15 CPU秒:4.727 |
| 3倍ズーム 現行品 | ヒット数:62 CPU秒:4.172 |
ヒット数:62 CPU秒:3.320 |
ヒット数:60 CPU秒:3.438 |
|
| 3単語 AND検索 |
28mm/ 単焦点 現行品 | ヒット数:12 CPU秒:5.164 |
ヒット数:12 CPU秒:1.312 |
ヒット数:12 CPU秒:4.977 |
●感想
wwwsearch.cgiは高速ですが、単語数が増えるにしたがってスピードが遅くなります。
KISS-Searchは1単語では低速ですが、単語数が増えるとスピードは速くなります。ただ、該当ページの内容を全文出力するため転送で不利となり、体感スピードはけして速くありません。「性能表」の検索で、ブラウザの表示が終わるまで2分ほどかかりました。
検索前に2ファイル追加してインデックスを作成し直しています。時間は約1分ほど。Splendid Search1.61はやはり取りこぼしが発生しています。単語によってかなり検索スピードが変化しています。検索スピードから、「28mm/」は2単語以上として扱われているのではないかと思われます。
なお、検索前のインデックス作成作業では、検索対象ファイル数を476と正しく表示しています。したがって、インデックスの段階で、検索すべきファイルをインデックスし忘れているということは考えられません。なにが原因なんだぁぁ。
検索前に2ファイル追加してインデックスを作成し直しています。時間は約6分ほど。ブラウザからの管理だけでなく、telnetでもインデックスを作成できるようになるともっと高速なのではないかと思います。
ホーム >HTMLに役立つヒント> 検索テスト