AutoPartition in PGD#

PGD AutoPartitionを使用すると、テーブルを複数のパーティション、他のテーブルに分割し、必要に応じてパーティションを作成および削除できます。自動パーティション化は、データを管理可能なチャンクに分割できるため、時間の経過とともに増加する大規模なテーブルの管理に役立ちます。新しいパーティションを定期的に作成し、データ保持期間の有効期限が切れたら削除できます。

この機能は、パーティションの作成と削除の低競合ロックなどのPGDの機能を使用します。

PGD管理は、主にSQLで呼び出すことができるファンクションを使用して実行します。 PGDのすべてのファンクションはbdr スキーマで公開されています。 search_pathに配置しない限り、各ファンクションの名前をスキーマ修飾する必要があります。

パーティションの自動作成#

PGD AutoPartitionは bdr.autopartition() を使用します

テーブルの自動レンジパーティションの定義を作成または変更するファンクション。定義が存在しない場合、作成されます。それ以外の場合、後の実行で定義が変更されます。

PGD 5.5以降のPGD AutoPartitionは、基になるPostgres機能を活用して、テーブルの残りの部分をロックせずにパーティションをアタッチまたはデタッチ/ドロップできます。 5.5より前のバージョンのPGDはこの機能をサポートしておらず、テーブルをロックします。

テーブルがRANGEパーティション化されていない場合、または複数列パーティションキーが使用されている場合、エラーが発生します。

自動パーティションテーブルでのDEFAULT パーティションの作成は、サポートされていません。 DDLを作成しようとするDDLは拒否されます。

デフォルトでは、AutoPartitionはパーティションをローカルに管理します。パーティションのローカルでの管理は、パーティション化されたテーブルがレプリケートテーブルでない場合に役立ちます。その場合、すべてのノードにすべてのパーティションを必要としないか、したくない場合があります。例、ビルトイン bdr.conflict_history

テーブルはレプリケートテーブルではありません。これはAutoPartitionによってローカルに管理されます。各ノードはこのテーブルのパーティションをローカルに作成し、十分に古くなると削除します。

次のことも考慮します。

アクティビティは、エントリーがenabled = on とマークされている場合にのみ実行されます。
AutoPartitionによって管理されるテーブルのパーティションを手動で作成または削除しないことをお勧めします。そうすると、AutoPartitionメタデータの一貫性がなくなり、障害が発生する可能性があります。

AutoPartitionの例#

日次パーティション、データを1か月間保持します

CREATE TABLE measurement (
logdate date not null,
peaktemp int,
unitsales int
) PARTITION BY RANGE (logdate);

bdr.autopartition(measurement, 1 day, data_retention_period := 30 days);

パーティションがあと2つだけ残っている場合、5つの事前パーティションを作成します。各パーティションには、10億の注文を保持できます。

bdr.autopartition(Orders, 1000000000,
        partition_initial_lowerbound := 0,
        minimum_advance_partitions := 2,
        maximum_advance_partitions := 5
     );

RANGEパーティションテーブル#

PGD自動パーティション化は、 RANGE キーワードを使用したレンジパーティション化をサポートしています。レンジパーティション化を使用すると、列の値の範囲に基づいてテーブルをパーティション化できます。たとえば、日付でテーブルをパーティション化できます。各パーティションには、特定の日付範囲のデータが含まれます。これは、データを管理可能なチャンクに分割できるため、時間の経過とともに増加する大規模なテーブルの管理に役立ちます。

partition_increment 値の範囲ごとに新しいパーティションが追加されます。下限と上限はpartition_increment 離れています。 timestamp またはdate タイプのパーティションキーを持つテーブルの場合、 partition_increment はinterval タイプの有効な定数である必要があります。たとえば、 1 Day を指定すると、新しいパーティションが毎日追加され、パーティション境界は1日ごとに追加されます。

パーティション列がsnowflakeid 、timeshard 、またはksuuid シーケンスに接続されている場合、partition_increment をinterval タイプとして指定する必要があります。それ以外の場合、パーティションキーが整数または数値の場合、 partition_increment は同じデータ型の有効な定数である必要があります。たとえば、 1000000 を指定すると、100万の値ごとに新しいパーティションが追加されます。

テーブルに既存のパーティションがない場合、指定されたpartition_initial_lowerbound が最初のパーティションの下限として使用されます。 partition_initial_lowerbound を指定しない場合、システムはパーティション列タイプと指定されたpartition_increment からその値を導き出そうとします。たとえば、 partition_increment が1 Day として指定されている場合、 partition_initial_lowerbound はCURRENT DATEに設定されます。 partition_increment が1 Hour として指定される場合、 partition_initial_lowerbound は現在の日付の現在時間に設定されます。後続のパーティションの境界は、partition_increment 値を使用して設定されます。

システムは常に特定の最小数の事前パーティションを持とうとします。新しいパーティションを作成するかどうかを決定するために、指定されたpartition_autocreate_expression を使用します。これは、チェックが実行されるたびに評価されるSQLによって評価できる式です。たとえば、列タイプdate のパーティションテーブルの場合、partition_autocreate_expression がDATE_TRUNC('day',CURRENT_DATE) として指定され、partition_increment が1 Day として指定され、minimum_advance_partitions が2 として指定されるとします。次に、最後のパーティションの上限がDATE_TRUNC('day', CURRENT_DATE) + '2 Days'::interval 未満になるまで、新しいパーティションが作成されます。

式は、システムが新しいパーティションをチェックするたびに評価されます。

列タイプinteger のパーティションテーブルの場合、partition_autocreate_expression をSELECT max(partcol) FROM schema.partitioned_table として指定できます。次に、システムは、パーティション化された列の最大値が最後のパーティションの上限のminimum_advance_partitions * partition_increment の距離内にあるかどうかを定期的にチェックします。クエリーが効率的に実行されるように、 partcol にインデックスを作成します。カラムタイプinteger 、smallint 、またはbigint のパーティションテーブルにpartition_autocreate_expression を指定しない場合、システムはmax(partcol) に設定します。

data_retention_period が設定されている場合、パーティションはこの期間の後にドロップされます。ロックを最小限に抑えるために、新しいパーティションが追加されると同時にパーティションが削除されます。この値を設定しない場合、パーティションを手動で削除する必要があります。

data_retention_period パラメーターは、タイムスタンプベースおよび関連するパーティションでのみサポートされています。期間は、パーティションの上限を考慮して計算されます。上限と比較して、指定された期間が満了すると、パーティションはドロップされます。

パーティションの自動作成の停止#

bdr.drop_autopartition() を使用する

指定されたリレーションの自動パーティションルールを削除します。リレーションの保留中の作業項目はすべて削除され、新しい作業項目は作成されません。

パーティションの作成を待機しています#

パーティションの作成は非同期プロセスです。 AutoPartitionは、ローカルまたはすべてのノードでパーティションが作成されるのを待機する一連の機能を提供します。

bdr.autopartition_wait_for_partitions() を使用する

ローカルノードでパーティションの作成を待機します。ファンクションは、パーティションテーブル名とパーティションキー列値を取得し、その値を保持するパーティションが作成されるまで待機します。

このファンクションは、パーティションがローカルに作成されるのをのみ待機します。パーティションがリモートノードにも存在することは保証されません。

すべてのPGDノードでパーティションが作成されるのを待機するには、

bdr.autopartition_wait_for_partitions_on_all_nodes() を使用します

ファンクション。このファンクションは、ローカルノードとすべてのリモートノードを内部的にチェックし、パーティションがどこでも作成されるまで待機します。

パーティションの検索#

bdr.autopartition_find_partition() を使用します

指定されたパーティションキー値のパーティションを見つけるファンクション。その値を保持するパーティションが存在しない場合、ファンクションはNULLを結果ます。それ以外の場合、パーティションのOidを結果ます。

自動パーティショニングの有効化または無効化#

bdr.autopartition_enable() を使用する

指定されたテーブルで自動パーティション化を有効にします。自動パーティション化が既に有効になっている場合、アクションは発生しません。同様に、

bdr.autopartition_disable() を使用します

指定されたテーブルで自動パーティショニングを無効にします。

パーティションの削除またはデタッチ#

デフォルトでは、 data_retention_period の有効期限が切れると、 autopartition() によって管理されるテーブルのパーティションがデタッチおよびドロップされます。 drop_after_retention_period パラメーターはこの動作を制御できるため、これらのパーティションを保持することを選択できます。 false に設定すると、パーティションは親テーブルからデタッチされるだけで、ドロップされません。これにより、ユーザーは最終的に削除する前にパーティションを他のテーブルに再アタッチしたり、処理したりできる可能性があります。パラメーターのデフォルト値はtrue であるため、既存または新しい自動パーティションテーブルでは、 data_retention_period の有効期限が切れるとパーティションはドロップされます。デタッチされたがドロップされていないパーティションを処理するには、これらのパーティションを他のテーブルに手動で再アタッチするか、ドロップします。

AutoPartition in PGD

目次