Sequences¶
多くのアプリケーションでは、一意のサロゲート ID をデータベース
エントリに割り当てる必要があります。多くの場合、データベースの
SEQUENCE オブジェクトはこれらを生成するために使用されます。
PostgreSQLでは、これらは次のいずれかです。
CREATE SEQUENCEコマンドを使用して手動で作成され、nextval()関数を呼び出して取得したシーケンスserialおよびbigserial列、またはGENERATED BY DEFAULT AS IDENTITY列
ただし、PostgreSQLの標準シーケンスはマルチノードを認識せず、ローカルノードでのみ一意の値を生成します。このようなシーケンスによって生成された一意のIDは、マルチマスターレプリケーションで競合とデータ損失（破棄されたINSERT
アクション）を引き起こすため、これは重要です。
BDRグローバルシーケンス¶
このため、 BDRは、グローバルシーケンスと呼ばれるBDRグループ全体のbigintまたはbigserialデータ型のシーケンスを使用して一意のIDを生成するアプリケーション透過的な方法を提供します。
BDRグローバルシーケンスは、アプリケーションがデータベースを使用して、ほとんどの場合に機能するが必ずしもすべてではない非同期分散システムで一意の合成キーを生成する簡単な方法を提供します。
BDRグローバルシーケンスを使用すると、挿入の競合の問題を回避できます。グローバルシーケンスを使用している列にPRIMARY KEY
またはUNIQUE
制約を定義すると、ノードは他のノードと同じ値を取得できません。
BDRがノード間で挿入を同期する場合、競合することはありません。
BDRグローバルシーケンスはPostgreSQLシーケンスを拡張するため、クラッシュセーフです。これらを使用するには、
bdr_application ロールが付与されている必要があります。
グローバルシーケンスにはさまざまなアルゴリズムがあります。
SnowflakeIdシーケンス
グローバルに割り当てられた範囲シーケンス
SnowflakeIdシーケンスは、任意の時点でノード間通信を必要としないアルゴリズムを使用して値を生成します。より高速で堅牢で、値が作成されたタイムスタンプを記録するという便利なプロパティがあります。
SnowflakeIdシーケンスには、64ビットのBIGINTデータ型でのみ機能し、19桁の長さの値を生成するという制限があります。これは、Javascript Integer型などの一部のホスト言語データ型で使用するには長すぎる場合があります。グローバルに割り当てられたシーケンスは、ノード間のコンセンサスによって必要に応じて補充できる値のローカル範囲を割り当て、BIGINTまたはINTEGERシーケンスに適したものにします。
bdr.alter_sequence_set_kind()
ファンクションを使用して、グローバルシーケンスを作成できます。このファンクションは、標準のPostgreSQLシーケンスを取り、それをBDRグローバルシーケンスとしてマークします。シーケンスを標準のPostgreSQLシーケンスに変換することもできます。
BDRは、 CREATE SEQUENCE
コマンドが実行されたときに、またはserial 、bigserial
、またはGENERATED BY DEFAULT AS IDENTITY
列が作成されたときに作成するシーケンスの種類を決定する構成変数bdr.default_sequence_kind
も提供します。有効な設定は次のとおりです。
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()
は、すべてのタイプのグローバルシーケンスで正しく機能します。
SnowflakeIdシーケンス¶
SnowflakeIdシーケンスによって生成されたIDは大まかな時間順序付けであるため、標準のPostgreSQLシーケンスのように、それらを使用してデータ挿入のおおよその順序を取得できます。 1つのノードでも、同じミリ秒内に生成された値は順不同である場合があります。緩い時間順序のプロパティは、レンジパーティションキーとしての使用に適していることを意味します。
SnowflakeIdシーケンスは1つ以上のノードで動作し、ノード参加プロセスが完了した後のノード間通信は必要ありません。そのため、ネットワークパーティションが拡張されるリスクがある場合でも、引き続き使用できます。レプリケーションのラグやノード間のレイテンシーの影響を受けません。
SnowflakeIdシーケンスは、標準のシーケンスとは異なる方法で一意のIDを生成します。このアルゴリズムでは、シーケンス番号に 3 つのコンポーネントを使用します。シーケンスの最初のコンポーネントは、シーケンス番号生成時のタイムスタンプです。シーケンス番号の2番目のコンポーネントは、各BDRノードに割り当てられた一意のIDです。これにより、異なるノードのIDは常に異なります。 3番目のコンポーネントは、ローカルシーケンスによって生成された番号です。
シーケンス番号に一意のノードIDを追加するだけで競合が発生しませんが、シーケンスの別の有用なプロパティも保持します。シーケンス番号の順序は、テーブルにデータが挿入された順序にほぼ対応しています。タイムスタンプを最初に置くと、これが保証されます。
SnowflakeIdシーケンスには、いくつかの制限と警告が適用されます。
SnowflakeIdシーケンスは64ビット幅で、 bigint またはbigserial
が必要です。生成される値は少なくとも 19
桁です。実用的な32ビットinteger バージョンはないため、 serial
シーケンスでは使用できません。代わりに、グローバルに割り当てられた範囲シーケンスを使用します。
SnowflakeIdの場合、特定のノードで1ミリ秒に生成されるシーケンス値の制限は4096です（1秒あたり約400万のシーケンス値）。シーケンス値の生成が指定されたミリ秒以内にラップする場合、SnowflakeIdシーケンスは次のミリ秒まで待機し、そのミリ秒の新しい値を取得します。
SnowflakeIdシーケンスはタイムスタンプをシーケンス値にエンコードするため、指定されたタイムフレーム内でのみ新しいシーケンス値を生成できます（システムクロックによって異なります）。使用できる最も古いタイムスタンプは2016-10-07で、これはSnowflakeIdのエポック時間です。値は2086年に負の値にラップし、2156までに数が完全になくなります。
タイムスタンプはSnowflakeIdシーケンスの重要な部分であるため、postgresプロセスの有効期間中に使用された最新のものよりも古いタイムスタンプを持つシーケンスを生成しないようにする追加の保護があります。
SnowflakeIdシーケンスの入力として使用されるシーケンスのINCREMENT
オプションは効果的に無視されます。これは、多くのオブジェクトリレーショナルマッパー（ORM）ツール、特にHibernateのように、シーケンスIDキャッシングを行うアプリケーションに関連する場合があります。シーケンスは時間ベースであるため、アプリケーションがキャッシュされた値を使用して何かを実行できるようになるまでに、シーケンスは新しい非衝突値に進むため、実際的な効果はほとんどありません。
同様に、基になるシーケンスのSTART 、MINVALUE
、MAXVALUE 、およびCACHE
設定を変更することもできますが、変更してもメリットはありません。シーケンスの下位14ビットが使用され、残りは破棄されるため、値の範囲の制限は関数の結果に影響しません。同じ理由で、
setval() はSnowflakeIdシーケンスには役立ちません。
タイムシャードシーケンス¶
Timeshardシーケンスは、既存のインストールとの下位互換性のために提供されていますが、新しいアプリケーションでの使用は推奨されません。代わりに SnowflakeId シーケンスを使用することをお勧めします。
TimeshardはSnowflakeIdに非常に似ていますが、制限が異なり、保護が少なく、パフォーマンスが低下します。
timeshardとSnowflakeIdの違いは次のとおりです。
Timeshardは、SnowflakeIdよりも多い、ミリ秒あたり最大16384個（1秒あたり約1600万個）を生成できます。ただし、指定されたミリ秒内のラップアラウンドに対する保護はありません。タイムハードシーケンスを使用するスキーマは、特定の列にタイムハード値を使用するときに
UNIQUE制約の使用を保護する必要があります。 -timeshardシーケンスのタイムスタンプコンポーネントは2050年に値を使い果たし、bigintと組み合わせて使用すると、値は2033年に負の数にラップします。これは、2033年以降に生成されたシーケンスが負の値を持つことを意味します。これはSnowflakeIdよりも大幅に短い時間であり、SnowflakeIdが好ましい主な理由です。 - タイムシャードシーケンスでは、定期的なディスク書き込みが必要です（標準のローカルシーケンスと同様）。 SnowflakeIdはメモリで計算されるため、SnowflakeIdシーケンスは一般的にtimehardシーケンスよりも少し高速です。
グローバルに割り当てられた範囲シーケンス¶
グローバルに割り当てられた範囲（または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
シーケンスの主な欠点は、割り当てられた範囲を使い果たすと、シーケンスジェネレーターがノード間通信を必要とするローカルノードの次の範囲についてコンセンサスを求める必要があることです。
BDRグループの大部分にアクセスできない場合、これにより遅延や操作上の問題が発生する可能性があります。これは、後のリリースでは回避される可能性があります。
CACHE 、START 、MINVALUE 、およびMAXVALUE
オプションは、 galloc
シーケンスで正しく機能します。ただし、シーケンスをgalloc
種類に変換する前に設定する必要があります。 INCREMENT BY
オプションも正しく動作します。ただし、シーケンスデータ型ごとに割り当てられた上記の範囲以上のインクリメント値を割り当てることはできません。
setval() はgalloc
シーケンスのグローバル状態をリセットしません。使用しないでください。
galloc シーケンスにはいくつかの制限が適用されます。
BDRは、特別なBDRカタログ :ref:bdr.sequence_alloc`<`bdr.sequence_alloc`>` で ``galloc
シーケンスを追跡します。このカタログは、 galloc
シーケンスに現在割り当てられているチャンクを追跡するために必要です。シーケンス名と名前空間はこのカタログに保存されます。シーケンスチャンクの割り当てはRaftによって管理されるのに対し、シーケンス名前/名前空間の変更はレプリケーションストリームによって管理されるため、
BDRは現在、 galloc
シーケンスの名前変更、別の名前空間への移動、またはgalloc
シーケンスを含む名前空間の名前変更をサポートしていません。アプリケーションスキーマを設計するときは、この制限に注意してください。
ローカルシーケンスからgallocシーケンスへの変換¶
ローカルシーケンスをgallocに変換する前に、いくつかの前提条件を満たす必要があります。
1.シーケンスと列のデータ型が一致することを確認します¶
シーケンスのデータ型が使用する列のデータ型と一致することを確認します。たとえば、
bigint
シーケンスを作成し、そのシーケンスによって返されるnextval()
にinteger 列のデフォルトを割り当てることができます。 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
に変更すると書き換えられ、ローカルシーケンスの定義された開始値からリスタートします。これが実稼働データベース内の既存のシーケンスで発生した場合、現在の値を照会してから、開始値を適切に設定する必要があります。このユースケースを支援するために、
BDRではユーザーが関数bdr.alter_sequence_set_kind()
で開始値を渡すことができます。既にオフセットを使用していて、複数のノードからの書き込みがある場合は、使用された最大の値を確認し、少なくとも次の値までシーケンスをリスタートする必要があります。
- - determine highest sequence value across all nodes
SELECT max((x->response->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);
ユーザーはシーケンスをロックできないため、 max()
値が照会されている間も操作を続行できるように、 $MARGIN
値を残す必要があります。
bdr.sequence_alloc
テーブルは、チャンクサイズとクラスター全体に割り当てられた範囲に関する情報を提供します。この例では、333
からシーケンスを開始し、クラスター内に2つのノードがあります。ノードごとに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)
各ノードの特定のシーケンスに現在割り当てられている範囲を表示するには、次のクエリを使用します。
ノード
Node1は333から2000333の範囲を使用しています。
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の範囲を使用しています。
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
注釈
まだ最初の範囲のみが表示されるため、単一のクエリ（ WHERE ctid IN ('(0,2)', '(0,3)') など）に結合できません。
ノードはチャンクを終了すると、新しいチャンクのコンセンサスを求め、最初に利用可能なチャンクを取得します。この例では、4000334から5000333です。これは新しい予約済みチャンクであり、古い予約済みチャンクの消費を開始します。
UUID、KSUUID、およびその他のアプローチ¶
BDRで使用できるグローバルシーケンスを使用せずにグローバルに一意のIDを生成する方法は他にもあります。例：
UUIDとそのBDRバリアント、KSUUID
ノードごとに異なるオフセットを持つローカルシーケンス（つまり、手動）
外部調整されたナチュラルキー
BDRアプリケーションは他の方法を安全に使用できませんBDRはノード間の行ロックをとらないため、シーケンス生成にSELECT ... FOR UPDATE
、UPDATE ... RETURNING ...
などに依存するカウンターテーブルベースのアプローチはBDRで正しく機能しません。複数のノードで同じ値が生成されます。同じ理由で、「ギャップレス」シーケンス生成の通常の戦略はBDRでは機能しません。ほとんどの場合、アプリケーションは、2フェーズコミットを使用して、外部ソースからのギャップレスである必要があるシーケンスの生成を調整します。または、
BDRグループ内の1つのノードでのみ生成します。
UUIDとKSUUID¶
UUID
キーは代わりにシーケンスを完全に回避し、128ビットのユニバーサル一意識別子を使用します。これらはランダムまたは擬似ランダムな値であり、同じ値を
2 回生成することはほとんど不可能です。 UUID
キーを使用する場合、ノードが継続的な通信を行う必要はありません。
万が一、衝突が発生した場合、競合検出は、挿入された2つのレコードのうちの新しい方を選択して保持します。競合ログが有効になっている場合、そのようなイベントが記録されます。ただし、衝突は約
2^64
キーが生成された後にのみ発生する可能性があるため、例外的に発生する可能性はありません。
UUID
キーの主な欠点は、スペースとネットワークの面でやや非効率なことです。主キーとしてだけでなく、外部キーで参照される場所やネットワークで送信される場合にも、より多くの領域を消費します。また、すべてのアプリケーションが
UUID キーに対応しているわけではありません。
BDRは、KSUUIDと呼ばれるUUID
データのK-Sortableバリアントを操作するための関数を提供します。これは、PostgreSQL標準のUUID
データ型を使用して保存できる値を生成します。 KSUUID 値は、 UUID
標準に従って、タイムスタンプとランダムデータの両方を格納するという点でUUIDv1
に似ています。違いは、 KSUUID
はK-Sortable、つまりタイムスタンプで弱くソートできることです。これにより、よりコンパクトなbtree
インデックスが生成され、検索の有効性が向上し、結果データの自然な時間ソートが可能になるため、データベースキーとしてより便利になります。
UUIDv1 とは異なり、 KSUUID
の値には、それらが生成されたコンピューターのMACが含まれないため、使用してもセキュリティ上の懸念はありません。
KSUUID
v2はすべての場合に推奨されます。通常の比較演算子で生成された値を直接ソートできます。
BDRにはKSUUID の2つのバージョンがあります：v1とv2。古い KSUUID
v1
は非推奨ですが、既存のインストールをサポートするために保持されています。新規インストールには使用しないでください。
v1とv2の内部コンテンツには互換性がありません。そのため、それらを操作する機能も互換性がありません。
KSUUID のv2には、 UUID バージョン番号も保存されなくなりました。
ステップとオフセットのシーケンス¶
オフセットステップシーケンスでは、各ノードで通常のPostgreSQLシーケンスが使用されます。各シーケンスは同じ量でインクリメントし、異なるオフセットで開始します。たとえば、ステップ1000では、node1のシーケンスは1001、2001、3001などを生成します。 node2のシーケンスは1002、2002、3002などを生成します。このスキームは、ノードが長期間通信できない場合でもうまく機能します。ただし、設計者はスキーマを確立するときにノードの最大数を指定する必要があり、ノードごとの構成が必要です。間違いは、シーケンスの重複につながりやすいです。
次のように、1つのノードで目的のシーケンスを作成することにより、 BDRでこのアプローチを構成するのは比較的簡単です。
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以上のオフセットを使用してもキーが枯渇する心配はありません。何百もの機械が毎秒何百万もの挿入を行うと、枯渇に近づく可能性があります。
BDRは現在、そのようなステップ/オフセットシーケンスでのノードごとのオフセットの構成の自動化を提供していません。
複合キー¶
ステップ/オフセットシーケンスのバリアントは、
PRIMARY KEY (node_number, generated_value)
で構成される複合キーを使用することです。ノード番号は通常、各ノードで異なる番号を返す関数から取得されます。
DDLレプリケーションを一時的に無効にし、定数SQLファンクションを作成することにより、このようなファンクションを作成できます。または、レプリケーションセットの一部ではない1行のテーブルを使用して、各ノードに異なる値を保存できます。
グローバルシーケンス管理インターフェース¶
BDRは、標準のPostgreSQLシーケンスとBDRグローバルシーケンスの間で変換するためのインターフェイスを提供します。
以下の関数はDDL とみなされるため、
DDLレプリケーションとグローバルロックが適用されます。
bdr.alter_sequence_set_kind¶
シーケンスの所有者がシーケンスの種類を設定できるようにします。設定すると、
seqkind はbdr.sequences
ビューを介してのみ表示されます。他のすべての方法では、シーケンスは通常のシーケンスとして表示されます。
BDRはこのファンクションをDDL
として扱うため、現在アクティブな場合はDDLレプリケーションとグローバルロックが適用されます。
DMLおよびDDLレプリケーション を参照してください。
概要¶
bdr.alter_sequence_set_kind(seqoid regclass, seqkind text)
パラメーター¶
seqoid—変更するシーケンスの名前またはOid。seqkind—標準のPostgreSQLシーケンスの場合はlocal、グローバルに一意のBDRシーケンスの場合はsnowflakeidまたはgalloc、またはレガシーのグローバルに一意のシーケンスの場合はtimeshard。
注意事項¶
シーケンスの種類をgalloc
に変更すると、そのシーケンスに最初に割り当てられた範囲はシーケンスの開始値を開始点として使用します。
galloc
に変更される前にシーケンスで使用された既存の値がある場合は、次のコマンドを使用して、新しく生成された値が既存の値と競合しないように、開始点を移動することをお勧めします。
ALTER SEQUENCE seq_name START starting_value RESTART
このファンクションは、 DDL
ステートメントと同じ複製メカニズムを使用します。これは、レプリケーションが ddl filters 構成の影響を受けることを意味します。
この関数は、グローバルな DDL
ロックを取得します。また、シーケンスをローカルにロックします。
このファンクションはトランザクションです。トランザクションのROLLBACK
で効果をロールバックできます。変更は現在のトランザクションに表示されます。
bdr.backwards_compatibility
が30618以下に設定されていない限り、シーケンスの所有者のみがbdr.alter_sequence_set_kind
ファンクションを実行できます。
bdr.extract_timestamp_from_snowflakeid¶
このファンクションは、 snowflakeid
シーケンスのタイムスタンプコンポーネントを抽出します。戻り値はtimestamptz型です。
概要sql bdr.extract_timestamp_from_snowflakeid(snowflakeid bigint)¶
パラメーター¶
snowflakeid—スノーフレークイド シーケンスの値。
注意事項¶
この関数はローカルノードでのみ実行されます。
bdr.extract_nodeid_from_snowflakeid¶
このファンクションは、 snowflakeid
シーケンスのnodeidコンポーネントを抽出します。
概要sql bdr.extract_nodeid_from_snowflakeid(snowflakeid bigint)¶
パラメーター¶
snowflakeid—スノーフレークイド シーケンスの値。
注意事項¶
この関数はローカルノードでのみ実行されます。
bdr.extract_localseqid_from_snowflakeid¶
この関数は、 snowflakeid
シーケンスのローカルシーケンス値コンポーネントを抽出します。
概要sql bdr.extract_localseqid_from_snowflakeid(snowflakeid bigint)¶
パラメーター¶
snowflakeid—スノーフレークイド シーケンスの値。
注意事項¶
この関数はローカルノードでのみ実行されます。
bdr.timestamp_to_snowflakeid¶
このファンクションは、タイムスタンプ値をダミーのsnowflakeidシーケンス値に変換します。
これは、 snowflakeid 列の値および特定のタイムスタンプのインデックス付き検索または比較を行う場合に役立ちます。
たとえば、 snowflakeid シーケンスを使用している列id
を持つテーブルfoo
がある場合、次のように昨日の午前0時からの変更数を取得できます。
SELECT count(1) FROM foo WHERE id > bdr.timestamp_to_snowflakeid(yesterday)
このように定式化されたクエリは、列 id
でインデックススキャンを使用します。
概要sql bdr.timestamp_to_snowflakeid(ts timestamptz)¶
パラメーター¶
ts— Snowflakeidシーケンス生成に使用するタイムスタンプ。
注意事項¶
この関数はローカルノードでのみ実行されます。
bdr.extract_timestamp_from_timeshard¶
このファンクションは、 timeshard
シーケンスのタイムスタンプコンポーネントを抽出します。戻り値はtimestamptz型です。
概要¶
bdr.extract_timestamp_from_timeshard(timeshard_seq bigint)
パラメーター¶
timeshard_seq—タイムハードシーケンスの値。
注意事項¶
この関数はローカルノードでのみ実行されます。
bdr.extract_nodeid_from_timeshard¶
このファンクションは、 timeshard
シーケンスのnodeidコンポーネントを抽出します。
概要¶
bdr.extract_nodeid_from_timeshard(timeshard_seq bigint)
パラメーター¶
timeshard_seq—タイムハードシーケンスの値。
注意事項¶
この関数はローカルノードでのみ実行されます。
bdr.extract_localseqid_from_timeshard¶
この関数は、 timeshard
シーケンスのローカルシーケンス値コンポーネントを抽出します。
概要¶
bdr.extract_localseqid_from_timeshard(timeshard_seq bigint)
パラメーター¶
timeshard_seq—タイムハードシーケンスの値。
注意事項¶
この関数はローカルノードでのみ実行されます。
bdr.timestamp_to_timeshard¶
このファンクションは、タイムスタンプ値をダミーのタイムシャードシーケンス値に変換します。
これは、timeshard列の値と特定のタイムスタンプのインデックス付き検索または比較を行う場合に役立ちます。
たとえば、 timeshard シーケンスを使用している列id
を持つテーブルfoo
がある場合、次のように昨日の午前0時からの変更数を取得できます。
SELECT count(1) FROM foo WHERE id > bdr.timestamp_to_timeshard(yesterday)
このように定式化されたクエリは、列 id
でインデックススキャンを使用します。
概要¶
bdr.timestamp_to_timeshard(ts timestamptz)
パラメーター¶
ts—タイムハードシーケンス生成に使用するタイムスタンプ。
注意事項¶
この関数はローカルノードでのみ実行されます。
KSUUID v2関数¶
KSUUID v2データ、K-Sortable UUIDデータを操作するための関数。
bdr.gen_ksuuid_v2¶
このファンクションは、引数として渡されたタイムスタンプの値、またはNULLが渡された場合は現在のシステム時刻を使用して、新しいKSUUID
v2値を生成します。システム時刻を使用してKSUUIDを自動的に生成する場合は、
NULL 引数を渡します。
戻り値はUUID型です。
概要¶
bdr.gen_ksuuid_v2(timestamptz)
注意事項¶
この関数はローカルノードでのみ実行されます。
bdr.ksuuid_v2_cmp¶
この関数は、 KSUUID v2の値を比較します。
最初の値の方が新しい場合は1、2番目の値の方が小さい場合は-1、等しい場合は0を返します。
概要¶
bdr.ksuuid_v2_cmp(uuid, uuid)
パラメーター¶
UUID—比較するKSUUIDv2。
注意事項¶
この関数はローカルノードでのみ実行されます。
bdr.extract_timestamp_from_ksuuid_v2¶
この関数は、 KSUUID
v2のタイムスタンプコンポーネントを抽出します。戻り値はtimestamptz型です。
概要¶
bdr.extract_timestamp_from_ksuuid_v2(uuid)
パラメーター¶
UUID—タイムスタンプを抽出するKSUUIDv2値。
注意事項¶
この関数はローカルノードでのみ実行されます。
KSUUID v1の機能¶
KSUUID v1データ、K-Sortable UUIDデータ（v1）を操作するための関数。
bdr.gen_ksuuid¶
この関数は、現在のシステム時刻を使用して、新しいKSUUID
v1値を生成します。戻り値はUUID型です。
概要¶
bdr.gen_ksuuid()
注意事項¶
この関数はローカルノードでのみ実行されます。
bdr.uuid_v1_cmp¶
この関数は、 KSUUID v1の値を比較します。
最初の値の方が新しい場合は1、2番目の値の方が小さい場合は-1、等しい場合は0を返します。
概要¶
bdr.uuid_v1_cmp(uuid, uuid)
注意事項¶
この関数はローカルノードでのみ実行されます。
パラメーター¶
UUID—比較するKSUUIDv1。
bdr.extract_timestamp_from_ksuuid¶
この関数は、 KSUUID v1またはUUIDv1
値のタイムスタンプコンポーネントを抽出します。戻り値はtimestamptz型です。
概要¶
bdr.extract_timestamp_from_ksuuid(uuid)
パラメーター¶
UUID—タイムスタンプを抽出するKSUUIDv1値。
注意事項¶
この関数はローカルノードで実行されます。
