2

ウィキペディア (英語) に関するリンク構造データをできるだけ転送し終えました。基本的に、ウィキペディアの最新のダンプ リポジトリから SQL ダンプをダウンロードしました。MySQL の代わりに PostgreSQL を使用しているため、パイプライン シェル コマンドを使用して、これらすべてのダンプをデータベースにロードすることにしました。

とにかく、これらのテーブルの 1 つに 2 億 9500 万行あります。pagelinksテーブルです。すべてのウィキ内ハイパーリンクが含まれています。私のラップトップから、pgAdmin III を使用して、次のコマンドをデータベース サーバー (別のコンピューター) に送信しました。

SELECT pl_namespace, COUNT(*) FROM pagelinks GROUP BY (pl_namespace);

それは今1時間ほどそこにあります。問題は、postmaster が私の非常に限られた HD スペースをますます食い尽くしているように見えることです。今のところ20GBくらい食ったと思います。以前、12 GB の RAM で実行されているため、パフォーマンスの柔軟性を高める (つまり、より多くのリソースを使用できるようにする) ために、postgresql.conf ファイルをいじってみました。私は基本的に、このファイルのほとんどのバイトとそのような関連変数を4倍にして、より多くのRAMを使用してそのことを行うと考えていると思います.

ただし、データベースはあまり RAM を使用していないようです。Linux システム モニターを使用すると、postmaster が 1.6 GB の共有メモリ (RAM) を使用していることがわかります。とにかく、 PostgreSQL が HD リソースをどのように使用しているかを本当に理解していないようです。

ウィキペディア データベースのメタ構造に関しては、役に立つか、興味があるかもしれない優れたスキーマを提供します。

詳細についてはお気軽にお問い合わせください thx.

4

3 に答える 3

3

問題を引き起こしているのはおそらくGROUPBYです。グループ化を行うには、データベースで行を並べ替えて、重複するアイテムをまとめる必要があります。インデックスはおそらく役に立ちません。封筒裏の計算：

各行に100バイトのスペースが必要だとすると、29,500,000,000バイト、つまり約30GBのストレージになります。それらすべてをメモリに収めることができないため、システムがスラッシングし、操作が1000倍以上遅くなります。スワップファイルを使用している場合、HDスペースがスワップスペースに表示されなくなる可能性があります。

この計算を1回だけ実行する必要がある場合は、データの小さなサブセットに分割してみてください。pl_namespaceが数値であり、範囲が1〜295百万であると仮定して、次のようなものを試してください。

SELECT pl_namespace, COUNT(*)
FROM pagelinks
WHERE pl_namespace between 1 and 50000000
GROUP BY (pl_namespace);

次に、50000001-100000000などについても同じようにします。UNIONを使用して回答を組み合わせるか、外部プログラムを使用して結果を集計します。GROUPBYを支援しないインデックスについて私が書いたことを忘れてください。ここで、インデックスはWHERE句に役立ちます。

于 2009-01-03T21:25:01.813 に答える
1

9.5MB の RAM しか使用していないと主張しているのは、正確には何ですか? それは私にはありそうにないように思えます-共有メモリはほぼ確実に、異なるPostgresプロセス間で共有されているRAMです。(私が覚えている限りでは、各クライアントは最終的に個別のプロセスになりますが、かなり時間が経っているので間違っている可能性があります。)

列にインデックスがありpl_namespaceますか? 非常に多くの個別の結果がある場合、インデックスのない 2 億 9,500 万行のテーブルでクエリがかなり重くなることが想像できます。そうは言っても、10GBは飲み込むのが大変です。どのファイルに書き込んでいるか知っていますか？

于 2009-01-03T20:27:50.807 に答える
0

わかりましたので、ここにその要点があります：

GROUP BY 句がインデックスを無効にしたため、postmaster (postgresql サーバー プロセス) は、ディレクトリ $PGDATA/base/16384/pgsql_tmp にある一連のテーブル (23GB のテーブル) を作成することにしました。

postgresql.conf ファイルを変更するときに、postgreSQL に 1.6 GB の RAM を使用する許可を与えました (11.7 GB の RAM にアクセスできるようになったため、これを 2 倍にします)。postmaster プロセスは実際に 1.6 GB の RAM を使用していましたが、それだけでは十分ではなかったため、pgsql_tmp ディレクトリが使用されました。

Barry Brown が指摘したように、私はこの SQL コマンドを実行してpagelinks.namespaces間のリンクの分布に関する統計情報を取得しただけだったので、2 億9600万のページリンクのサブセットを照会できたはずです(これが彼らの仕事です)。調査用）。

コマンドが結果セットを返すと、何も起こらなかったかのように、すべての一時テーブルが自動的に削除されました。

助けてくれてありがとう！

于 2009-01-03T21:43:02.557 に答える