Neo Inspiration

またまた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/

挙動は確認してません。

ってういか・・・

エントリー長すぎだしまとめるのが不能になった・・・

This entry was posted on 月曜日, 3 月 10th, 2008 at 1:21 PM and is filed under Just A Scrap, Seo, 後で検証.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.