データベースのテーブル膨張とは何ですか？
膨満がデータベースの意味で何を意味するのか誰かが説明できますか？たとえば、インデックスが肥大化しているとはどういう意味ですか。私はそれを探してみましたが、膨満が何であるか、何が原因であるのか、何が原因であるのかについての説明はありません。
PostgreSQLがトランザクションと並行処理を処理する方法、MVCC-マルチバージョン並行処理制御により、肥大化する可能性があります。 PostgreSQLでは、UPDATEまたはDELETEを実行しても、行が実際に物理的に削除されるわけではありません。 DELETEの場合、行は将来のトランザクションで使用不可としてマークされ、UPDATEの場合、内部ではINSERTとDELETEの組み合わせになります。行の以前のバージョンは使用不可とマークされます。
データは使用不可とマークされていますが、まだそこにあり、スペースは使用できません。次に、スペースをデータベースで使用できるようにマークするには、バキュームプロセスが操作の背後に来て、データベースが使用できるスペースをマークする必要があります。ただし、オペレーティングシステムには返されません。これは、ページ全体にアクティブな行がない場合にのみ発生します。これは、一部のワークロードでは一般的ではありません。これは、追加のデータファイルを追加する必要なく、データファイル内の個々のページのスペースを単に更新できるため、一部のワークロードに適しています。
ライブタプルと比較して、死んだタプルの数が非常に多い場合、膨張が問題になります。ウォークスルーしてすべての可視性フラグをチェックすると時間がかかり、リレーションのデータファイルが増えると、不要なIOロードが発生します。ブロートはインデックスで特に顕著であり、多くのデッドタプルも存在する可能性があります。 、テーブルよりもはるかに多い場合があります。Bloatはインデックスのルックアップとスキャンを遅くする可能性があり、クエリ時間の増加とクエリプランの変更で遅くなります。
pg_reorg 、 pg_repack 、CLUSTER、またはVACUUM FULLを使用してスペースを復元できます。これにより、ファイルを調べて再編成し、タプルを移動して再編成し、デッドタプルがないことを確認します。これにより、膨張がなくなります。
ブロートは、テーブルごとにVACUUM設定を調整することによって効率的に管理することもできます。これにより、後続のクエリで再利用できるデッドタプルスペースがマークされます。
Show Database Bloat および Index Bloat に関連するPostgreSQL Wikiのクエリを使用して、どれだけの膨張があるかを判断し、そこから少しパフォーマンスを分析して確認できます。テーブルにある膨らみの量に問題がある場合。
これはおそらく、2つの多くの列がインデックスに追加されているか、テーブルに重複するインデックスがあるインデックスの一般的な問題を参照しています。つまり、同じ列のセットを含む複数のインデックス（そのうちの1つを不要にします）。テーブルのすべてのインデックスを確認して、重複する列を探し、他のインデックスのサブセットにすぎないインデックスを探し、それらが使用されていないと判断できる場合は削除します。
さらに、テーブル内のデータが更新されると、インデックスが断片化され、必要以上に大きくなる可能性があります。私はpostgresに精通していませんが、ディスク上のサイズを小さくする（インデックスを再構築することによって）インデックスを最適化する方法があると思います。