0

1日に約15GB以上のHTMLファイルをスクレイピングして保存する必要があるWebスクレイパーを実装しています。日々のデータ量も同様に増加する可能性があります。

スクレイピングしたデータをできるだけ長く保存するつもりですが、すべてのページについて少なくとも 1 か月は完全な HTML ファイルを保存したいと考えています。

私の最初の実装では、HTML ファイルをディスクに直接書き込みましたが、すぐに inode 制限の問題に遭遇しました。

私が次に試したのは、Couchbase 2.0 をキー/バリュー ストアとして使用することでしたが、Couchbase サーバーは Web スクレイピング書き込みの 5 ～ 8 時間後に Temp_OOM エラーを返し始めました。Couchbase サーバーを再起動することが唯一の復旧方法です。

MongoDB は良いソリューションでしょうか? この記事は私を心配させますが、彼らの要件は私が必要とするものを超えているようです.

また、Cassandra と HDFS についても少し調べましたが、これらのソリューションが私の問題に対して過剰であるかどうかはわかりません。

データのクエリに関しては、特定のページ データの URL と日付を取得できれば問題ありません。データもほとんどの場合、1 回書き込み、1 回読み取り、将来の読み取りに備えて保存されます。

このような大量の HTML ファイルの保存に関するアドバイスは役に立ちます。

4

2 に答える 2

1

HTML ページごとに 50kB と仮定すると、毎日 15GB で 1 日あたり 300.000+ ページになります。月10万くらい。

MongoDB は間違いなく、このデータ量でうまく機能します。その制限に関しては、データをどのように読み取って分析するかによってすべてが異なります。その量のデータがあれば、map/reduce 機能を利用できます。

ただし、問題のサイズがさらに拡大する可能性がある場合は、他のオプションを検討することをお勧めします。Google 検索エンジンが BigTable を HTML データのストレージとして使用していることは注目に値するかもしれません。その意味で、ユースケースで Cassandra を使用することは適切な場合があります。Cassandra は、優れた永続的な書き込み/読み取りパフォーマンスを提供し、データ ボリュームをはるかに超えて水平方向にスケーリングします。

于 2013-05-23T21:50:29.010 に答える
0

Cassandra を使用してこれらのエラーが発生したときにどのような展開シナリオを行ったのかわかりません..問題の原因を知るには、さらに調査が必要になる場合があります。上記の要件に従って、Cassandra は正常に動作し、5 時間後に停止することはないため (ストレージに問題がない限り)、エラーを追跡して原因を知る必要があります。

MongoDB を試してみることをお勧めします。MongoDB は非常に強力で、必要なものに合わせて最適化されており、上記の要件について文句を言うべきではありません。

HDFS を使用することはできますが、MongoDB (または Cassandra でさえ) が使用できるため、実際には必要ありません。

于 2013-05-23T22:41:56.603 に答える