ウェブクローラー

ウェブクローラーのアーキテクチャ

ウェブクローラーは、スパイダーまたはスパイダーボットと呼ばれることもあり、クローラーと略されることもあります。これは、ワールドワイドウェブを体系的に閲覧するインターネットボットであり、通常はウェブインデックス作成（ウェブスパイダー）の目的で検索エンジンによって運用されます。[ 1 ]

ウェブ検索エンジンや一部のウェブサイトは、ウェブクロールやスパイダーソフトウェアを使用して、自社のウェブコンテンツや他のサイトのウェブコンテンツのインデックスを更新しています。ウェブクローラーは、検索エンジンで処理できるようにページをコピーします。検索エンジンはダウンロードしたページをインデックス化し、ユーザーがより効率的に検索できるようにします。

クローラーは訪問先のシステムのリソースを消費し、多くの場合、自発的にサイトを訪問します。大量のページにアクセスする場合、スケジュール、負荷、そして「丁寧さ」といった問題が顕在化します。クロールを希望しない公開サイトには、その旨をクロールエージェントに伝えるための仕組みが用意されています。例えば、ファイルをクロールエージェントに組み込むことで、ウェブサイトの一部のみをインデックスするように、あるいは全くインデックスしないようにボットrobots.txtに指示することができます。

インターネット上のページ数は膨大で、最大規模のクローラーでさえ完全なインデックスを作成することはできません。そのため、2000年以前のワールドワイドウェブ黎明期には、検索エンジンは関連性の高い検索結果を提供することに苦労していました。今日では、関連性の高い検索結果がほぼ瞬時に提供されます。

クローラーはハイパーリンクとHTMLコードを検証できます。また、 Webスクレイピングやデータ駆動型プログラミングにも使用できます。

命名法

ウェブクローラーは、スパイダー[ 2 ]、アント[ 3]、自動インデクサー[ 4 ] 、または（ FOAFソフトウェアの文脈では）ウェブスカッター[ 5 ]とも呼ばれます

概要

Webクローラーは、アクセスするURLのリストから始まります。これらの最初のURLはシードと呼ばれます。クローラーがこれらのURLにアクセスすると、それらのURLに応答するWebサーバーと通信することで、取得したWebページ内のすべてのハイパーリンクを識別し、アクセスするURLのリスト（クロールフロンティア）に追加します。フロンティアからのURLは、一連のポリシーに従って再帰的にアクセスされます。クローラーがWebサイトのアーカイブ（またはWebアーカイブ）を実行している場合、クローラーはアクセスしながら情報をコピーして保存します。アーカイブは通常、ライブWeb上にあるかのように表示、読み取り、ナビゲートできるような方法で保存されますが、「スナップショット」として保存されます。[ 5 ]

大量のデータをダウンロードする場合、クローラーは一定時間内にダウンロードできるウェブページの数が限られているため、ダウンロードの優先順位を設定する必要があります。また、更新率が高い場合、ページが既に更新されているか、削除されている可能性があります。

サーバー側ソフトウェアによって生成されるクロール対象の URL の数が膨大になったことで、Web クローラーが重複コンテンツの取得を避けるのも難しくなっています。HTTP GET ( URL ベース) パラメータの組み合わせは無限にあり、そのうち実際に一意のコンテンツを返すのはごく一部です。たとえば、シンプルなオンライン写真ギャラリーでは、URL の HTTP GET パラメータで指定された 3 つのオプションをユーザーに提供するとします。画像の並べ替え方法が 4 つ、サムネイルサイズが 3 種類、ファイル形式が 2 種類、ユーザー提供コンテンツを無効にするオプションがある場合、同じコンテンツ セットに 48 種類の異なる URL でアクセスでき、そのすべてがサイトにリンクされている可能性があります。この数学的組み合わせはクローラーにとって問題を引き起こします。一意のコンテンツを取得するために、比較的小さなスクリプト変更の無限の組み合わせを整理しなければならないからです。

エドワーズらは、「クロールを実行するための帯域幅は無限でも無料でもないことから、ある程度の品質や鮮度を維持するためには、スケーラブルであるだけでなく効率的な方法でウェブをクロールすることが不可欠になっている」と指摘している。[ 6 ]クローラーは各ステップで次にどのページを訪問するかを慎重に選択する必要がある。

クロールポリシー

ウェブクローラーの動作は、以下のポリシーの組み合わせの結果です。[ 7 ]

  • ダウンロードするページを指定する選択ポリシー
  • ページの変更をいつ確認するかを規定する再訪問ポリシー
  • ウェブサイトの過負荷を避ける方法を定めた礼儀上のポリシー。
  • 分散 Web クローラーを調整する方法を規定する並列化ポリシー。

選択方針

現在のウェブの規模を考えると、大規模な検索エンジンでさえ、公開されている部分の一部しかカバーしていません。2009年の調査では、大規模な検索エンジンでさえ、インデックス可能なウェブの40～70%しかインデックスしていないことが示されました。[ 8 ]スティーブ・ローレンスとリー・ジャイルズによる以前の研究では、 1999年にはウェブの16%以上をインデックスした検索エンジンはなかったことが示されました。 [ 9 ]クローラーは常にウェブページの一部だけをダウンロードするため、ダウンロードされた部分には、ウェブのランダムなサンプルではなく、最も関連性の高いページが含まれていることが非常に望ましいです

ウェブページの優先順位付けには、重要度の指標が必要です。ページの重要度は、そのページの本質的な品質、リンクや訪問数による人気度、さらにはURL（単一のトップレベルドメインに限定された垂直検索エンジン、または固定のウェブサイトに限定された検索エンジンの場合）によって決まります。適切な選択ポリシーを設計するには、さらなる難しさがあります。それは、クロール中にウェブページの完全なセットがわからないため、部分的な情報に基づいて処理する必要があるということです。

Junghoo Choらは、クローリングスケジューリングのポリシーに関する最初の研究を行いました。彼らのデータセットは、stanford.eduドメインから18万ページのクロールデータであり、異なる戦略を用いてクローリングシミュレーションが行われました。[ 10 ]テストされた順序付け指標は、幅優先、被リンク数、部分的なPageRank計算でした。結論の一つは、クローラーがクローリングプロセスの早い段階で高いPageRankのページをダウンロードしたい場合、部分的なPageRank戦略が最も優れており、次に幅優先、被リンク数戦略が続くというものでした。しかし、これらの結果は単一のドメインのみを対象としています。Choはスタンフォード大学でウェブクローリングに関する博士論文も執筆しました。[ 11 ]

マーク・ナヨルクとジャネット・ウィーナーは、幅優先順序を用いて3億2800万ページのクロールを実際に実施しました。[ 12 ]彼らは、幅優先クロールはページランクの高いページをクロールの早い段階で捕捉することを発見しました（ただし、この戦略を他の戦略と比較したわけではありません）。著者はこの結果について、「最も重要なページには多数のホストから多くのリンクがあり、クロールの起点となるホストやページに関係なく、それらのリンクは早い段階で発見される」と説明しています。

アビテブールは、OPIC（オンラインページ重要度計算）と呼ばれるアルゴリズムに基づくクローリング戦略を設計した。 [ 13 ] OPICでは、各ページに初期値の「キャッシュ」が与えられ、それがリンク先のページに均等に分配される。これはPageRankの計算に似ているが、より高速で、1ステップで完了する。OPIC駆動型クローラーは、クローリングフロンティアにある「キャッシュ」の量が多いページを最初にダウンロードする。実験は、インリンクがべき乗分布を持つ10万ページの合成グラフで行われた。しかし、他の戦略との比較や実際のWebでの実験は行われなかった。

Boldiらは、ドメインから4000万ページ、WebBaseクロールから1億ページというウェブのサブセットを用いてシミュレーションを行い.it、幅優先戦略、深さ優先戦略、ランダム順序戦略、全知戦略を比較した。比較は、部分クロールで算出されたPageRankが真のPageRank値をどの程度正確に近似しているかに基づいて行われた。PageRankを非常に急速に蓄積する訪問（特に幅優先戦略と全知戦略）では、漸進的な近似値が非常に低くなる。[ 14 ] [ 15 ]

Baeza-Yatesらは、 Webの2つのサブセットである「」.grと「」.clドメインの300万ページに対してシミュレーションを行い、いくつかのクローリング戦略をテストしました。[ 16 ]彼らは、OPIC戦略とサイトごとのキューの長さを使用する戦略の両方が幅優先クローリングよりも優れていること、また、以前のクロールが利用可能な場合はそれを使用して現在のクロールをガイドすることも非常に効果的であることを示しました。

Daneshpajouhらは、優れたシードを発見するためのコミュニティベースのアルゴリズムを設計した[ 17 ]。彼らの手法は、ランダムシードからクロールを開始する場合と比較して、より少ない反復回数で、異なるコミュニティから高いPageRankを持つウェブページをクロールする。この新しい手法を用いることで、以前にクロールしたウェブグラフから優れたシードを抽出することができる。これらのシードを用いることで、新たなクロールは非常に効果的となる。

クローラーはHTMLページのみを探し、他のすべてのMIMEタイプを避けたい場合があります。HTMLリソースのみを要求するために、クローラーはGETリクエストでリソース全体を要求する前に、HTTP HEADリクエストを発行してWebリソースのMIMEタイプを特定する場合があります。多数のHEADリクエストを発行することを避けるために、クローラーはURLを調べ、URLが.html、.htm、.asp、.aspx、.php、.jsp、.jspx、またはスラッシュなどの特定の文字で終わる場合にのみリソースを要求する場合があります。この戦略により、多くのHTML Webリソースが意図せずスキップされる可能性があります

一部のクローラーは、スパイダートラップを回避するために、「?」を含むリソース（動的に生成されるリソース）のリクエストを回避することがあります。これは、クローラーがウェブサイトから無限にURLをダウンロードしてしまう可能性のあるスパイダートラップを回避するためです。ただし、サイトがURL書き換えによってURLを簡素化している場合、この戦略は信頼できません。

URL正規化

クローラーは通常、同じリソースを複数回クロールすることを避けるために、何らかのURL正規化を実行します。URL正規化（ URL正規化とも呼ばれます）という用語は、URLを一貫した方法で変更および標準化するプロセスを指します。実行できる正規化には、URLを小文字に変換する、「.」および「..」セグメントを削除する、空でないパスコンポーネントに末尾のスラッシュを追加するなど、いくつかの種類があります。[ 18 ]

パス上昇クロール

一部のクローラーは、特定のウェブサイトからできるだけ多くのリソースをダウンロード／アップロードすることを目的としています。そのため、クロール対象の各URL内のすべてのパスを上昇するパス上昇クローラーが導入されました。 [ 19 ]例えば、シードURLとしてhttp://llama.org/hamster/monkey/page.htmlが与えられると、/hamster/monkey/、/hamster/、および/をクロールしようとします。Cotheyは、パス上昇クローラーは孤立したリソース、または通常のクロールではインバウンドリンクが見つからないリソースを見つけるのに非常に効果的であることを発見しました

フォーカスドクロール

クローラーにとってのページの重要性は、特定のクエリに対するページの類似度の関数として表現することもできます。互いに類似したページをダウンロードしようとするウェブクローラーは、フォーカスドクローラーまたはトピカルクローラーと呼ばれます。トピカルクロールとフォーカスドクロールの概念は、フィリッポ・メンツァー[ 20 ] [ 21 ]とソウメン・チャクラバーティら[22]によって初めて導入されました

フォーカス・クロールの主な問題は、Webクローラーのコンテキストでは、実際にページをダウンロードする前に、特定のページのテキストとクエリの類似性を予測できるようにしたいという点です。可能性のある予測子はリンクのアンカーテキストです。これは、Webの初期の初期のWebクローラーでPinkerton [ 23 ]が採用したアプローチでした。Diligentiら[ 24 ]は、すでに訪問したページの完全なコンテンツを使用して、駆動クエリとまだ訪問していないページとの類似性を推測することを提案しています。フォーカス・クロールのパフォーマンスは、主に検索対象の特定のトピックへのリンクの豊富さに依存し、フォーカス・クロールは通常、開始点を提供するために汎用Web検索エンジンに依存しています。

学術に特化したクローラー

集中型クローラーの例としては、 CiteSeer X検索エンジンのクローラーであるciteseerxbotなど、無料でアクセスできる学術関連文書をクロールする学術クローラーがあります。他の学術検索エンジンには、 Google ScholarやMicrosoft Academic Searchなどがあります。ほとんどの学術論文はPDF形式で公開されているため、このようなクローラーはPDF、PostScriptファイル、Microsoft Word （圧縮形式を含む）のクロールに特に重点を置きます。このため、 Heritrixなどの一般的なオープンソースクローラーは、他のMIMEタイプを除外するようにカスタマイズするか、ミドルウェアを使用してこれらの文書を抽出し、集中クロールデータベースとリポジトリにインポートする必要があります。[ 25 ]これらの文書が学術的なものかどうかを識別することは困難であり、クロールプロセスに大きなオーバーヘッドを追加する可能性があるため、機械学習または正規表現アルゴリズムを使用して、クロール後のプロセスとして実行されます。これらの学術文書は通常、学部や学生のホームページ、または研究機関の出版物ページから取得されます学術文書はウェブページ全体のうちごく一部を占めるに過ぎないため、これらのウェブクローラーの効率を高めるには、適切なシードの選択が重要です。[ 26 ]他の学術クローラーは、論文のタイトル、論文名、抄録などのメタデータを含むプレーンテキストファイルやHTMLファイルをダウンロードする場合があります。これにより論文の総数は増加しますが、かなりの数の論文が無料のPDFダウンロードを提供していない可能性があります。

セマンティック重視のクローラー

フォーカスドクローラーのもう一つのタイプはセマンティックフォーカスドクローラーで、ドメインオントロジーを利用してトピックマップを表現し、Webページを関連するオントロジー概念にリンクさせることで選択と分類を行います。[ 27 ]さらに、オントロジーはクローリングプロセス中に自動的に更新されます。Dongら[ 28 ]は、Webページをクローリングする際にオントロジー概念の内容を更新するために サポートベクターマシンを用いた、このようなオントロジー学習ベースのクローラーを導入しました。

再訪問ポリシー

ウェブは非常に動的な性質を持っており、ウェブの一部をクロールするだけでも数週間から数ヶ月かかる場合があります。ウェブクローラーがクロールを完了するまでに、作成、更新、削除など、多くのイベントが発生している可能性があります

検索エンジンの観点から見ると、イベントを検出しないこと、つまりリソー​​スの古いコピーを保持することにはコストがかかります。最もよく使われるコスト関数は、鮮度と年齢です。[ 29 ]

鮮度: これは、ローカルコピーが正確かどうかを示すバイナリ指標です。リポジトリ内のページpの時刻tにおける鮮度は、以下のように定義されます。

Fp（t）＝{1私f p  私s equal to the local copy at t私me t0otherw私se{\displaystyle F_{p}(t)={\begin{cases}1&{\rm {if}}~p~{\rm {がt時点のローカルコピーと等しい}}~t\\0&{\rm {そうでない場合}}\end{cases}}}

経過時間: これは、ローカルコピーの古さを示す指標です。リポジトリ内のページpの時刻tにおける経過時間は、以下のように定義されます。

Ap（t）＝{0私f p  私s not mod私f私ed at t私me tt−mod私f私cat私on t私me of potherw私se{\displaystyle A_{p}(t)={\begin{cases}0&{\rm {if}}~p~{\rm {t時点で変更されていない}}~t\\t-{\rm {pの変更時刻}}~p&{\rm {それ以外の場合}}\end{cases}}}

コフマンらは、 Webクローラーの目的を鮮度と同等と定義したが、異なる表現を用いている。彼らは、クローラーはページが古くなった時間の割合を最小化しなければならないと提唱している。また、Webクローラーの問題は、複数キュー、単一サーバーポーリングシステムとしてモデル化できることにも言及している。このシステムでは、Webクローラーがサーバー、Webサイトがキューとなる。ページの変更は顧客の到着であり、切り替え時間は単一のWebサイトへのページアクセス間隔である。このモデルでは、ポーリングシステムにおける顧客の平均待ち時間は、Webクローラーの平均年齢に相当する。[ 30 ]

クローラーの目的は、コレクション内のページの平均鮮度を可能な限り高く保つこと、またはページの平均年齢を可能な限り低く保つことです。これらの目的は同じではありません。前者の場合、クローラーは単に古くなったページの数だけを気にしますが、後者の場合、クローラーはページのローカルコピーがどれだけ古いかに気を配ります。

ウェブクローラーにおける鮮度と年齢の進化

チョーとガルシアモリーナは、2つの単純な再訪問政策を研究した。[ 31 ]

  • 均一ポリシー: 変更率に関係なく、コレクション内のすべてのページを同じ頻度で再訪問します。
  • 比例ポリシー：これは、頻繁に変更されるページをより頻繁に再訪問することを意味します。訪問頻度は（推定される）変更頻度に正比例します。

どちらの場合も、ページの繰り返しクロール順序はランダムまたは固定順序で実行できます。

Cho氏とGarcia-Molina氏は、平均的な鮮度に関して、シミュレーションWebと実際のWebクロールの両方において、均一ポリシーが比例ポリシーよりも優れているという驚くべき結果を証明しました。直感的に言えば、Webクローラーは一定時間内にクロールできるページ数に制限があるため、(1) 更新頻度の低いページを犠牲にして、頻繁に変化するページに過剰な量の新規クロールを割り当ててしまう、(2) 更新頻度の低いページよりも更新頻度の高いページの鮮度が短い、ということになります。言い換えれば、比例ポリシーは頻繁に更新されるページのクロールに多くのリソースを割り当てますが、それらのページから得られる全体的な鮮度時間は短くなります。

鮮度を向上させるには、クローラーは頻繁に変更される要素にペナルティを課すべきである。[ 32 ]最適な再訪問ポリシーは、均一ポリシーでも比例ポリシーでもない。平均的な鮮度を高く保つための最適な方法は、頻繁に変更されるページを無視することであり、平均年齢を低く保つための最適な方法は、各ページの変更率に応じて単調に（そして準線形に）増加するアクセス頻度を使用することである。どちらの場合も、最適な方法は比例ポリシーよりも均一ポリシーに近い。Coffmanらが指摘するように、「予想される陳腐化時間を最小限に抑えるためには、特定のページへのアクセスは可能な限り均等に間隔を空ける必要がある」。[ 30 ]再訪問ポリシーの明示的な式は一般には得られないが、ページ変更の分布に依存するため、数値的に得られる。ChoとGarcia-Molinaは、指数分布がページ変更を記述するのに適することを示している。[ 32 ]一方、Ipeirotisらは、この分布に影響を与えるパラメータを発見するために統計ツールを使用する方法を示します。[ 33 ]ここで検討されている再訪問ポリシーでは、すべてのページが品質の点で均質であるとみなされます（「Web上のすべてのページの価値は同じである」）。これは現実的なシナリオではないため、より優れたクロールポリシーを実現するには、Webページの品質に関する詳細情報を含める必要があります。

ポライトネスポリシー

クローラーは人間の検索者よりもはるかに速く、より深くデータを取得できるため、サイトのパフォーマンスに深刻な影響を与える可能性があります。1つのクローラーが1秒間に複数のリクエストを実行したり、大きなファイルをダウンロードしたりする場合、サーバーは複数のクローラーからのリクエストに対応するのが困難になる可能性があります

コスターが指摘しているように、Webクローラーの使用は多くのタスクに役立ちますが、一般のコミュニティにとってはコストがかかります。[ 34 ] Webクローラーの使用コストは次のとおりです。

  • クローラーは相当の帯域幅を必要とし、長期間にわたって高度な並列処理で動作するため、ネットワーク リソースが必要になります。
  • サーバーの過負荷、特に特定のサーバーへのアクセス頻度が高すぎる場合。
  • 適切に記述されていないクローラーは、サーバーやルーターをクラッシュさせたり、処理できないページをダウンロードしたりする可能性がある。
  • 個人用クローラーは、あまりに多くのユーザーによって導入されると、ネットワークや Web サーバーに混乱を引き起こす可能性があります。

これらの問題の部分的な解決策として、ロボット排除プロトコル（robots.txtプロトコルとも呼ばれる）が挙げられます。これは、管理者がWebサーバーのどの部分をクローラーによるアクセス禁止にするかを示すための標準規格です。[ 35 ]この標準規格には、同一サーバーへのアクセス間隔に関する提案は含まれていませんが、この間隔はサーバーの過負荷を回避する最も効果的な方法です。最近では、Google、Ask Jeeves、MSN、Yahoo! Searchなどの商用検索エンジンは、 robots.txtファイルに追加の「Crawl-delay:」パラメータを使用して、リクエスト間の遅延秒数を指定できるようになりました。

最初に提案された連続ページロード間隔は60秒でした。[ 36 ]しかし、10万ページ以上のウェブサイトから、遅延ゼロ、無制限の帯域幅の完璧な接続を介してこの速度でページをダウンロードすると、そのウェブサイト全体をダウンロードするだけで2か月以上かかります。また、そのウェブサーバーのリソースのほんの一部しか使用されません。

Choはアクセス間隔として10秒を使用し[ 31 ]、WIREクローラーはデフォルトで15秒を使用しています[ 37 ] 。MercatorWebクローラーは適応的な礼儀正しさポリシーに従います。つまり、特定のサーバーから文書をダウンロードするのにt秒かかった場合、クローラーは次のページをダウンロードする前に10t秒間待機します[38]。Dillらは1秒を使用しています[ 39 ]。

研究目的でWebクローラーを使用する場合は、より詳細な費用便益分析が必要であり、どこをクロールするか、どのくらいの速度でクロールするかを決定する際には倫理的な配慮を考慮する必要があります。[ 40 ]

アクセスログから得られた事例証拠によると、既知のクローラーからのアクセス間隔は20秒から3～4分と幅があります。非常に丁寧な対応をし、ウェブサーバーの過負荷を回避するためのあらゆる安全対策を講じていても、ウェブサーバー管理者から苦情が寄せられる場合があることは注目に値します。セルゲイ・ブリン氏とラリー・ペイジ氏は1998年に次のように述べています。「…50万台以上のサーバーに接続するクローラーを運用すると…かなりの数のメールや電話が発生します。膨大な数のユーザーがオンラインにアクセスするため、初めて目にするクローラーであるため、クローラーが何なのかわからない人が必ずいます。」[ 41 ]

並列化ポリシー

並列クローラーとは、複数のプロセスを並列に実行するクローラーです。並列化によるオーバーヘッドを最小限に抑えながらダウンロード速度を最大化し、同じページの繰り返しダウンロードを回避することが目標です。同じページを複数回ダウンロードすることを避けるために、クロールシステムには、クロールプロセス中に検出された新しいURLを割り当てるポリシーが必要です。これは、2つの異なるクロールプロセスによって同じURLが見つかる可能性があるためです

アーキテクチャ

標準的なWebクローラーの高レベルアーキテクチャ

前のセクションで述べたように、クローラーは優れたクロール戦略を持つだけでなく、高度に最適化されたアーキテクチャも持つ必要があります

シュカペニュクとスエルは次のように指摘している。[ 42 ]

短時間に 1 秒あたり数ページをダウンロードする低速クローラーを構築するのは比較的簡単ですが、数週間にわたって数億ページをダウンロードできる高性能システムを構築するには、システム設計、I/O とネットワークの効率、堅牢性と管理性に関して多くの課題が生じます。

ウェブクローラーは検索エンジンの中核を成すものであり、そのアルゴリズムとアーキテクチャの詳細は企業秘密として扱われています。クローラーの設計が公開される際には、他者による再現を阻む重要な詳細事項が欠落しているケースがしばしばあります。また、「検索エンジンスパム」への懸念も高まりつつあり、大手検索エンジンはランキングアルゴリズムの公開を控えています。

セキュリティ

ほとんどのウェブサイト所有者は、検索エンジンで強力なプレゼンスを得るために、自分のページをできるだけ広範囲にインデックスさせたいと考えていますが、検索エンジンが公開すべきではないリソースや、潜在的に脆弱なバージョンのソフトウェアを公開するページをインデックスした場合、ウェブクロールは意図しない結果をもたらし、侵害やデータ漏洩につながる可能性があります

標準的なWeb アプリケーション セキュリティ推奨事項とは別に、Web サイトの所有者は、検索エンジンが Web サイトの公開部分のみをインデックスできるようにし ( robots.txtを使用)、トランザクション部分 (ログイン ページ、プライベート ページなど) のインデックスを明示的にブロックすることで、便乗ハッキングの危険を減らすことができます。

クローラーの識別

ウェブクローラーは通常、 HTTPリクエストのユーザーエージェントフィールドを使用して、ウェブサーバーに対して自身を識別します。ウェブサイト管理者は通常、ウェブサーバーのログを調べ、ユーザーエージェントフィールドを使用して、どのクローラーがウェブサーバーにアクセスしたか、またどのくらいの頻度でアクセスしたかを判断します。ユーザーエージェントフィールドには、ウェブサイト管理者がクローラーに関する詳細情報を確認できるURLが含まれている場合があります。ウェブサーバーのログを調べるのは面倒な作業であるため、一部の管理者はツールを使用してウェブクローラーを識別、追跡、検証しています。スパムボットやその他の悪意のあるウェブクローラーは、ユーザーエージェントフィールドに識別情報を配置する可能性は低く、ブラウザや他のよく知られたクローラーとして自身のIDを隠す可能性があります

ウェブサイト管理者は、必要に応じて所有者に連絡できるよう、ウェブクローラーが自己識別を行うことを推奨します。場合によっては、クローラーが誤ってクローラートラップに引っかかったり、リクエストによってウェブサーバーに過負荷をかけたりして、所有者がクローラーを停止する必要が生じることがあります。また、特定の検索エンジンによってウェブページがインデックスされる時期を知りたい管理者にとっても、識別情報は役立ちます。

ディープウェブのクロール

膨大な量のウェブページがディープウェブ、あるいはインビジブルウェブに存在します。[ 43 ]これらのページは通常、データベースにクエリを送信することによってのみアクセスでき、通常のクローラーは、それらのページを指すリンクがない場合、これらのページを見つけることができません。Googleのサイトマッププロトコルとmod oai [ 44 ]は、これらのディープウェブリソースの発見を可能にすることを目的としています。

ディープウェブクローリングでは、クロール対象となるウェブリンクの数も増加します。一部のクローラーは、URLの一部のみをフォームから取得します。Googlebot<a href="URL">のように、ハイパーテキストコンテンツ、タグ、テキストに含まれるすべてのテキストを対象にウェブクローリングが行われる場合もあります。

深層ウェブコンテンツをターゲットとするためには、戦略的なアプローチが考えられます。スクリーンスクレイピングと呼ばれる手法を用いると、特定のウェブフォームを自動的に繰り返しクエリし、その結果を集約する専用のソフトウェアをカスタマイズできます。このようなソフトウェアは、複数のウェブサイトにまたがる複数のウェブフォームにまたがって使用することができます。あるウェブフォームの送信結果から抽出されたデータは、別のウェブフォームの入力として取り込むことができ、従来のウェブクローラーでは不可能な方法で深層ウェブ全体にわたる連続性を確立することができます。[ 45 ]

AJAXで構築されたページは、ウェブクローラーにとって問題を引き起こすものの一つです。Googleは、ボットが認識してインデックスできるAJAX呼び出しの形式を提案しています。[ 46 ]

ビジュアルクローラーとプログラムクローラー

ウェブ上には、ページをクロールし、ユーザーの要件に基づいてデータを列と行に構造化する「ビジュアルウェブスクレイパー／クローラー」製品が数多く存在します。従来のクローラーとビジュアルクローラーの主な違いの一つは、クローラーの設定に必要なプログラミングスキルのレベルです。最新世代の「ビジュアルスクレイパー」は、ウェブデータをスクレイピングするためのクロールをプログラミングして開始するために必要なプログラミングスキルの大部分を排除します。

ビジュアルスクレイピング／クローリング手法は、ユーザーがクローラー技術の一部を「学習」させ、クローラーが半構造化データソースのパターンを辿るという仕組みです。ビジュアルクローラーの学習方法としては、ブラウザでデータをハイライト表示し、列と行を学習させる方法が主流です。この技術自体は新しいものではありませんが、例えばGoogleが買収したNeedlebase（ITA Labs [ 47 ]の大規模買収の一環として）の基盤技術となったことから、投資家やエンドユーザーによるこの分野への投資と成長は続いています。

ウェブクローラーのリスト

以下は、汎用クローラー (集中型 Web クローラーを除く) の公開されたクローラー アーキテクチャのリストです。さまざまなコンポーネントに付けられた名前と優れた機能を含む簡単な説明も記載されています。

歴史的なウェブクローラー

社内ウェブクローラー

  • ApplebotはAppleのウェブクローラーです。Siriなどの製品をサポートしています。 [ 48 ]
  • Bingbotは、MicrosoftのBingウェブクローラーの名前です。Msnbotの後継です。
  • Baiduspider はBaiduの Web クローラーです。
  • DuckDuckBot はDuckDuckGoの Web クローラーです。
  • Googlebot については詳細に説明されていますが、参照されているのは C++ とPythonで記述された初期のアーキテクチャのみです。クローラーはインデックス作成プロセスと統合されており、テキスト解析は全文インデックス作成と URL 抽出の両方で行われていました。複数のクロールプロセスで取得する URL のリストを送信する URL サーバーが存在します。解析中に見つかった URL は URL サーバーに渡され、URL サーバーは以前にその URL が参照されているかどうかを確認します。参照されていない場合は、URL サーバーのキューに追加されます。
  • WebCrawlerは、Webのサブセットを対象とした、初めて公開されたフルテキストインデックスの構築に使用されました。ページのダウンロードにはlib-WWWを、Webグラフの幅優先探索のためのURL解析と順序付けには別のプログラムを採用していました。また、アンカーテキストとクエリの類似度に基づいてリンクを辿るリアルタイムクローラーも搭載されていました。
  • WebFountainは、Mercator に似た分散型モジュール式クローラーですが、C++ で書かれています。
  • Xenonは、政府の税務当局が詐欺を検出するために使用するウェブクローラーです。[ 49 ] [ 50 ]

商用ウェブクローラー

以下のウェブクローラーは有料でご利用いただけます。

オープンソースクローラー

参照

参考文献

  1. ^ 「ウェブクローラー：ウェブの閲覧」 。 2021年12月6日時点のオリジナルよりアーカイブ
  2. ^ Spetka, Scott. 「TkWWWロボット：ブラウジングを超えて」 NCSA . 2004年9月3日時点のオリジナルよりアーカイブ。 2010年11月21日閲覧。
  3. ^小林正治・武田健一 (2000). 「ウェブ上の情報検索」. ACM Computing Surveys . 32 (2): 144– 173. CiteSeerX 10.1.1.126.6094 . doi : 10.1145/358923.358934 . S2CID 3710903 .  
  4. ^ FOAFプロジェクトのwikiにあるscutterの定義を参照。 2009年12月13日Wayback Machineにアーカイブ。
  5. ^マサネス、ジュリアン（2007年2月15日）.ウェブアーカイブ. シュプリンガー. p. 1. ISBN 978-3-54046332-02014年4月24日閲覧
  6. ^ Edwards, J.; McCurley, KS; Tomlin, JA (2001). 「増分ウェブクローラーのパフォーマンスを最適化する適応モデル」.第10回国際ワールドワイドウェブ会議議事録. pp.  106– 113. CiteSeerX 10.1.1.1018.1506 . doi : 10.1145/371920.371960 . ISBN  978-1581133486. S2CID  10316730 . 2014年6月25日時点のオリジナルよりアーカイブ。2007年1月25日閲覧{{cite book}}: CS1 maint: multiple names: authors list (link)
  7. ^ Castillo, Carlos (2004).効果的なウェブクローリング（博士論文）. チリ大学. 2010年8月3日閲覧。
  8. ^ Gulls, A.; A. Signori (2005). 「インデックス可能なウェブは115億ページ以上」.第14回国際ワールドワイドウェブ会議の特別企画トラックとポスター. ACM Press. pp.  902– 903. doi : 10.1145/1062745.1062789 .
  9. ^ローレンス、スティーブ、C. リー・ジャイルズ (1999年7月8日). 「ウェブ上の情報のアクセシビリティ」 . Nature . 400 ( 6740): 107–9 . Bibcode : 1999Natur.400..107L . doi : 10.1038/21987 . PMID 10428673. S2CID 4347646 .  
  10. ^ Cho, J.; Garcia-Molina, H.; Page, L. (1998年4月). 「URL順序付けによる効率的なクロール」 .第7回国際ワールドワイドウェブ会議. オーストラリア、ブリスベン. doi : 10.1142/3725 . ISBN 978-981-02-3400-32009年3月23日閲覧
  11. ^ Cho, Junghoo、「Web のクローリング: 大規模 Web データの発見とメンテナンス」Wayback Machineに 2012 年 12 月 21 日にアーカイブ、博士論文、スタンフォード大学コンピューター サイエンス学部、2001 年 11 月。
  12. ^ Najork, Marc、Janet L. Wiener.「幅優先クロールによる高品質ページ生成」。Wayback Machineに2017年12月24日アーカイブ。Proceedings of the Tenth Conference on World Wide Web、114～118ページ、香港、2001年5月。Elsevier Science。
  13. ^アビテブール、セルジュ、ミハイ・プレダ、グレゴリー・コベナ (2003). 「適応型オンラインページ重要度計算」 .第12回国際ワールドワイドウェブ会議議事録. ブダペスト、ハンガリー: ACM. pp.  280– 290. doi : 10.1145/775152.775192 . ISBN 1-58113-680-32008年3月20日時点のオリジナルよりアーカイブ。2009年3月22日閲覧
  14. ^ Boldi, Paolo; Bruno Codenotti; Massimo Santini; Sebastiano Vigna (2004). 「UbiCrawler: スケーラブルな完全分散型Webクローラー」(PDF) . Software: Practice and Experience . 34 (8): 711– 726. CiteSeerX 10.1.1.2.5538 . doi : 10.1002/spe.587 . S2CID 325714. 2009年3月20日時点のオリジナル(PDF)からのアーカイブ。 2009年3月23日閲覧。  
  15. ^ Boldi, Paolo; Massimo Santini; Sebastiano Vigna (2004). 「最悪を尽くして最善を尽くす：PageRankの増分計算における逆説的効果」（PDF） . Webグラフのためのアルゴリズムとモデル. コンピュータサイエンス講義ノート. 第3243巻. pp.  168– 180. doi : 10.1007/978-3-540-30216-2_14 . ISBN 978-3-540-23427-22005年10月1日時点のオリジナル（PDF）からアーカイブ。2009年3月23日閲覧
  16. ^ Baeza-Yates, R.; Castillo, C.; Marin, M. and Rodriguez, A. (2005).「国レベルのクローリング：ウェブページ順序付けにおける幅優先戦略よりも優れた戦略」第14回ワールドワイドウェブ会議産業・実用経験トラック議事録、864～872ページ、千葉、日本。ACMプレス。
  17. ^ Shervin Daneshpajouh、Mojtaba Mohammadi Nasiri、Mohammad Ghodsi、「クローラーシードセットを生成するための高速コミュニティベースアルゴリズム」。第4回国際ウェブ情報システム技術会議（ Webist -2008）議事録、ポルトガル、フンシャル、2008年5月。
  18. ^ Pant, Gautam; Srinivasan, Padmini; Menczer, Filippo (2004). 「Crawling the Web」(PDF) . Levene, Mark; Poulovassilis, Alexandra (編). Web Dynamics: Adapting to Change in Content, Size, Topology and Use . Springer. pp.  153– 178. ISBN 978-3-540-40676-1. 2009年3月20日時点のオリジナル（PDF）からアーカイブ。2006年5月9日閲覧。
  19. ^ Cothey, Viv (2004). 「Webクロールの信頼性」（PDF） . Journal of the American Society for Information Science and Technology . 55 (14): 1228– 1238. CiteSeerX 10.1.1.117.185 . doi : 10.1002/asi.20078 . 2017年9月22日時点のオリジナル（PDF）からアーカイブ。 2017年10月26日閲覧。 
  20. ^ Menczer, F. (1997). ARACHNID: 情報発見のためのヒューリスティック近傍を選択する適応型検索エージェント 2012年12月21日アーカイブWayback Machine . D. Fisher編『機械学習：第14回国際会議（ICML97）の議事録』 Morgan Kaufmann
  21. ^ Menczer, F. and Belew, RK (1998).分散テキスト環境における適応型情報エージェントArchived 21 December 2012 at the Wayback Machine . K. Sycara and M. Wooldridge (eds.) Proc. 2nd Intl. Conf. on Autonomous Agents (Agents '98). ACM Press
  22. ^ Chakrabarti, Soumen; Van Den Berg, Martin; Dom, Byron (1999). 「Focused crawling: A new approach to topic-specific Web resource discovery」(PDF) . Computer Networks . 31 ( 11– 16): 1623– 1640. doi : 10.1016/s1389-1286(99)00052-3 . 2004年3月17日時点のオリジナル(PDF)からのアーカイブ。
  23. ^ Pinkerton, B. (1994). 「人々が何を求めているかを見つける：WebCrawlerの経験」 . 第1回World Wide Web Conference Proceedings, Geneva, Switzerland.
  24. ^ Diligenti, M., Coetzee, F., Lawrence, S., Giles, CL, Gori, M. (2000).コンテキストグラフを用いたフォーカストクローリング. 第26回国際超大規模データベース会議 (VLDB) 議事録, 527-534ページ, カイロ, エジプト.
  25. ^ Wu, Jian; Teregowda, Pradeep; Khabsa, Madian; Carman, Stephen; Jordan, Douglas; San Pedro Wandelmer, Jose; Lu, Xin; Mitra, Prasenjit; Giles, C. Lee (2012). 「検索エンジンデジタルライブラリ向けWebクローラーミドルウェア」.第12回国際Web情報・データ管理ワークショップ WIDM '12 議事録. p. 57. doi : 10.1145/2389936.2389949 . ISBN 9781450317207 . S2CID  18513666
  26. ^ Wu, Jian; Teregowda, Pradeep; Ramírez, Juan Pablo Fernández; Mitra, Prasenjit; Zheng, Shuyi; Giles, C. Lee (2012). 「学術文書検索エンジンにおけるクローリング戦略の進化」. Proceedings of the 3rd Annual ACM Web Science Conference on - Web Sci '12 . pp.  340– 343. doi : 10.1145/2380718.2380762 . ISBN 9781450312288. S2CID  16718130 .
  27. ^ Dong, Hai; Hussain, Farookh Khadeer; Chang, Elizabeth (2009). 「セマンティックフォーカスクローラーの最新技術」 .計算科学とその応用 – ICCSA 2009.コンピュータサイエンス講義ノート. 第5593巻. pp.  910– 924. doi : 10.1007/978-3-642-02457-3_74 . hdl : 20.500.11937/48288 . ISBN 978-3-642-02456-6。
  28. ^ Dong, Hai; Hussain, Farookh Khadeer (2013). 「SOF：半教師ありオントロジー学習ベースの集中型クローラー」 .並行性と計算：実践と経験. 25 (12): 1755–1770 . doi : 10.1002/cpe.2980 . S2CID 205690364 
  29. ^ Junghoo Cho; Hector Garcia-Molina (2000). 「データベースの同期による鮮度向上」(PDF) . 2000 ACM SIGMOD 国際データ管理会議議事録. テキサス州ダラス、米国: ACM. pp.  117– 128. doi : 10.1145/342009.335391 . ISBN 1-58113-217-42009年3月23日閲覧
  30. ^ a b E. G. Coffman Jr; Zhen Liu; Richard R. Weber (1998). 「Web検索エンジンのための最適ロボットスケジューリング」. Journal of Scheduling . 1 (1): 15– 29. CiteSeerX 10.1.1.36.6087 . doi : 10.1002/(SICI)1099-1425(199806)1:1<15::AID-JOS3>3.0.CO;2-K . 
  31. ^ a b Cho, Junghoo; Garcia-Molina, Hector (2003). 「Webクローラーのための効果的なページ更新ポリシー」. ACM Transactions on Database Systems . 28 (4): 390– 426. doi : 10.1145/958942.958945 . S2CID 147958 . 
  32. ^ a b Junghoo Cho; Hector Garcia-Molina (2003). 「変化頻度の推定」. ACM Transactions on Internet Technology . 3 (3): 256– 290. CiteSeerX 10.1.1.59.5877 . doi : 10.1145/857166.857170 . S2CID 9362566 .  
  33. ^ Ipeirotis, P., Ntoulas, A., Cho, J., Gravano, L. (2005)テキストデータベースにおけるコンテンツ変更のモデリングと管理Archived 5 September 2005 at the Wayback Machine . Proceedings of the 21st IEEE International Conference on Data Engineering, pages 606-617, April 2005, Tokyo.
  34. ^ Koster, M. (1995). ウェブにおけるロボット：脅威か、それとも扱いか？ConneXions, 9(4).
  35. ^ Koster, M. (1996).ロボット排除の基準Archived 7 November 2007 at the Wayback Machine .
  36. ^ Koster, M. (1993).ロボットライターのためのガイドラインArchived 22 April 2005 at the Wayback Machine .
  37. ^ Baeza-Yates, R. および Castillo, C. (2002). Web クローリングにおける量、品質、鮮度のバランス. 『Soft Computing Systems – Design, Management and Applications』, 565–572 ページ, サンティアゴ, チリ. IOS Press Amsterdam.
  38. ^ Heydon, Allan; Najork, Marc (1999年6月26日). 「Mercator: スケーラブルで拡張可能なWebクローラー」(PDF) . 2006年2月19日時点のオリジナル(PDF)からアーカイブ。 2009年3月22日閲覧。{{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）が必要です
  39. ^ Dill, S.; Kumar, R.; Mccurley, KS; Rajagopalan, S.; Sivakumar, D.; Tomkins, A. (2002). 「Webにおける自己相似性」(PDF) . ACM Transactions on Internet Technology . 2 (3): 205– 223. doi : 10.1145/572326.572328 . S2CID 6416041 . 
  40. ^ M. Thelwall; D. Stuart (2006). 「Webクロール倫理の再考：コスト、プライバシー、そしてサービス拒否」 . Journal of the American Society for Information Science and Technology . 57 (13): 1771– 1779. doi : 10.1002/asi.20388 . 2008年3月7日時点のオリジナルよりアーカイブ。 2008年1月28日閲覧。
  41. ^ Brin, Sergey; Page, Lawrence (1998). 「大規模ハイパーテキストWeb検索エンジンの解剖学」 .コンピュータネットワークとISDNシステム. 30 ( 1–7 ): 107–117 . doi : 10.1016/s0169-7552(98)00110-x . S2CID 7587743 . 
  42. ^ Shkapenyuk, V. およびSuel, T. (2002).高性能分散ウェブクローラーの設計と実装Archived 1 October 2005 at the Wayback Machine . Proceedings of the 18th International Conference on Data Engineering (ICDE), pages 357-368, San Jose, California. IEEE CS Press.
  43. ^ Shestakov, Denis (2008). Web上の検索インターフェース：クエリと特性評価 2014年7月6日アーカイブ、 Wayback Machine . TUCS Doctoral Dissertations 104、トゥルク大学
  44. ^ Michael L Nelson、Herbert Van de Sompel、Xiaoming Liu、Terry L Harrison、Nathan McFarland (2005年3月24日). 「mod_oai: メタデータ収集のためのApacheモジュール」: cs/0503069. arXiv : cs/0503069 . Bibcode : 2005cs......3069N .{{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）が必要です
  45. ^ Shestakov, Denis; Bhowmick, Sourav S.; Lim, Ee-Peng (2005). 「DEQUE: ディープウェブへのクエリ」(PDF) . Data & Knowledge Engineering . 52 (3): 273– 311. doi : 10.1016/s0169-023x(04)00107-7 .
  46. ^ 「AJAXクロール：ウェブマスターと開発者向けガイド」。2013年3月6日時点のオリジナルよりアーカイブ。2013年3月17日閲覧。
  47. ^ ITA Labs「ITA Labsの買収」 2014年3月18日アーカイブ、Wayback Machineにて2011年4月20日午前1時28分
  48. ^ 「Applebotについて」 Apple Inc. 2021年10月18日閲覧。
  49. ^ノートン、クイン（2007年1月25日）「税金徴収人がスパイダーを送り込む」。ビジネス。Wired 。 2016年12月22日時点のオリジナルよりアーカイブ。 2017年10月13日閲覧。
  50. ^ 「Xenonウェブクロールイニシアチブ：プライバシー影響評価（PIA）概要」オタワ：カナダ政府。2017年4月11日。2017年9月25日時点のオリジナルよりアーカイブ。 2017年10月13日閲覧。

さらに詳しい情報

「 https://en.wikipedia.org/w/index.php?title=Web_crawler&oldid=1335488565」から取得