PHP クローラ開発


現在特定のサイトを対象とした検索エンジンをPHPベースに作っています。指定したサイトからHTMLタグを取り除きコンテンツを取得しデータベースに格納しているのですが、量が多いためDBに負荷がかかってしまいます。

調べるとGoogleはDBを使用していないようです。

Googleなどの巨大検索エンジンはもとより価格.comや比較.comなど一般企業のクローラはデータをどのように保存し、管理、検索をかけているのでしょうか?

詳細な情報をお願いいたします。

回答の条件
  • URL必須
  • 1人10回まで
  • 登録:2007/01/29 10:11:31
  • 終了:2007/02/04 18:14:45

回答(2件)

id:yna1962 No.1

yna1962回答回数26ベストアンサー獲得回数32007/01/29 11:16:31

ポイント23pt

 一概に言えないのですが、DBがボトルネックになっているとすると、DBのオプティマイズがちゃんとされていないのかもしれません。検索時の高速性を狙って全部の項目に索引をつけると、登録の度にすごく重くなります。また、ページファイルのようなものをDBに保存しているようなら、これを外部のファイルに保存するようにしてください。DBの設計を一度見直してみては如何でしょうか?

 昔Btreeそのものを作っていましたが、索引つきのテーブルに10000件のデータを順次登録するのより、索引のないテーブルに10000件のデータを登録し、その後索引を再構成したほうが早いということが起きます。バッチ処理的な運用が可能なら、このような方法でプログラムすることも可能かもしれません。(ただし普通のSQLを使うというレベルでない難しさがあると思います)

MSSQLの例ですが、考え方は応用できると思います。

http://www.microsoft.com/japan/technet/archive/columns/itpro/rip...

id:pmakino No.2

まきのっぴ回答回数355ベストアンサー獲得回数282007/01/29 12:57:56

ポイント47pt

ひょっとして全文を突っ込んだフィールドに対して LIKE 演算子で単純に中間一致検索されていないでしょうか?

単純な中間一致検索は対象のデータを毎回全文嘗め回すので、データ量が増えるとそれに比例して遅くなってしまいます。

そこで、Google その他の全文検索システムでは転置インデックスというデータ構造をあらかじめ作成し、高速に検索できるようにしています。

MySQL や PostgreSQL 等の RDBMS にも全文検索のための転置インデックス作成機能がありますが、日本語に対応していないという問題があります。

そこで、それらで転置インデックスを用いた日本語対応の高速な全文検索を可能にするライブラリとして、Senna があります。

Senna には MySQL と連携するためのパッチが標準でついていますし、PostgreSQL についても NTT データが提供している Ludia を追加することで Senna と連携可能になります。

また、RDBMS との連携機能はありませんが、Hyper Estraier ならクローラも付属していますので、お手軽に全文検索を実現できます。

id:esecua

大変参考になります。ありがとうございます。

2007/01/29 13:07:11
  • id:tamtam3
    >調べるとGoogleはDBを使用していないようです。

    なんだって!! 冗談もほどほどにしてくれ
  • id:b-wind
    >http://japan.cnet.com/news/ent/story/0,2000056022,20060821,00.htm
    >GoogleやSlashdotなどをはじめ、日本でも楽天、ソニー、NEC、東芝、日立といった企業がMySQLを採用している。
    基本は MySQL のはずですが。
  • id:esecua
    すいません、うそですw
  • id:pmakino
    一口に Google と言っても様々なプログラムがあるわけですから、「Google が MySQL を使っている」からと言って、「Google の WWW 検索のコアに MySQL が使われている」とは限りませんよ。

    上記回答にも書きましたように、基本的に単純な RDBMS は大規模な全文検索には向きませんので、各検索エンジンは MySQL でも PostgreSQL でもない、独自のデータ構造を持った DB (RDBMS とは限りません) を使っているはずです。
    (MySQL でも Senna を使えば日本語の全文検索ができますが、Google は Senna が登場する前からありますし、Google は日本語に限らず多言語対応ですし、検索の挙動を見ても Senna のような N-gram 系ではなく形態素解析系のようですので、Senna ベースではないのは明らか)

    例えば、Namazu はバックエンドに RDBMS は使っておらず、独自のデータ構造を持ったデータベースを構築しています。(http://0xcc.net/pub/namazu-ipsj/)
    Hyper Estraier は同作者の QDBM (http://qdbm.sourceforge.net/) をベースに RDB 的要素を付加 (http://qdbm.sourceforge.net/mikio/rbbs.cgi?id=RA11439825461275735795) した独自 DB です。(http://qdbm.sourceforge.net/mikio/he-sigmodj.pdf)

    Google の Web 検索のコアの DB については情報を見つけられませんでしたが、例えばデータベースより低いレイヤーの話になりますと、Google は GFS (Google File System) という独自の分散ファイルシステムを自前で構築していることを公表しています。
    http://dev.ariel-networks.com/modules/xfsection/article.php?articleid=50
    http://internet.watch.impress.co.jp/cda/special/2004/11/29/5561.html
    http://internet.watch.impress.co.jp/cda/event/2004/11/16/5430.html

    ということで、「Google は DB を使用していない」というのが、「MySQL のような RDBMS」のことを指しているのであれば、その認識は間違いではないと思いますよ。
    しかし、RDBMS に限らずデータベース全般を指して「DB」と呼んでいるのであれば、誤りですね。
  • id:yna1962
     一般的な意味でのRDBは使用していないというのは、有名な話です。検索エンジンのようなソフトを作成するのに、一般的なRDBは不向きです。
     概念としてはgoogleというデータベースを作っているというの正しい認識だと思います。
     単語のスペルを間違えたり、エラーコードのような変なコードを入力するとまったく拾ってこなかったりすることがあります。恐らく一種のキーワードを辞書を持っており、文書中に含まれるキーワードを拾っているのだと思います。
     
  • id:esecua
    やっぱりDBは使用していないのですね。
  • id:pmakino
    あー、上のコメントは読んでいただけなかったのでしょうか…(^^;
    「Google Web 検索のコアが RDBMS でない」なら正しいかもしれませんが、「Google が DB を使用していない」は間違いです。
    http://ja.wikipedia.org/wiki/%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9
    リレーショナルデータモデルを採用しているものだけが DB ではありません。
  • id:esecua
    貴重なご意見ありがとうございます。 回答欄でお答えいただければよかったのですが。
  • id:orangeissei
    orangeissei 2009/02/15 08:43:25
    googleはBigTable(?)っていうオリジナルのDB作ってますね.
    つい先日クローンがオープンソース化され,思わずニヤっとしたところです.
    http://ja.wikipedia.org/wiki/BigTable
    http://gigazine.net/index.php?/news/comments/20080208_hypertable/
    http://www.hypertable.org/

    古い質問へのコメントなのであまり意味をなしませんが,参考までに

この質問への反応(ブックマークコメント)

トラックバック

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません