TyphoeusとHydraの使用を見てください。URLを並行して処理するのが簡単になります。
各ページから特別なデータを要求する必要がない限り、Mechanizeを使用する必要はありません。通常のクローラーの場合、Mechanizeのオーバーヘッドや追加機能なしで、Open::URIとNokogiriを使用して本体を取得して解析できます。目的に応じて、Open :: URIの代わりにTyphoeusを使用し、Hydraにスレッド管理を処理させます。
200kのWebサイトをクロールすると、一度にすべてを実行しようとすると、帯域幅が飽和することを忘れないでください。それはあなたのRailsサイトを利用できなくするでしょう、それであなたはあなたの要求を絞る必要があります。そして、それはあなたが数時間（または何時間も）それらをしなければならないことを意味します。ここでサイトをオンラインに保つほど、速度は重要ではありません。おそらく、クローラーをRailsサーバーとは別のマシンに配置し、データベースにそれらを結び付けさせます。
クロールしているサイトのURLを含むテーブルまたはファイルを作成します。URLを編集/管理するためのフォームをまとめられるように、この表をお勧めします。次のようなものを追跡する必要があります。
- URLが最後にクロールされたとき。（日付時刻）
- 特定のURLをクロールする必要があるかどうか（ブール値または文字1）
- URL（Stringまたはvar char [1024]で問題ありません）。これは一意のキーである必要があります。
- そのURLが現在クロールされているかどうか（ブール値またはchar 1）。これは、すべてのレコードの実行の開始時にクリアされ、スパイダーがそのページをロードするときに設定され、残されます。
- そのサイトをいつ実行してもよいかを示すフィールド。
- そのサイトを実行しても問題がない時間を示すフィールド。
最後の2つは重要です。電力が不足している小さなサイトをクロールして、その接続を切断したくありません。それは禁止されるための素晴らしい方法です。
クロール中に遭遇したリンクから収集された特定のサイトをチェックするための次のURLである別のテーブルを作成します。セッションデータとパラメータを含むURLを、一意性をテストするために使用できるものに減らすための正規化ルーチンを考え出す必要があります。この新しいテーブルでは、URLを一意にして、ループに陥ったり、異なるパラメーターを使用して同じページを追加し続けたりしないようにする必要があります。
リダイレクトとDNS名はサイト内で異なる可能性があり、コンテンツを生成する人々は異なるホスト名を使用している可能性があるため、「get」URLではなくリダイレクト後に取得される実際のランディングURLに注意を払うことをお勧めします。同様に、ヘッドブロックでメタリダイレクトを探して、それに従うこともできます。これらはあなたが書きたいことをすることの特に苛立たしい側面です。
新しいURLに遭遇したら、それらが既存のURLであるかどうかを確認します。これにより、それらをフォローした場合、そのサイトを離れることになります。その場合は、それらをURLテーブルに追加しないでください。
正しいファイルを見つけるには、とにかくデータベース検索を行う必要があるため、データベース情報をファイルに書き込むことはおそらく役に立ちません。必要なものをフィールドに保存して、直接リクエストするだけです。200K行はデータベースには何もありません。
サイトの「スパイダー」ルールに注意してください。サイトがデータを取得するためのAPIを提供している場合は、クロールする代わりにそれを使用してください。