要約

  • Pinkertonの1994年の原論文によると、公開WebCrawlerの索引には9000を超えるサーバーの約5万文書が入り、毎日6000件以上の質問に答え、週ごとに更新されていた。
  • 同じソフトには索引から関連ページを選び、未探索リンクへ進んで新しい文書を加えるリアルタイム検索もあった。Pinkertonは、その機能を一般利用者へ提供していないと明記した。利用者ごとの巡回がネットワークを圧迫するためだった。

一度読んだページを何度も使う

Webの検索には、いつページを取りに行くかという選択がある。先に集めて索引にし、後から多くの人が調べる。あるいは質問が来るたびに、その答えを探してWebへ出かける。WebCrawlerは両方の手段を備えていた。公開サービスとして利用者が触れたのは前者であり、検索サーバーは保存済みの文章から結果を並べた。

シカゴの会議に提出された原論文は、索引の作り方を細かく説明する。既知のページからリンクを追い、新しいサーバーを見つけたら、すでに知っている一つのサーバーを深掘りする前に、そちらから少なくとも一文書を読む。システムは全文の索引と、文書・リンク・サーバーの関係図を保存した。文書を取得すると、訪問記録を付け、外向きリンクを拾い、題名と本文の語を登録する。広く多くのサーバーに触れる方針には、容量の限られた索引を偏らせない狙いがあった。

当時の規模としてPinkertonが示したのは、9000を超えるサーバーの約5万文書、毎日6000件超の検索、週一度の索引更新である。これは1994年の運用記録であり、Web全体の数ではない。索引には当然穴がある。新しいページが次の巡回を待つことも、深いリンクの先が選ばれないこともある。その代わり、一度取得したページの内容を何千もの質問に使い回せた。

題名だけに頼らない点も大きかった。Pinkertonによれば、訪問した文書の20％には題名がなかった。題名だけの検索なら、それらのページに書かれた話題を取り逃がす。本文まで索引化すれば、検索側の保存容量と計算時間は増える。しかし元のサーバーへ同じ文書を質問のたびに取りに行く必要はなくなる。共有索引は検索機能であると同時に、取得費用を分け合う仕組みだった。

質問を追う二番目の仕組み

実験中のリアルタイム検索は、最初に共有索引を引く。質問に近い文書を選び、そこからまだ調べていないリンクを追う。新しい文書を取得したら索引へ加え、同じ質問をもう一度走らせる。新たに上位へ現れた文書が次の探索の起点になる。十分な類似文書を見つけるか、制限時間に達すれば止まる。Pinkertonはリンクに書かれた文字と質問を比べ、無関係な枝へ進みにくくする工夫も試した。

週ごとの索引が見逃したページでも、その時の質問に合うリンクをたどれば見つかるかもしれない。Pinkertonは私的な試験で速く、狙いも良い結果が得られたと書く。しかし同じ論文で、リアルタイム検索は一般に公開していないと断言する。公開索引の毎日6000件以上の質問を、毎回個別の巡回ロボットが処理していたわけではない。この区別こそ、当時の検索サービスを成り立たせた判断だ。

索引を作る巡回は、訪問先をサーバー間に分散できる。Pinkertonは広い巡回なら、一つのサーバーが受けるアクセスは数時間に一度程度になると述べた。取得した内容は多くの読者が再利用する。一人のための検索は違う。複数の取得エージェントがその人の答えを探して動き、結果はその人だけが使う。同じことを大勢が始めれば、遠隔のサイトは何度もページを送らなければならない。Pinkertonは当時のネットワークで広範な公開を現実的と見なさなかった。

見送った分だけ、新しさでは不利になる。共有索引は更新まで待たなければならない。質問別の巡回なら、今つながったばかりのページを探し当てる可能性がある。それでも一人の鮮度向上のために外部サーバーを働かせるなら、その仕事を誰が引き受けるのかが残る。Pinkertonは個別探索の発見を主索引へ戻し、後の利用者にも役立てる案を将来の課題に挙げた。公開済みの機能としてではなく、費用を共有するための検討として読むべき箇所だ。