web-dev-qa-db-ja.com

PostgreSQLの適切なストレージサイズ推定手法

本番用にPostgreSQLデータベースを準備しています。このデータベースのストレージサイズを見積もる必要があります。私たちはデータベース管理の専門知識が低い開発者のチームなので、調査を行い、マニュアルを読み、一般的な情報技術の知識を使用してこれを実現しています。

このデータベースに移行する実際のデータがあり、成長の大まかな見積もりがあります。例として、年間50％の成長率の見積もりがあるとします。

ポイントは：適切なサイズ推定を行うための一般的な適切な手法は何ですか？

ストレージの使用量は、以下のルールで見積もります。アドバイスが必要なトピックには、太字のテキストが付いています。プロセス全体に関するフィードバックは大歓迎です。

  1. 各テーブルのサイズを見積もる
    1. 各行の実際のサイズを確認します。
      • 固定サイズのフィールド（bigint、charなど）の場合、 documentation で説明されているサイズを使用しました
      • 動的なサイズのフィールド（textなど）の場合、文字列の長さを見積もり、関数select pg_column_size('expected text here'::text)を使用しました
      • PostgreSQLが内部で使用する[〜＃〜] oid [〜＃〜]に4バイト追加しました
    2. 各行のサイズに推定行数を掛けます
    3. 行やテーブルのメタデータなど、ここでオーバーヘッドを考慮する必要がありますか？
  2. 各テーブルインデックスのサイズを見積もる
    • これを見積もる方法がわからない、ここでアドバイスが必要
  3. トランザクションログのサイズを見積もる
    • これを見積もる方法がわからない、ここでアドバイスが必要
  4. バックアップのサイズを見積もる（フルおよび増分）
    • これを見積もる方法がわからない、ここでアドバイスが必要

  5. 実際の最小サイズのすべての見積もりを合計します

  6. 1年後の最小サイズの見積もり1、2、4の合計に1.5倍（50％の増加）の係数を適用します

  7. 安全係数を適切にするには、概算係数1.2〜1.4（20％〜40％以上）を推定5および6に適用します

ルールがかなり広まったことは知っています。理解を深めるために例が必要かどうか教えてください。

postgresqlscalabilitydatabase-size
5
Bruno Polaco

ポイント1）については、ドキュメントの ストレージページレイアウト の章を読み、特に行のメタデータのHeapTupleHeaderData Layoutテーブルを検討する必要があります。レベル。

行ごとの4バイトOIDは、ユーザーテーブルでは廃止されました。PostgreSQLでは、8.1以降、デフォルトでそれらがなくなりました。これは、default_with_oids構成パラメーターまたはWITH(OIDS)によって制御されるようになりましたCREATE TABLEの句。

データの大部分がライブである（頻繁に更新される）場合、UPDATEは新しいバージョンの挿入に続いて古いバージョンの削除に続き、できれば未使用のスペースを可能な限り再利用することと同等であるため、ディスクサイズの見積もりはより困難です。ここで機能するテーブルのfillfactorストレージオプションもあります（ CREATEのストレージパラメータセクションを参照） TABLE ）

また、インデックスレベルでの膨張もあります。書き込みが多いテーブルの場合、インデックスがその最適なサイズの数倍になることも珍しくありません。

[〜＃〜] vacuum [〜＃〜] について少し学習して、特定の使用法でテーブルとインデックスの膨張の影響を受ける可能性があるかを把握する必要があるかもしれません。

トランザクションログのサイズは、データベースへの書き込み量に完全に依存します。

5
Daniel Vérité

適切なサイズ推定を行うための一般的な適切な手法は、スキーマをモックアップして、偽のデータでテーブルを埋めることです。そのためには、generate_series関数が役立ちます。手動で行うプロセスでエラーがどのように満たされたかを理解するために、（1）を肉付けし始めたため、（3）で疑われたように、行ごとに約24バイトのヘッダー情報が欠落しており、通常のテーブルのOIDはもうありません。

インデックスサイズの見積もりはさらに困難です。データと比較してどの程度コンパクト化されるかは、そのデータの変動量によって異なります。また、Bツリーインデックスのしくみが原因で、直線的に増加することもありません。また、UPDATEとDELETEの負荷が高いワークロードでは、時間の経過とともに、ほとんどがINSERTのインデックスよりもはるかに大きなインデックスが取得されます。ワークロードをシミュレートしてしばらくの間、いくつかのテストデータを噛まない限り、これに数値を付けることは本当に困難です。

メインデータベースディレクトリのトランザクションログのサイズは、checkpoint_segmentsパラメータによって制限されます。それに関するドキュメントは、サイズを推定するためのいくつかの公式を示していますが、最悪の場合、サイズは約16MB * 3 * checkpoint_segmentです。それがそのサイズまで大きくなり、それ自体が剪定を開始すると、修正され、通常、より大きなデータベースの他のすべてのものと比べて簡単です。

データベースのバイナリバックアップを行うと、データベースと同じサイズになります。増分データは通常、一連のWALファイルとして保存されます。これらは、サイジングを検討する際に重要なトランザクションログです。 WALのフォーマットは複雑すぎて手動でサイズを設定することはできませんが、とりわけcheckpoint_segmentsなどに大きく依存しています。繰り返しますが、それを見積もるには、シミュレーションを実行して、その実行中にいくつのWALファイルが吐き出されるかを確認するしかありません。

論理的なテキストベースのバックアップを行うこともできます。それらの大きさは、使用しているデータ型によって異なります。テキスト形式は大きくなりますが、数値形式は、最も単純な例として、文字列形式よりもはるかに大きくなります。再度、最も簡単な見積もり方法は、いくつかのデータをシミュレートし、pg_dumpを使用してそれをプレーンテキストに保存し、推定することです。

3
Greg Smith