またまたSEOのお話
最近SEO BookMark なるものがあって
登録してみたんですが、見てるだけで色々新しい発見あって面白いです。
（SEOのナレッジのために自分はSEO Vertical Blog Searchを作ったんですが、
明らかにこっちのがクオリティも量も新規性も維持できますね～ カシコイ！もうこれやめよっかな。）
それはそうとまた面白い記事を見つけたのでちょっとエントリー
検索エンジンの５つのプログラム – スパイダーとクローラって別物？ in SEOブログ from SEO塾
よくよく考えてみると当たり前なんですが、
確かに言及するにいたってないですね。気づくことって重要ですね。
こういう時海外の情報をすばやく取得できる人がすごいです。
＊ちなみにSEO Vertical Blog Searchでもスパイダーとクローラは別になっています。
⇒が独立モジュールではありません。
ということで、どうしてこうなるかというお話。
スパイダーとクローラが別である理由
（スパイダーとかクローラとか名前はどうでもいいんですが、ようは
URLリストを作るプログラムと
キャッシュするプログラムってことです。）
開発者っぽい視点で検索エンジンを考えてみるとこうなります。
●ほしいもの
検索エンジンを作るためのDB作成
ブレイクダウン：WEB全体のページデータがほしい（できるだけ新鮮なのがいい）
：ページを取得するためにURLリストがほしい（新鮮なページのために新鮮なURLがいい）
：ページ全体を分析したい
：分析したやつを超早く出力したい
⇒という要望なので、こんなかんじにしましょう
１：WEBのURLリストが最速でほしい（スパイダー）
２：URLリストを順に見て行ってデータをひとまず保存したい（クローラ＊キャッシュ）
３：WEBページを色々分析したい（インデクサ）
４：分析結果をすばやく検索結果として出力したい（アウトプット）
#なぜＵＲＬリストが最速で欲しいかというと、
#そのＵＲＬリストがそのままデータの鮮度に直結するからです。
#このリスト作成サイクルが早くなればなるほど、情報の鮮度がよくなります。
じゃあどうするかってことで、
スパイダーとクローラが同じ場合
プログラム１：URLリストDBを元にURLにアクセスして「以前と変更があったらキャッシュDBに格納」し、
そのキャッシュにあるURLを抽出して、「既存にあるURLと重複がなければURLリストDBに格納」する
プログラム２：キャッシュDBのデータを色々分析
プログラム３：検索結果を出力->この場合単純に１プログラムの負荷が高すぎるというのもありますが、
ＵＲＬリストの作成とキャッシュを作成してＵＲＬリストを作成するのが同時なので、
一回のプログラムの実行時間が長くなってしまい、ＵＲＬリストの鮮度が保てません。
＊しかもこの場合、キャッシュしたページのURLを優先するのか、リストを優先するのかとか、
いろいろクローラー＜＞スパイダー間の関係が複雑になります。
さらにプログラムのチューンアップとかも考えると、別モジュールにしたほうがよいです。＊よくあるアルゴリズムを更新しました とかのときに、
URLリストから生成しなくてはならないのも問題ですね。
スパイダーとクローラをわける場合
プログラム１：キャッシュDBを順番に見ていって「既存にあるURLと重複がなければURLリストDBに格納」する
プログラム２：URLリストDBからURLにアクセスして「以前と変更があったらキャッシュDBに格納」する
プログラム３：キャッシュDBのデータを色々分析
プログラム４：検索結果を出力->プログラムが増えますが、URLリストを作りつつ別軸でキャッシュもできるので、
優先的にキャッシュしたいURLなんかを設定したとしても、URLリストの作成に影響がでません。
URLリストの優先順位とかキャッシュするしないの閾値とか、そういうチューンアップも
別々に行えます。
おまけでインデクサとスパイダーをくっつける場合
プログラム１：URLリストDBからURLにアクセスして「以前と変更があったらキャッシュDBに格納」する
プログラム２：キャッシュDBのデータを色々分析する中で必要なURLを見つけてばURLリストDBに格納する」
プログラム３：検索結果を出力->これもありっておもってます。
メリットとしては必要なURLだけアクセスすることで、
サーバの負荷を減らせること。
デメリットはURLのリストが小さくなってしまうこと。
あとチューンアップとか速度とかの問題。
ちなみに SEO Vertical Blog Search はこの形態です。
＊補足1：プログラムとして他人のURLにアクセスすること が一番負荷が高く
自分のDBにアクセスしてURLをチェックすることと比べるとコストは何倍にもなります。
（俺の感覚ですがｗ）
＊補足2：
３：WEBページを色々分析したい（インデクサ）
というのは極端な話、クロール最中にしてしまってもいいわけです。
＝URLにアクセスしてURLリストを作りつつインデックスしてもいいわけです。
（つまり インデクサ＋クローラー＋スパイダーの１プログラム）
が これは一番効率が悪いので分割してると思われるわけです。
そういう意味で、キャッシュ というのは中間生成物なんですよね。（アーカイブとは違うわけです）
それを単にユーザにとって便利かもしれないということで、
YahooもGoogleも開示してるっていう。
プログラムが５こ？
当該のエントリーの引用元では５個のプログラムとなっていますが、
まあそれはないのかなーと思うので書きます。
上記の通りDBだけでも、
スパイダーが作ったURLリストDB
クロールしてキャッシュしたキャッシュDB
インデックスした後のインデックスDB
は必要なので、
DBもプログラムというなら５個以上になりますね。
ちなみにインデックスも仕方があって（これは長くなるので別エントリーにします）
ページ主体でインデックスする場合とワード主体でインデックスする場合で
DBの格納の仕方がかわるので、さらに増える可能性もありますね。
というかアメリカの人はDBをアプリというのか。。
おまけ
改めて気づいて考えてみると
なかなかおくが深いというかなんと言うか。
実際にGoogleが100%こうなっているとは思えませんが、
近いイメージなんではないでしょうか。
そうそう当たり前ですが、規模が小さい場合クローラとスパイダーを一緒にしてる場合が結構あります。
そういうのは結構出回っているので、自分で使ってみるのもいいかもしれませんね。
しかし、めちゃくちゃでかい（WEB全体とか）をやろうとおもったら、
分離しておくのが普通の発想なのかもしれません。
（というか普通のサーバじゃWEB全体をクロールとかむりだｗ）
ちなみに検索したらsouceforge にスパイダー＋クローラーのPHPクラスがおいてありました。
http://sourceforge.net/projects/phpcrawl/
挙動は確認してません。
ってういか・・・
エントリー長すぎだしまとめるのが不能になった・・・
おせわになります、SEOブログを運営しているライオン丸です。
ところで、専門の方ならスパイダーとクローラのIPアドレスとか区別できますか？
つまり自サイトにアクセスしてきたパターンや傾向などから、こいつはスパイダー、こいつはクローラという具合に。
大御所からコメントありがとうございます！
ちなみに先に書いておくと私はSEOの専門家ではありません。（SEO も するってかんじです。）
（SEOという言葉を知ったのは半年くらい前です（苦笑））
どちらかといえばWEBサイト構築な仕事がメインなので
その知識が少しでも共有できればうれしいかぎりです。
で質問の件なんですが、
あくまでエントリーの考察の範疇で、
真ん中のパターンであれば
1アクセスですべてが足りるはずなので（SiteMap管理とかは別にして）
そういう意味で BOT1回のアクセスでキャッシュだけしているんではないでしょうか。
（エントリーに書いたように別URLに対するアクセスは高コストなので、2回するとはあまり思えません）
＊そのキャッシュからURLを別に抜いているというだけで、
２つのプログラムが別々にサイトにアクセスしているわけではないのかと思います。
コメントありがとうございました。
即答ありがとうございます。ライオン丸です。
ところで、Yahoo! Slurpはどうもクローラとスパイダーがハッキリ違っている感じなんですね。Yahoo!(YST)のアルゴリズムでは、どこへリンクしているのかも重大事のようで、リンクだけをたどるロボットの動きが見られるんですね。ハッキリ実証できないんですが。
今後ともよろしくお願いします。
こちらこそありがとうございます。
>Yahoo! Slurpはどうもクローラとスパイダーがハッキリ違っている感じなんですね。
なるほど！
YahooはHubとAuthorityが みたいな話は聞いていましたが、
それを実装するのにURLだけまとめて専用にアクセスしてるかもしれないということなのかもしれないですね。
勉強になります。
自分のブログの生ログは全部とってあるんで
Yahoo!Slurpに関して追ってみたいと思います。
今後ともよろしくお願いします。
現在、データベースサイトを作成しているので大変参考になりました。
構成としてスパイダー、クローラー、インデクサーという形態をとっているのですが、実際に作成してテストしてみた結果、キャッシュDBの容量が膨れあがってしまうことがデメリットに感じています。
世間には全て一本(クローラー+スパイダー+インデクサー)という構成も多いように思いますが、やはり負荷も大きく、時間もかかってしまうので、
(1) クロール + URLリスト作成(スパイダー)
(2) クロール + 分析(インデクサー)
のような構成を考えています。
つまり、キャッシュDBは作成せず、毎回クロールします。クロール間隔・回数等はURLリストで管理しようと思っています。
二重にクロールするデメリットはありますが、キャッシュDBを作成しない分、ストレージを圧迫しないですむと思うのですが、こういった構成はどう思われますか？
もしよろしければ、ご意見をいただけないでしょうか？よろしくお願いいたします。
MIK-I2さん
コメントありがとうございます。
質問の件ですが、確かにキャッシュファイルがなくなるだけでストレージは大幅に
節減できると思うのでいいんじゃないでしょうか？
キャッシュが必要な意味というと、インデックスの再構築と分析用くらいしか思いつかないので、
普通にDBを作っている限りはMIK-I2さんの構成でも十分事足りると私は思います。
＊違うURLで同じコンテンツ っていうパターンの場合若干めんどくさいかもしれません。
早々のコメントをありがとうございます。
>＊違うURLで同じコンテンツ っていうパターンの場合若干めんどくさいかもしれません。
なるほど、この点は見逃していました。
キャッシュしておくと後々楽だとは思うのですが、何分サーバーのストレージが小さめでして…(汗
他の構成でもそうですが、やはりトレードオフな部分はでてきますね。もう少し練ってみようと思います。
ありがとうございました。