PostgreSQL初期データベースサイズ

私の質問には2つの部分があります。

1. PostgreSQLのデータベースの初期サイズを指定する方法はありますか？
2. 存在しない場合、データベースが時間の経過とともに大きくなった場合の断片化にどのように対処しますか？

最近、MSSQLからPostgresに移行しました。データベースを作成するときにMSSQLの世界で行ったことの1つは、データベースとトランザクションログの初期サイズを指定することでした。これにより、特にデータベースの「通常の」サイズが事前にわかっている場合、断片化が減少し、パフォーマンスが向上します。

サイズが大きくなると、データベースのパフォーマンスが低下します。たとえば、私がそれを実行しているワークロードは通常10分かかります。データベースが大きくなると、この時間が長くなります。VACUUM、VACUUM FULL、およびVACUUM FULL ANALYZEを実行しても問題は解決しないようです。パフォーマンスの問題を解決するのは、データベースを停止し、ドライブの断片化を解消してから、VACUUM FULL ANALYZEを実行すると、テストのパフォーマンスが元の10分に戻ります。これは、断片化が痛みの原因であると疑うことにつながります。

Postgresでテーブルスペース/データベーススペースを予約するための参照を見つけることができませんでした。間違った用語を使用しているため何も見つからないか、Postgresでファイルシステムの断片化を緩和する別の方法があります。

ポインタはありますか？

ソリューション

提供された回答は、私が疑い始めたことを確認するのに役立ちました。PostgreSQLはデータベースを複数のファイルに保存します。これにより、断片化の心配なしにデータベースを拡張できます。デフォルトの動作では、これらのファイルをテーブルデータでいっぱいにパックします。これは、ほとんど変更されないテーブルには適していますが、頻繁に更新されるテーブルには適していません。

PostgreSQLはMVCCを使用して、テーブルデータへの同時アクセスを提供します。このスキームでは、更新ごとに更新された行の新しいバージョンが作成されます（これはタイムスタンプまたはバージョン番号を使用している可能性があります）。古いデータはすぐには削除されませんが、削除のマークが付けられます。実際の削除は、VACUUM操作が実行されるときに発生します。

これは曲線因子とどのように関係しますか？テーブルのデフォルトのフィルファクター100はテーブルページを完全にパックします。つまり、テーブルページ内に更新された行を保持するスペースがないことを意味します。つまり、更新された行は元の行とは異なるテーブルページに配置されます。私の経験が示すように、これはパフォーマンスに悪いです。サマリーテーブルは非常に頻繁に更新されるため（最大1500行/秒）、20のFILL FACTORを設定することを選択しました。つまり、テーブルの20％が挿入行データ用で、80％が更新データ用です。これは過度に思えるかもしれませんが、更新された行のために予約された大量のスペースは、更新された行が元のページと同じページ内に留まり、autovacuumデーモンが古い行を削除するまでにテーブルページがいっぱいにならないことを意味します。

データベースを「修正」するために、次のことを行いました。

1. サマリーテーブルのFILL FACTORを20に設定します。作成時にこれを行うには、パラメーターをCREATE TABLEに渡すか、ALTER TABLEを介してファクトの後に渡します。次のplpgsqlコマンドを発行しました。ALTER TABLE "my_summary_table" SET (fillfactor = 20);
2. VACUUM FULLを発行しました。これにより、完全に新しいバージョンのテーブルファイルが書き込まれ、含意により新しいフィルファクターで新しいテーブルファイルが書き込まれます。

テストを再実行すると、数百万行のデータベースが必要な大きさであっても、パフォーマンスの低下は見られません。

TL; DR-ファイルの断片化は原因ではなく、表スペースの断片化でした。これは、特定のユースケースに合わせてテーブルのFILL FACTORを調整することで軽減されます。

1. これに近いのは、-with-segsizeスイッチを使用してサーバーをコンパイルするときだけです。これは、テーブルがギグよりも多くのスペースを占有し、ファイルシステムがギグを超える単一のファイルを処理できる場合に役立ちます。20個のギグを挿入する場合、このスイッチを使用しないと20個のファイルを作成する必要があります。ファイルシステムがギグを介してファイルを処理できる場合は、大きな値に設定するだけで何らかの利点があり、最悪の場合は小さな利点があります。

2. CLUSTER http://www.postgresql.org/docs/9.1/static/sql-cluster.htmlおよびFILLFACTOR http://www.postgresql.org/docs/9.1/static/sql-createtable.htmlをご覧ください。http://www.postgresql.org/docs/9.1/static/sql-createindex.html

FILLFACTORはテーブルとインデックスの両方に適用できることに注意してください。

方程式をまだ入力していない別のことがあります：HOT update。関連する回答：

• PostgreSQLの原因不明のテーブルの膨張
• 通常のVACUUM ANALYZEは9.1でも引き続き推奨されますか？
• pg_stat_user_tablesのn_live_tupとn_dead_tupの意味は何ですか
• 遅いUPDATEクエリを高速化する方法

設定FILLFACTORとして低いと20 ん過度のように見えます。テーブルを最大サイズの5倍まで膨らませます。HOT更新が機能する場合、通常はそれほど低くする必要はありません。

例外があります：HOT更新は、同じまたは同時のトランザクションからではなく、以前のトランザクションからの無効なタプルのみを再利用できます。したがって、同じ行を繰り返し更新する重い同時ロードまたは長いトランザクションは、このような低い（またはさらに低い）設定を保証できます。

テーブルの大部分を一度に変更する大きな更新がある場合は、それらをいくつかのチャンクに分割し、理想的にはデータページにローカルに収まるだけの行を一度に変更することをお勧めします。しかし、それを推定し規制するのは困難です。

HOT更新は、変更された列が何らかの方法でインデックスに関与していない場合にのみ機能することに注意してください（データとしても、部分インデックスの条件としても）。更新された列のインデックスでHOT更新をブロックしている可能性があります。それらが消耗品である場合、それらがなくても全体的なパフォーマンスが向上する可能性があります。

最後に、テーブルごとに自動バキュームパラメータを設定できます。アグレッシブな設定で頻繁に更新されるテーブルをターゲットにして、のみよりも行のパッキングをやや厳しくすることができますFILLFACTOR 20。

問題がファイルの断片化である場合、いいえ、ありません。Postgresでは、各テーブルは独自のファイル、またはファイルシステムでTOASTを使用している場合はファイルのセットを取得します。これは、たとえば、テーブルをドロップする事前サイズのテーブルスペースファイルを作成するOracle（または明らかにMS-SQL）とは異なりますが、テーブルスペースファイルが拡張されたり、ファイルシステムが最初はひどく断片化されていました。

あなたの2番目の質問について... MS-Windowsは断片化の問題を経験した唯一のOSであり、MS-Windowsを絶対に実行しないので、ファイルシステムの断片化をきれいに処理する方法はわかりませんこれらの日が必要です。おそらく、データベースファイルを独自のディスクに配置すると、ある程度軽減される可能性があります。