非常に揮発性の高いデータを保持する整数型の100〜300列のテーブルがいくつかあります。データセットは1つまたは2つの主キーでキー設定され、更新が発生すると、データセット全体が削除され、新しいデータが1つのトランザクションに挿入されます。データセットのサイズは通常数百行ですが、極端な場合には最大数千行になることがあります。更新は1秒に1回行われ、さまざまなキーのデータセットの更新は通常ばらばらであるため、テーブルの削除と再作成は実行できません。
そのような負荷を処理するようにPostgresをどのように調整しますか？違いがある場合は、最新かつ最高のバージョンを使用できます。
回答:
データセットの数に応じて、1つのオプションは、データセットごとにテーブルを分割することです。
データセットが更新されるとBEGIN、新しいトランザクション、TRUNCATEテーブル、COPYそこへの新しいデータ、およびCOMMIT。PostgreSQLは、最適化しているCOPYをされているテーブルにINGのTRUNCATED と同じトランザクションでは、使用している場合ははるかに少ないI / Oを行いますwal_level = minimal（デフォルト）。
パーティション分割および切り捨てができない場合（たとえば、数十または数十万のデータセットを処理していて、テーブルが多すぎる場合）、代わりに、autovacuumを最大にして、できるだけ多く実行するようにします。に基づいて、削除したものに適切なインデックスがあることを確認し、やや通常のパフォーマンスに備えてください。
クラッシュの安全性が必要ない場合- システムクラッシュ後のテーブルが空であってもかまいません-としてテーブルを作成することもできますUNLOGGED。これにより、I / Oコストを大幅に節約できます。
システムクラッシュ後、バックアップからセットアップ全体を復元する必要がない場合は、さらに一歩進んで設定することもできますfsync=off。これにより、基本的にPostgreSQLに「クラッシュの安全性に煩わされることはありません。適切なバックアップがあります。クラッシュ後に自分のデータが完全に完全に回復できなくなっても気にしないでくださいinitdb。データベースを再び使用できるようになる前に、喜んで再利用できます。」
これについては、高速テスト用にPostgreSQLを最適化することについて、Stack Overflowの同様のスレッドで詳しく説明しました。これは、ホストOSのチューニング、unloggedテーブルを使用していない場合はWALを別のディスクに分離すること、チェックポインタの調整などについて言及しています。
Pgのドキュメントには、データの高速読み込みと永続的でない設定に関する情報も含まれています。
SIGKILL編集など）、UNLOGGEDテーブルはTRUNCATEdになる可能性があるため、起動時に空になります。完全にシャットダウンして再起動した後は切り捨てられませんが、耐久性に依存するべきではありません。
UNLOGGEDテーブルごとにオプションがあることは素晴らしいことです。
TRUNCATEまたはDROP/CREATE TABLEシーケンスですか？
TRUNCATE個人的にお勧めします。DDLチャーンには独自のコストがあります。このような高い頻度で変更を加えているので、自動バキュームの積極性とpg_catalog.pg_class、そのワークロードで膨らむ可能性のある他のシステムテーブルを確実に有効にすることが非常に重要です。