Sequences

Sequences#

多くのアプリケーションでは、一意のサロゲートIDをデータベースエントリに割り当てる必要があります。多くの場合、データベース SEQUENCE オブジェクトはこれらを生成するために使用されます。 PostgreSQLでは、これらは次のいずれかです。

  • CREATE SEQUENCE コマンドを使用して手動で作成し、nextval() ファンクションを呼び出して取得したシーケンス

  • serial およびbigserial 列またはGENERATED BY DEFAULT AS IDENTITY 列

ただし、 PostgreSQLの標準シーケンスはマルチノード対応ではなく、ローカルノードでのみ一意の値を生成します。このようなシーケンスによって生成された一意のIDは、マルチマスターレプリケーションで破棄されたINSERT アクションによる競合とデータ損失を発生させるため、これは重要です。

PGDグローバルシーケンス#

このため、 PGDは、 グローバルシーケンス と呼ばれる、 PGDグループ全体のbigintまたはbigserialデータ型のシーケンスを使用して、一意のIDを生成するアプリケーション透過的な方法を提供します。

PGDグローバルシーケンスは、アプリケーションがデータベースを使用して、ほとんどの場合に機能する非同期分散システムで一意の合成キーを生成する簡単な方法を提供しますが、必ずしもすべての場合ではありません。

PGDグローバルシーケンスを使用すると、挿入の競合に関する問題を回避できます。グローバルシーケンスを使用している列にPRIMARY KEY またはUNIQUE 制約を定義すると、ノードは他のノードと同じ値を取得できません。 PGDがノード間で挿入を同期すると、競合することはできません。

PGDグローバルシーケンスはPostgreSQLシーケンスを拡張するため、クラッシュセーフです。これらを使用するには、 bdr_applicationロールを付与される必要があります。

グローバルシーケンスにはさまざまなアルゴリズムが考えられます。

  • SnowflakeIdシーケンス

  • グローバルに割り当てられたレンジシーケンス

SnowflakeIdシーケンスは、どの時点でもノード間通信を必要としないアルゴリズムを使用して値を生成します。より速く、より堅牢で、値が作成されたときにタイムスタンプを記録する便利な特性があります。

SnowflakeIdシーケンスには、64ビットBIGINTデータ型でのみ動作し、最大19桁の長さの値を生成するという制限があります。これは、JavaScript Numberタイプなどの一部のホスト言語データ型で使用するには長すぎる場合があります。グローバルに割り当てられたシーケンスは、ノード間コンセンサスによって必要に応じて補充できるローカルな値の範囲を割り当て、BIGINTまたはINTEGERシーケンスに適しています。

bdr.alter_sequence_set_kind() を使用してグローバルシーケンスを作成できます

ファンクション。このファンクションは、標準のPostgreSQLシーケンスを取得し、PGDグローバルシーケンスとしてマークします。シーケンスを標準のPostgreSQLシーケンスに変換して戻すこともできます。

PGDは、構成変数 bdr.default_sequence_kind も提供します。この変数は、 CREATE SEQUENCE コマンドが実行されたとき、またはserial 、bigserial 、またはGENERATED BY DEFAULT AS IDENTITY 列が作成されたときに作成するシーケンスの種類を決定します。有効な設定は次のとおりです。

  • local —新しく作成されたシーケンスは、標準のPostgreSQLローカルシーケンスです。

  • galloc —常にグローバルに割り当てられたレンジシーケンスを作成します。

  • snowflakeid —時間、ノードID、およびカウンターコンポーネントで構成されるBIGINTシーケンスのグローバルシーケンスを作成します。 INTEGERシーケンスでは使用できませんので、 bigserial には使用できますが、 serial には使用できません。

  • timeshard — SnowflakeIdシーケンスの古いバージョン。下位互換性のためのみに提供されています。 SnowflakeIdが優先されます。

  • distributed デフォルト bdr.default_sequence_kind にのみ使用できる特別な値。 int8 シーケンスつまりbigserial の場合はsnowflakeid を選択し、int4 つまりserial およびint2 シーケンスの場合はgalloc シーケンスを選択します。

bdr.sequences ビューには、個々のシーケンス種類に関する情報が表示されます。

currval() およびlastval() ファンクションは、すべてのタイプのグローバルシーケンスで正しく動作します。

自動シーケンス変換#

PGD 6.0以降では、ノードをPGDグループに参加するか、新しいグループを作成する行為も、ローカルシーケンスのグローバルシーケンスへの変換をトリガーします。 bdr.default_sequence_kind をdistributed に設定します。この設定は、ローカルシーケンスの変換に最適な種類のシーケンスを選択します。 bdr.default_sequence_kind がlocal に設定されている場合、シーケンスはローカルシーケンスとして残されます。 galloc への変換は、シーケンスがグループ内の他のシーケンスと競合しないことを保証する方法で実行されます。

ローカルシーケンスで開始し、後でgallocシーケンスに切り替える場合は、bdr.default_sequence_kind をgalloc に設定し、変換する各シーケンスでbdr.alter_sequence_set_kind() ファンクションを実行します。ただし、シーケンスの開始値を手動で設定して、テーブル内の既存の値と競合しないようにする必要があることに注意してください。これ全般、特に How to set a new start value for a sequence の詳細については、 Converting a local sequence to a galloc sequence を参照してください。

SnowflakeIdシーケンス#

SnowflakeIdシーケンスによって生成されたIDは、緩やかな時間順序であるため、これらを使用して、標準のPostgreSQLシーケンスのように、データ挿入のおおよその順序を取得できます。 1つのノードでも、同じミリ秒以内に生成された値は順序が崩れる場合があります。緩い時間順序付けの特性は、レンジパーティションキーとしての使用に適していることを意味します。

SnowflakeIdシーケンスは1つ以上のノードで動作し、ノード参加プロセスが完了した後にノード間通信を必要としません。したがって、拡張ネットワーク分割のリスクがある場合でも、それらを使用し続けることができます。これらは、レプリケーション遅延やノード間レイテンシーの影響を受けません。

SnowflakeIdシーケンスは、標準のシーケンスとは異なる方法で一意のIDを生成します。このアルゴリズムは、シーケンス番号に3つのコンポーネントを使用します。シーケンスの最初のコンポーネントは、シーケンス番号生成時のタイムスタンプです。シーケンス番号の2番目のコンポーネントは、各PGDノードに割り当てられる一意のIDであり、これにより、異なるノードからのIDが常に異なることが保証されます。 3番目の成分は、ローカルシーケンスによって生成された数です。

競合がないことを保証には一意のノードIDをシーケンス番号に追加するだけで十分ですが、シーケンスの別の便利なプロパティも保持したいと思います。シーケンス番号の順序は、データがテーブルに挿入された順序にほぼ対応します。最初にタイムスタンプを配置することにより、これが保証されます。

SnowflakeIdシーケンスには、いくつかの制限と注意事項が適用されます。

SnowflakeIdシーケンスは64ビット幅で、bigint またはbigserial が必要です。生成される値は最大19桁の長さです。実用的な32ビットinteger バージョンがないため、 serial シーケンスでは使用できません。代わりに、グローバルに割り当てられたレンジシーケンスを使用します。

SnowflakeIdの場合、特定のノードでミリ秒ごとに生成されるシーケンス値4096の制限があります1秒あたり約400万シーケンス値。シーケンス値の生成が特定のミリ秒内でラップアラウンドする場合、SnowflakeIdシーケンスは次のミリ秒まで待機し、そのミリ秒の新しい値を取得します。

SnowflakeIdシーケンスはタイムスタンプをシーケンス値にエンコードするため、指定された時間フレーム内でのみ新しいシーケンス値を生成できますシステムクロックによって異なります。使用できる最も古いタイムスタンプは2016-10-07で、これはSnowflakeIdのエポック時間です。値は2086年に負の値にラップし、2156年までに数値が完全になくなります。

タイムスタンプはSnowflakeIdシーケンスの重要な部分であるため、Postgresプロセスの有効期間中に使用される最新のタイムスタンプより古いシーケンスを生成しないための追加の保護がありますただし、Postgresの再起動の間ではありません。

SnowflakeIdシーケンスの入力として使用されるシーケンスのINCREMENT オプションは、事実上無視されます。これは、多くのオブジェクトリレーショナルマッパーORMツール、特にHibernateと同様に、シーケンスIDキャッシュを行うアプリケーションに関連する可能性があります。シーケンスは時間ベースであるため、アプリケーションがキャッシュされた値で何かをできるようになるまでにシーケンスは新しい非衝突値に進むため、実際的な効果はほとんどありません。

同様に、基になるシーケンスのSTART 、MINVALUE 、MAXVALUE 、およびCACHE 設定を変更することもできますが、変更するメリットはありません。シーケンスの下位14ビットが使用され、残りは破棄されるため、値範囲制限はファンクションの結果に影響を与えません。同じ理由で、 setval() はSnowflakeIdシーケンスには役立ちません。

タイムシャードシーケンス#

タイムシャードシーケンスは、既存のインストールとの下位互換性のために提供されていますが、新しいアプリケーションの使用はお勧めしません。代わりにSnowflakeIdシーケンスを使用することをお勧めします。

TimeshardはSnowflakeIdに非常に似ていますが、制限が異なり、保護が少なく、パフォーマンスが低下します。

TimeshardとSnowflakeIdの違いは次のとおりです。

  • Timeshardは、ミリ秒ごとに最大16384秒ごとに約1600万を生成できます。これは、SnowflakeIdを超えています。ただし、特定のミリ秒内のラップアラウンドに対する保護はありません。 Timeshardシーケンスを使用するスキーマは、特定の列にtimeshard値を使用する場合、 UNIQUE 制約の使用を保護する必要があります。

  • Timeshardシーケンスのタイムスタンプコンポーネントは、2050年に値がなくなり、bigintと組み合わせて使用すると、値は2033年に負の数にラップします。これは、2033年以降に生成されたシーケンスが負の値を持つことを意味します。これはSnowflakeIdよりもかなり短い時間であり、これがSnowflakeIdが優先される主な理由です。

  • Timeshardシーケンスは、時折のディスク書き込みが必要です標準のローカルシーケンスと同様に。 SnowflakeIdはメモリで計算されるため、SnowflakeIdシーケンスは、一般にtimeshardシーケンスよりも少し高速です。

ログに記録されていないシーケンスとPGD#

Postgres 15以降、ログに記録されないシーケンスを作成できるようになりました。これらは関連しており、WALに書き込まれず、レプリケートされないログ非記録テーブルに似ています。 PGDとログなしシーケンスのコンテキストでは、ログなしのPGDシーケンスを持つことは合理的な構成ではなく、ノードに障害が発生した場合に予期しない問題を引き起こす可能性があります。したがって、ログのないPGD配列の作成、またはPGD配列のログのない配列への変換を防止します。

グローバルに割り当てられたレンジシーケンス#

グローバルに割り当てられたレンジまたはgalloc シーケンスは、値のレンジチャンクを各ノードに割り当てます。ローカルレンジが使い果たされると、他のノード間のコンセンサスによって、新しいレンジがグローバルに割り当てられます。この動作はキー空間を効率的に使用しますが、現在割り当てられているローカルレンジが使い果たされたときにシーケンスジェネレーターが進行するには、ローカルノードがクラスター内のノードの大部分に接続している必要があります。

SnowflakeIdシーケンスとは異なり、galloc シーケンスは、PostgreSQLが提供するすべてのシーケンスデータ型smallint 、integer 、およびbigint をサポートします。これは、64ビットシーケンスに問題がある環境でgalloc シーケンスを使用できることを意味します。例には、53ビット値のみをサポートするため、またはシーケンスが制限されたスペースで出力に表示される場合、JavaScriptでの整数の使用が含まれます。

各投票ノードによって割り当てられる範囲は、シーケンスが使用しているデータ型に基づいて、現在事前に決定されています。

  • smallint — 1 000数字

  • 整数 — 1 000 000番号

  • bigint — 1 000 000 000数字

各ノードは、seq_chunk_sizeの2つのチャンクを割り当てます。1つは現在の使用に、1つは将来の使用のために予約されたチャンクです。したがって、1つのノードから生成される値は単調増加します。ただし、グローバルに見ると、生成された値はまったく順序付けられていません。これは、bツリーインデックスへの影響によりパフォーマンスの低下を引き起こす可能性があり、通常は、生成された値がレンジパーティションキーとして役に立たないことを意味します。

galloc シーケンスの主な欠点は、割り当てられたレンジが使い果たされると、シーケンスジェネレーターがノード間通信を必要とするローカルノードの次のレンジに関するコンセンサスを求めなければならないことです。これにより、PGDグループの大部分がアクセスできない場合、遅延または操作の問題が発生する可能性があります。 (これは、後のリリースで回避される可能性があります。)

CACHE 、START 、MINVALUE 、およびMAXVALUE オプションは、galloc シーケンスで正常に動作します。ただし、シーケンスをgalloc 種類に変換する前に、それらを設定する必要があります。 INCREMENT BY オプションも正常に動作します。ただし、各シーケンスデータ型に割り当てられた上記の範囲以上の増分値を割り当てることはできません。 setval() は、galloc シーケンスのグローバル状態をリセットしません。使用しないでください。

galloc シーケンスには、いくつかの制限が適用されます。 PGDは、特別なPGDカタログ bdr.sequence_alloc のgalloc シーケンスを追跡します。このカタログは、galloc シーケンスに現在割り当てられているチャンクを追跡するために必要です。シーケンス名と名前空間はこのカタログに保存されます。シーケンスチャンクの割り当てはRaftによって管理されますが、シーケンス名前/名前空間の変更はレプリケーションストリームによって管理されます。したがって、PGDは現在galloc シーケンスの名前の変更、別の名前空間への移動、またはgalloc シーケンスを含む名前空間の名前の変更をサポートしていません。アプリケーションスキーマをデザインするときは、この制限に注意してください。

ローカルシーケンスのgallocシーケンスへの変換#

ローカルシーケンスをgallocに変換する前に、いくつかの前提条件に注意する必要があります。

1.シーケンスと列のデータ型が一致することを確認します#

シーケンスのデータ型が、使用される列のデータ型と一致することを確認します。たとえば、 bigint シーケンスを作成し、 integer 列のデフォルトをそのシーケンスによって返されるnextval() に割り当てることができます。 bigint の場合1 000 000 000のブロックで割り当てられるgallocシーケンスでは、3つ以上のノードが使用されている場合、nextval() によって返される値がすぐにint4 範囲を超えます。

この例は、何が起こり得るかを示しています。

CREATE SEQUENCE int8_seq;

SELECT sequencename, data_type FROM pg_sequences;
 sequencename | data_type
- -------------+-----------
 int8_seq     | bigint
(1 row)

CREATE TABLE seqtest (id INT NOT NULL PRIMARY KEY);

ALTER SEQUENCE int8_seq OWNED BY seqtest.id;

SELECT bdr.alter_sequence_set_kind(public.int8_seq::regclass, galloc, 1);
 alter_sequence_set_kind
- ------------------------

(1 row)

ALTER TABLE seqtest ALTER COLUMN id SET DEFAULT nextval(int8_seq::regclass);

2つのノードでINSERT INTO seqtest VALUES(DEFAULT) を実行した後、テーブルには次の値が含まれます。

SELECT * FROM seqtest;
     id
- -----------
          2
 2000000002
(2 rows)

ただし、3番目のノードで同じ操作を試行すると、シーケンスが値4000000002 を生成したため、integer out of range エラーで失敗します。

Tip

PostgreSQLからシーケンスの現在のデータ型を取得できます pg_sequences

ビュー。現在の値が新しいデータ型の最大値を超えない限り、 ALTER SEQUENCE ... AS ... たとえば ALTER SEQUENCE public.sequence AS integer を使用してシーケンスのデータ型を変更できます。

2.シーケンスの新しい開始値を設定します#

シーケンス種類がgalloc に変更されると、書き換えられ、ローカルシーケンスの定義された開始値からリスタートします。これが実稼働データベースの既存のシーケンスで発生した場合、現在の値を照会し、開始値を適切に設定する必要があります。このユースケースを支援するために、PGDではファンクション bdr.alter_sequence_set_kind() で開始値を渡すことができます。すでにオフセットを使用しており、複数のノードからの書き込みがある場合は、最大使用値を確認し、少なくとも次の値までシーケンスをリスタートする必要があります。

- - determine highest sequence value across all nodes
SELECT max((x->response->command_tuples->0->>nextval)::bigint)
    FROM jsonb_array_elements(
        bdr.run_on_all_nodes(
            ESELECT nextval(\public.sequence\);
            )::jsonb) AS x;

- - turn into a galloc sequence
SELECT bdr.alter_sequence_set_kind(public.sequence::regclass, galloc, $MAX + $MARGIN);

ユーザーはシーケンスをロックできないため、 $MARGIN 値を残して、 max() 値が照会されている間操作を続行できるようにする必要があります。

bdr.sequence_alloc テーブルは、チャンクサイズと、クラスター全体に割り当てられたレンジに関する情報を提供します。

この例では、シーケンスは333 で始まり、クラスターには2つのノードがあります。 割り当て数は4で、ノードごとに2であり、チャンクサイズは1000000で、整数シーケンスに関連しています。

SELECT * FROM bdr.sequence_alloc
    WHERE seqid = public.categories_category_seq::regclass;
          seqid          | seq_chunk_size | seq_allocated_up_to | seq_nallocs |       seq_last_alloc
- ------------------------+----------------+---------------------+-------------+-----------------------------
 categories_category_seq |        1000000 |             4000333 |           4 | 2020-05-21 20:02:15.957835+00
(1 row)

各ノードの特定のシーケンスに現在割り当てられているレンジを表示するには、ファンクション bdr.galloc_chunk_info を実行します。

  • ノードNode1 は、 333 〜2000333 のレンジを使用しています。

SELECT * FROM bdr.galloc_chunk_info(categories_category_seq);
 chunk_start | chunk_end
- ------------+-----------
         334 |   1000333
     1000334 |   2000333
(2 rows)

  • ノードNode2 は、 2000334 〜4000333 のレンジを使用しています。

SELECT * FROM bdr.galloc_chunk_info(categories_category_seq);
 chunk_start | chunk_end
- ------------+-----------
     2000334 |   3000333
     3000334 |   4000333

ノードはチャンクを終了すると、新しいチャンクのコンセンサスを求め、最初に利用可能なものを取得します。この例では、4000334〜5000333です。これは新しい予約チャンクであり、古い予約チャンクの消費を開始します。

UUID、KSUUID、およびその他のアプローチ#

PGDで使用できるグローバルシーケンスを使用せずに、他の方法でグローバルに一意のIDを生成できます。例

  • UUIDとそのPGDバリアントKSUUID

  • ノードごとに異なるオフセットを持つローカルシーケンスつまり手動

  • 外部調整されたナチュラルキー

PGDアプリケーションは、他の方法を安全に使用できません。 PGDはノード間で行ロックを取得しないため、シーケンス生成にSELECT ... FOR UPDATE 、UPDATE ... RETURNING ... または同様のものに依存するカウンターテーブルベースのアプローチは、PGDでは正しく動作しません。同じ値が複数のノードで生成されます。同じ理由で、「ギャップレス」シーケンス生成の通常の戦略はPGDでは機能しません。ほとんどの場合、アプリケーションは、2フェーズコミットを使用して外部ソースからギャップレスである必要があるシーケンスの生成を調整します。または、PGDグループ内の1つのノードでのみ生成されます。

KSUUID v2ファンクション#

PGDアプリケーションは、他の方法を安全に使用できません。 PGDはノード間で行ロックを取得しないため、シーケンス生成にSELECT ... FOR UPDATE 、UPDATE ... RETURNING ... または同様のものに依存するカウンターテーブルベースのアプローチは、PGDでは正しく動作しません。同じ値が複数のノードで生成されます。同じ理由で、「ギャップレス」シーケンス生成の通常の戦略はPGDでは機能しません。ほとんどの場合、アプリケーションは、2フェーズコミットを使用して外部ソースからギャップレスである必要があるシーケンスの生成を調整します。または、PGDグループ内の1つのノードでのみ生成されます。

UUID#

UUID キーは、代わりにシーケンスを完全に回避し、128ビットのユニバーサル一意識別子を使用します。これらはランダムまたは擬似乱数値であり、非常に大きいため、同じ値を2回生成することはほぼ不可能です。 UUID キーを使用する場合、ノードが継続的に通信する必要はありません。

万が一、衝突が発生した場合、競合検出は、挿入された2つのレコードの新しい方を選択して保持します。競合ログが有効になっている場合、このようなイベントが記録されます。ただし、約2^64キーが生成された後にのみ衝突が実際に可能になるため、発生する可能性は非常に低いです。

UUID キーの主な欠点は、領域とネットワークの点でやや非効率であることです。これらは、主キーとしてだけでなく、外部キーで参照される場合、および回線上で送信される場合にも、より多くの領域を消費します。また、すべてのアプリケーションがUUID キーにうまく対応できるわけではありません。

KSUUID#

PGDは、 UUID データのKソート可能なバリアントを操作するためのファンクションを提供します。 KSUUIDとして知られ、PostgreSQL標準のUUID データ型を使用して保存できる値を生成します。 KSUUID 値は、 UUID 標準に従って、タイムスタンプとランダムデータの両方を保存するという点でUUIDv1 に似ています。違いは、 KSUUID がKソート可能であること、つまりタイムスタンプで弱くソート可能であることを意味します。これにより、よりコンパクトなbtree インデックスが生成されるため、データベースキーとしてより役立ちます。この動作により、検索の効率が向上し、結果データの自然な時間ソートが可能になります。 UUIDv1 とは異なり、KSUUID 値には、生成されたコンピューターのMACが含まれないため、それらの使用にセキュリティ上の懸念はありません。

あらゆる場合にKSUUID v2を推奨するようになりました。通常の比較演算子で生成された値を直接並べ替えることができます。

PGDにはKSUUID の2つのバージョンv1およびv2があります。古いKSUUID v1は非推奨ですが、既存のインストールをサポートするために維持されます。新しいインストールには使用しないでください。 v1とv2の内部コンテンツには互換性がありません。そのため、それらを操作する機能も互換性がありません。 KSUUID のv2も、UUID バージョン番号を保存しなくなりました。

PGDリファレンスの KSUUID v2 functions および KSUUID v1 functions を参照してください。

ステップシーケンスとオフセットシーケンス#

オフセットステップシーケンスでは、各ノードで通常のPostgreSQLシーケンスが使用されます。各シーケンスは同じ量だけインクリメントし、異なるオフセットで開始します。たとえば、ステップ1000では、ノード1のシーケンスは1001、2001、3001などを生成します。 node2のシーケンスは、1002、2002、3002などを生成します。このスキームは、ノードが長期間通信できない場合でもうまく機能します。ただし、デザイナーはスキーマを確立するときにノードの最大数を指定する必要があり、ノードごとの構成が必要です。間違いにより、シーケンスのオーバーラップが簡単に発生する可能性があります。

次のように1つのノードで目的のシーケンスを作成することにより、 PGDでこのアプローチを構成するのは比較的簡単です。

CREATE TABLE some_table (
    generated_value bigint primary key
);

CREATE SEQUENCE some_seq INCREMENT 1000 OWNED BY some_table.generated_value;

ALTER TABLE some_table ALTER COLUMN generated_value SET DEFAULT nextval(some_seq);

次に、 setval() を呼び出す各ノードで、各ノードに異なるオフセット開始値を与えます。例

- - On node 1
SELECT setval(some_seq, 1);

- - On node 2
SELECT setval(some_seq, 2);

 -- ... etc

将来的に変更することは困難であり、中断を伴うため、追加するすべてのノードのための領域を残すように十分な大きさのINCREMENT を許可してください。

bigint 値を使用する場合、10000以上のオフセットを使用する場合でも、キーの枯渇に関する実質的な懸念はありません。枯渇に近づく可能性があるまでには、数百のマシンが毎秒数百万の挿入を実行して、数百年かかります。

PGDは、現在、このようなステップ/オフセットシーケンスでノードごとのオフセットを構成するための自動化を提供していません。

複合キー#

ステップ/オフセットシーケンスのバリアントは、PRIMARY KEY (node_number, generated_value) で構成される複合キーを使用することです。ノード番号は通常、各ノードで異なる番号を返すファンクションから取得されます。 DDLレプリケーションを一時的に無効にし、定数SQLファンクションを作成することにより、このようなファンクションを作成できます。または、レプリケーションセットの一部ではない1行テーブルを使用して、各ノードに異なる値を保存できます。

関連項目#

目次