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整数型などの一部のホスト言語データ型で使用するには長すぎる場合があります。グローバルに割り当てられたシーケンスは、ノード間コンセンサスによって必要に応じて補充できるローカルな値の範囲を割り当て、BIGINTまたはINTEGERシーケンスに適しています。 :ref:`bdr.alter_sequence_set_kind() ` を使用してグローバルシーケンスを作成できます ファンクション。このファンクションは、標準のPostgreSQLシーケンスを取得し、PGDグローバルシーケンスとしてマークします。シーケンスを標準のPostgreSQLシーケンスに変換して戻すこともできます。 PGDは、構成変数 :ref:`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`` デフォルト。これは、:ref:`bdr.default_sequence_kind ` にのみ使用できる特別な値です。 ``int8`` シーケンスつまり\ ``bigserial`` の場合は\ ``snowflakeid`` を選択し、\ ``int4`` つまり\ ``serial`` および\ ``int2`` シーケンスの場合は\ ``galloc`` シーケンスを選択します。 :ref:`bdr.sequences ` ビューには、個々のシーケンス種類に関する情報が表示されます。 ``currval()`` および\ ``lastval()`` は、すべてのタイプのグローバルシーケンスで正しく動作します。 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シーケンスよりも少し高速です。 グローバルに割り当てられたレンジシーケンス ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ グローバルに割り当てられたレンジまたは\ ``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つのノードから生成される値は単調増加します。ただし、グローバルに見ると、生成された値はまったく順序付けられていません。これは、bツリーインデックスへの影響によりパフォーマンスの低下を引き起こす可能性があり、通常は、生成された値がレンジパーティションキーとして役に立たないことを意味します。 ``galloc`` シーケンスの主な欠点は、割り当てられたレンジが使い果たされると、シーケンスジェネレーターがノード間通信を必要とするローカルノードの次のレンジに関するコンセンサスを求めなければならないことです。これにより、PGDグループの大部分がアクセスできない場合、遅延または操作の問題が発生する可能性があります。 (これは、後のリリースで回避される可能性があります。) ``CACHE`` 、\ ``START`` 、\ ``MINVALUE`` 、および\ ``MAXVALUE`` オプションは、\ ``galloc`` シーケンスで正常に動作します。ただし、シーケンスを\ ``galloc`` 種類に変換する前に、それらを設定する必要があります。 ``INCREMENT BY`` オプションも正常に動作します。ただし、各シーケンスデータ型に割り当てられた上記の範囲以上の増分値を割り当てることはできません。 ``setval()`` は、\ ``galloc`` シーケンスのグローバル状態をリセットしません。使用しないでください。 ``galloc`` シーケンスには、いくつかの制限が適用されます。 PGDは、特別なPGDカタログ :ref:`bdr.sequence_alloc ` の\ ``galloc`` シーケンスを追跡します。このカタログは、\ ``galloc`` シーケンスに現在割り当てられているチャンクを追跡するために必要です。シーケンス名と名前空間はこのカタログに保存されます。シーケンスチャンクの割り当てはRaftによって管理され、シーケンス名前/名前空間の変更はレプリケーションストリームによって管理されるため、PGDは現在\ ``galloc`` シーケンスの名前の変更、別の名前空間への移動、または\ ``galloc`` シーケンスを含む名前空間の名前の変更をサポートしていません。アプリケーションスキーマをデザインするときは、この制限に注意してください。 ローカルシーケンスの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からシーケンスの現在のデータ型を取得できます :ref:`pg_sequences ` ビュー。現在の値が新しいデータ型の最大値を超えない限り、 ``ALTER SEQUENCE ... AS ...`` たとえば ``ALTER SEQUENCE public.sequence AS integer`` を使用してシーケンスのデータ型を変更できます。 2.シーケンスの新しい開始値を設定します '''''''''''''''''''''''''''''''''''''' シーケンス種類が\ ``galloc`` に変更されると、書き換えられ、ローカルシーケンスの定義された開始値からリスタートします。これが実稼働データベースの既存のシーケンスで発生した場合、現在の値を照会し、開始値を適切に設定する必要があります。このユースケースを支援するために、PGDでは、ユーザーがファンクション :ref:`bdr.alter_sequence_set_kind() ` で開始値を渡すことができます。既にオフセットを使用しており、複数のノードからの書き込みがある場合は、最大使用値を確認し、少なくとも次の値までシーケンスをリスタートする必要があります。 .. code:: sql - - determine highest sequence value across all nodes SELECT max((x->response->command_tuples->0->>nextval)::bigint) FROM json_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()`` 値が照会されている間操作を続行できるようにする必要があります。 :ref:`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) 各ノードの特定のシーケンスに現在割り当てられている範囲を表示するには、次のクエリを使用します。 - ノード\ ``Node1`` は、 ``333`` 〜\ ``2000333`` のレンジを使用しています。 .. code:: sql SELECT last_value AS range_start, log_cnt AS range_end FROM categories_category_seq WHERE ctid = (0,2); -- first range range_start | range_end - ------------+----------- 334 | 1000333 (1 row) SELECT last_value AS range_start, log_cnt AS range_end FROM categories_category_seq WHERE ctid = (0,3); -- second range range_start | range_end - ------------+----------- 1000334 | 2000333 (1 row) - ノード\ ``Node2`` は、 ``2000004`` 〜\ ``4000003`` のレンジを使用しています。 .. code:: sql SELECT last_value AS range_start, log_cnt AS range_end FROM categories_category_seq WHERE ctid = (0,2); -- first range range_start | range_end - ------------+----------- 2000334 | 3000333 (1 row) SELECT last_value AS range_start, log_cnt AS range_end FROM categories_category_seq WHERE ctid = (0,3); -- second range range_start | range_end - ------------+----------- 3000334 | 4000333 .. NOTE :: 最初の範囲のみが表示されるため、単一のクエリー`WHERE ctid IN ('(0,2)', '(0,3)')` のようなクエリーと組み合わせることはできません。 ノードはチャンクを終了すると、新しいチャンクのコンセンサスを求め、最初に利用可能なものを取得します。この例では、4000334〜5000333です。これは新しい予約チャンクであり、古い予約チャンクの消費を開始します。 UUID、KSUUID、およびその他のアプローチ -------------------------------------- PGDで使用できるグローバルシーケンスを使用せずに、他の方法でグローバルに一意のIDを生成できます。例 - UUIDとそのPGDバリアントKSUUID - ノードごとに異なるオフセットを持つローカルシーケンスつまり手動 - 外部調整されたナチュラルキー PGDアプリケーションは他の方法を安全に使用できません。 PGDはノード間で行ロックを取得しないため、シーケンス生成で\ ``SELECT ... FOR UPDATE`` 、\ ``UPDATE ... RETURNING ...`` または同様のものに依存するカウンタテーブルベースのアプローチは、PGDでは正しく機能しません。同じ値が複数のノードで生成されます。同じ理由で、「ギャップレス」シーケンス生成の通常の戦略はPGDでは機能しません。ほとんどの場合、アプリケーションは、2フェーズコミットを使用して外部ソースからギャップレスである必要があるシーケンスの生成を調整します。または、PGDグループ内の1つのノードでのみ生成されます。 UUID ^^^^ ``UUID`` キーは、代わりにシーケンスを完全に回避し、128ビットのユニバーサル一意識別子を使用します。これらはランダムまたは擬似乱数値であり、非常に大きいため、同じ値を2回生成することはほぼ不可能です。 ``UUID`` キーを使用する場合、ノードが継続的に通信する必要はありません。 万が一、衝突が発生した場合、競合検出は、挿入された2つのレコードの新しい方を選択して保持します。競合ログが有効になっている場合、このようなイベントが記録されます。ただし、約2^64キーが生成された後にのみ衝突が実際に可能になるため、発生する可能性は非常に低いです。 ``UUID`` キーの主な欠点は、領域とネットワークの点でやや非効率であることです。これらは、主キーとしてだけでなく、外部キーで参照される場合、および回線上で送信される場合にも、より多くの領域を消費します。また、すべてのアプリケーションが\ ``UUID`` キーにうまく対応できるわけではありません。 KSUUID ^^^^^^ PGDは、KSUUIDとして知られる\ ``UUID`` データのK-Sortableバリアントを操作するためのファンクションを提供し、PostgreSQL標準の\ ``UUID`` データ型を使用して保存できる値を生成します。 ``KSUUID`` 値は、 ``UUID`` 標準に従って、タイムスタンプとランダムデータの両方を保存するという点で\ ``UUIDv1`` に似ています。違いは、 ``KSUUID`` がK-Sortableであること、つまりタイムスタンプで弱くソート可能であることです。これにより、よりコンパクトな\ ``btree`` インデックスを生成するため、データベースキーとしてより役立ちます。これにより、検索の効率が向上し、結果データの自然な時間ソートが可能になります。 ``UUIDv1`` とは異なり、\ ``KSUUID`` 値には、生成されたコンピューターのMACが含まれないため、それらの使用にセキュリティ上の懸念はありません。 あらゆる場合に\ ``KSUUID`` v2を推奨するようになりました。通常の比較演算子で生成された値を直接並べ替えることができます。 PGDには\ ``KSUUID`` の2つのバージョンv1およびv2があります。古い\ ``KSUUID`` v1は非推奨ですが、既存のインストールをサポートするために維持されます。新しいインストールには使用しないでください。 v1とv2の内部コンテンツには互換性がありません。そのため、それらを操作する機能も互換性がありません。 ``KSUUID`` のv2も、\ ``UUID`` バージョン番号を保存しなくなりました。 PGDリファレンスの :ref:`KSUUID v2ファンクション ` および :ref:`KSUUID v1ファンクション ` を参照してください。 ステップシーケンスとオフセットシーケンス ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ オフセットステップシーケンスでは、各ノードで通常の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行テーブルを使用して、各ノードに異なる値を保存できます。 関連項目 -------- - :ref:`Global sequence management interfaces ` - :ref:`KSUUID v2ファンクション ` - :ref:`KSUUID v1ファンクション `