4

私は次のプロジェクトのためにさまざまなMVCC対応データベースを検討しており、PostgreSQLが私のレーダーに登場しました。

私のプログラムの要件には、おおよそ次のようなシーケンスが含まれます。

  1. データベースの現在のバージョンからいくつかの情報を読み取り、データの80〜90％を変更して、1つ以上のトランザクションに書き戻します（グリッドの新旧両方の状態が存在するConwayのGame of Lifeでグリッドを更新するようなものを想像してください）が必要です）。

  2. コミット後1〜2分待ちます。この間、クライアントは新しいデータに対して読み取りを発行できます。

  3. 繰り返す。

データベースは2〜4GBのようなものに制限されます。

変更の約90％は既存のオブジェクトの更新であり、約5％は新しいオブジェクトであり、約5％は削除されたオブジェクトです。

だから私の質問は、ステップ1.5としてプレーンなVACUUMコマンドを1〜2分ごとに1回実行し、PostgreSQLが毎回2〜3GB以上の変更に対応できるようにすることができるかということです。

4

1 に答える 1

5

私はPostgresがこのシナリオでうまくいくはずだと信じています。このシナリオは非常に珍しいため、大規模な更新間の手動バキュームは妥当なオプションのように思われます。

大量の更新の代わりに、新しいテーブルのセットを生成して分析し（必要です！）、トランザクションddlの力を利用して、古いテーブルを削除し、新しいテーブルの名前を元の場所に変更できるようにすることができるかどうかを検討してください。 。これにより、VACUUMに関する心配が軽減されます。

このようなシナリオでは、深刻な調整を行う必要があります。特に、shared_buffers、チェックポイント関連のパラメーター、およびバキューム関連のパラメーターを確認してください。また、現実的なワークロードでのベンチマークについても覚えておいてください。

于 2012-03-13T23:40:17.570 に答える