0

私は Java で Web クローラーを作成し、クロールするページを保存するために Berkeley DB を使用しています (後でインデックスを作成するためなど)。各ページを Webpage オブジェクトとして保存しています。これには次のインスタンス フィールドがあります。

@PrimaryKey
String url;
String docString;
Date lastVisited;
Date lastChecked;
ArrayList<String> stringLinks;

最大のフィールドは文字列 docString で、これは HTML コンテンツ全体 (通常、巨大なページでも 500KB 以下) であり、stringLinks はページ上のアウトバウンド リンクごとに文字列を保持します。これは大きすぎてはいけません。せいぜい長さが 70 の 100 文字列です (数 KB でさえありません)。

私は 1 秒あたり 1 ページよりも少し速くクロールし、1 秒あたり 2 ページになることもあります。また、バークレー データベースが 1 ページあたり約 2 ~ 3 MB に成長しているのを見ています。データベースは Web ページを EntityStore に保存し、定期的に同期します。何を変えてもディスク使用率が下がらない!

これはかなり大きな問題です。クローラーの複数のインスタンスを実行すると (分散するようにビルドしました)、それぞれが大量のディスク領域をすばやく使用するからです。これが直線的に増加している場合は問題ないかもしれませんが、この空間がどの関数によって膨張しているのかを知る方法はありません。私が知っているのは、実際のデータのスペースの何倍もあるということだけです。

EntityStore について欠けているものはありますか?

注意すべきことの1つは、DBからの読み取りと書き込みの両方を行っているため、フラグを設定して書き込み専用にすることはできません。また、これはヒープ スペースの影響を受けやすい環境であるため、キャッシュ サイズをあまり大きくしたくないと考えています。

4

1 に答える 1

0

問題は遅延書き込みにありました。各プットで env.sync() を呼び出すのではなく、遅延書き込みを有効にしてから、タイマーで env.sync() を呼び出して DB をチェックする必要がありました。サイズは 30 分の 1 に縮小されました...

于 2012-05-01T03:52:53.623 に答える