Sequences ========= 多くのアプリケーションでは、一意のサロゲートIDをデータベースエントリに割り当てる必要があります。多くの場合、データベース ``SEQUENCE`` オブジェクトはこれらを生成するために使用されます。 PostgreSQLでは、これらは次のいずれかです。 - ``CREATE SEQUENCE`` コマンドを使用して手動で作成し、\ ``nextval()`` ファンクションを呼び出して取得したシーケンス - ``serial`` および\ ``bigserial`` 列または\ ``GENERATED BY DEFAULT AS IDENTITY`` 列 ただし、 PostgreSQLの標準シーケンスはマルチノード対応ではなく、ローカルノードでのみ一意の値を生成します。このようなシーケンスによって生成された一意のIDは、マルチマスターレプリケーションで破棄された\ ``INSERT`` アクションによる競合とデータ損失を発生させるため、これは重要です。 .. Note Permissions required:: これは、シーケンスを使用するユーザーが少なくとも :ref:`bdr_application ` を持っている必要があることを意味します 彼らに割り当てられたロール。 .. :: ## PGDグローバルシーケンス このため、 PGDは、 \_global sequences_と呼ばれる、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()`` ファンクションを実行します。ただし、シーケンスの開始値を手動で設定して、テーブル内の既存の値と競合しないようにする必要があることに注意してください。これ全般、特に :ref:`How to set a new start value for a sequence ` の詳細については、 :ref:`ローカルシーケンスのgallocシーケンスへの変換 <ローカルシーケンスのgallocシーケンスへの変換>` を参照してください。 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の数字 - integer — 1 000 000の数字 - bigint — 1 000 000 000数値 各ノードはseq_chunk_sizeの2つのチャンク—現在使用するものと将来の使用のために予約されたチャンク—を割り当てるため、1つのノードから生成される値は単調増加します。ただし、グローバルに見ると、生成された値はまったく順序付けられていません。これは、bツリーインデックスへの影響によりパフォーマンスの低下を引き起こす可能性があり、通常は、生成された値がレンジパーティションキーとして役に立たないことを意味します。 ``galloc`` シーケンスの主な欠点は、割り当てられたレンジが使い果たされると、シーケンスジェネレーターがノード間通信を必要とするローカルノードの次のレンジに関するコンセンサスを求めなければならないことです。これにより、PGDグループの大部分がアクセスできない場合、遅延または操作の問題が発生する可能性があります。 (これは、後のリリースで回避される可能性があります。) ``CACHE`` 、\ ``START`` 、\ ``MINVALUE`` 、および\ ``MAXVALUE`` オプションは、\ ``galloc`` シーケンスで正常に動作します。ただし、シーケンスを\ ``galloc`` 種類に変換する前に、それらを設定する必要があります。 ``INCREMENT BY`` オプションも正常に動作します。ただし、各シーケンスデータ型に割り当てられた上記の範囲以上の増分値を割り当てることはできません。 ``setval()`` は、\ ``galloc`` シーケンスのグローバル状態をリセットしません。使用しないでください。 PGDは、 ``bdr.sequence_alloc`` カタログの\ ``galloc`` シーケンスを追跡して、現在割り当てられているチャンクを管理します。 Raftはチャンクの割り当てを管理しますが、シーケンスの名前または名前空間の変更は、伝統的にレプリケーションストリームを介して処理されます。 PGD 6.3.0以降、\ ``ALTER SEQUENCE ... RENAME`` および\ ``ALTER SEQUENCE ... SET SCHEMA`` は、すべてのシーケンスタイプで完全にサポートされています。 ``galloc`` シーケンスの場合、このサポートは\ ``bdr.sequence_kind catalog`` のグローバルUUID識別子\ ``sequuid`` に依存しています。これにより、PGDは名前または名前空間の変更にわたって一貫してシーケンスを追跡できます。 これらのオブジェクトの管理の詳細については、 :ref:`ALTER SEQUENCE ` を参照してください。 ローカルシーケンスのgallocシーケンスへの変換 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ローカルシーケンスをgallocに変換する前に、いくつかの前提条件に注意する必要があります。 1.シーケンスと列のデータ型が一致することを確認します '''''''''''''''''''''''''''''''''''''''''''''''''''' シーケンスのデータ型が、使用される列のデータ型と一致することを確認します。たとえば、 ``bigint`` シーケンスを作成し、 ``integer`` 列のデフォルトをそのシーケンスによって返される\ ``nextval()`` に割り当てることができます。 ``bigint`` の場合1 000 000 000のブロックで割り当てられるgallocシーケンスでは、3つ以上のノードが使用されている場合、\ ``nextval()`` によって返される値がすぐに\ ``int4`` 範囲を超えます。 この例は、何が起こり得るかを示しています。 .. code:: sql 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)`` を実行した後、テーブルには次の値が含まれます。 .. code:: sql 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() `_ で開始値を渡すことができます。すでにオフセットを使用しており、複数のノードからの書き込みがある場合は、最大使用値を確認し、少なくとも次の値までシーケンスをリスタートする必要があります。 .. code:: sql - - 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で、整数シーケンスに関連しています。 .. code:: sql 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`` のレンジを使用しています。 .. code:: sql SELECT * FROM bdr.galloc_chunk_info(categories_category_seq); chunk_start | chunk_end - ------------+----------- 334 | 1000333 1000334 | 2000333 (2 rows) - ノード\ ``Node2`` は、 ``2000334`` 〜\ ``4000333`` のレンジを使用しています。 .. code:: sql 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行テーブルを使用して、各ノードに異なる値を保存できます。 関連項目 -------- - `Global Sequence management interfaces `_ - `KSUUID v2 functions `_ - `KSUUID v1 functions `_