Sequences¶
多くのアプリケーションでは、一意のサロゲート ID
をデータベースエントリに割り当てる必要があります。多くの場合、データベースの
SEQUENCE オブジェクトはこれらを生成するために使用されます。
PostgreSQL、これらはシーケンスコマンドを使用して手動で作成し、
nextval() ファンクションを呼び出すことで取得するか、 serial
およびbigserial 列、またはGENERATED BY DEFAULT AS IDENTITY
列のいずれかです。
ただし、
PostgreSQLの標準シーケンスはマルチノードを認識せず、ローカルノードで一意の値のみを生成します。このようなシーケンスによって生成された一意のIDは、マルチマスターレプリケーションで競合とデータロス（破棄されたINSERTs
による）を引き起こすため、これは重要です。
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。時間、ノードID、およびカウンタコンポーネントで構成されるBIGINTシーケンスのグローバルシーケンスを作成する
snowflakeidは、INTEGERシーケンスでは使用できません（したがって、bigserialには使用できますが、serialには使用できません）。下位互換性のためにのみ提供されているSnowflakeIdシーケンスの
timeshard古いバージョン、SnowflakeIdが推奨されますdistributedbdr.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秒あたり約400万のシーケンス値を意味します）。シーケンス値の生成が指定されたミリ秒内にラップする場合、SnowflakeIdシーケンスは次のミリ秒まで待機し、そのミリ秒の新しい値を取得します。
SnowflakeIdシーケンスはタイムスタンプをシーケンス値にエンコードため、新しいシーケンス値は指定されたタイムフレーム内にのみ生成できます（システムクロックによって異なります）。 SnowflakeIdのエポックタイムである2016-10-07を使用できる最も古いタイムスタンプ。値は2086年に負の値にラップし、2156までに数が完全になくなります。
タイムスタンプは SnowflakeId シーケンスの重要なパートであるため、postgresプロセスの有効期間内に使用された最新のタイムスタンプよりも古いタイムスタンプでシーケンスを生成しないようにする追加の保護があります。
SnowflakeIdシーケンスの入力として使用されるシーケンスのINCREMENT
オプションは効果的に無視されます。これは、多くのオブジェクトリレーショナルマッパー（ORM）ツール、特にHibernateのように、シーケンスIDキャッシングを行うアプリケーションに関連する可能性があります。シーケンスは時間ベースであるため、アプリケーションがキャッシュされた値を使用して何かを実行できるようになるまでに、シーケンスは新しい非衝突値に進むため、実際的な効果はほとんどありません。
同様に、 START 、 MINVALUE 、 MAXVALUE および CACHE
設定は、基になるシーケンスで変更できますが、そうするメリットはありません。シーケンスの下位14ビットが使用され、残りは破棄されるため、値のレンジの制限は関数の結果に影響しません。同じ理由で、
setval() はSnowflakeIdシーケンスには役立ちません。
タイムシャードシーケンス¶
タイムシャードシーケンスは、既存のインストールとの下位互換性のために提供されていますが、新しいアプリケーションでの使用はお勧めしません。代わりに SnowflakeIdシーケンスを使用することをお勧めします。
TimeshardはSnowflakeIdに非常に似ていますが、制限が異なり、保護が少なく、パフォーマンスが低下します。
timeshardとSnowflakeIdの違いは次のとおりです。
TimeshardはSnowflakeIdを超える最大16384ミリ秒（1秒あたり約1600万）を生成できますが、指定されたミリ秒内の周回に対する保護がないため、timeshardシーケンスを使用するスキーマは指定された列にtimehard値を使用するときに
UNIQUE制約の使用を保護する必要があります。 -タイムハードシーケンスのタイムスタンプコンポーネントは2050年に値を使い果たし、bigintと組み合わせて使用すると、値は2033年に負の数にラップします。これは、2033年以降に生成されたシーケンスは負の値を持つことを意味します。これはSnowflakeIdよりも大幅に短い時間間隔であり、SnowflakeIdが好ましい主な理由です。 -Timeshardシーケンスは時折ディスクメモリを必要とします（標準のローカルシーケンスと同様）。
グローバルに割り当てられたレンジシーケンス¶
グローバルに割り当てられたレンジ（またはgalloc
）シーケンスは、値の範囲（チャンク）を各ノードに割り当てます。ローカルレンジが使用されると、他のノード間のコンセンサスによって新しいレンジがグローバルに割り当てられます。これはキースペースを効率的に使用しますが、現在割り当てられているローカルレンジが使い果たされたときにシーケンスジェネレータを進行させるには、ローカルノードをクラスター内の大部分のノードに接続する必要があります。
SnowflakeIdシーケンスとは異なり、 gallocシーケンスは、
PostgreSQLが提供するすべてのシーケンスデータ型- smallint
、integer 、およびbigint
をサポートします。これは、53ビット値のみをサポートするため、javascriptで整数を使用するなど、64ビットシーケンスに問題がある環境で、またはシーケンスが限られたスペースで出力に表示される場合に使用できることを意味します。
各投票によって割り当てられるレンジは、現在、シーケンスが使用しているデータ型に基づいて事前に決定されます。
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
エラーで失敗します。次のセクションには、シーケンスのチャンクが割り当てられる方法の詳細が含まれています。
ちなみに
シーケンスの現在のデータタイプは、 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つのノードがあります。アロケーション数は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)
各ノードの特定のシーケンスに現在割り当てられている範囲を表示するには、次のクエリを使用します。
ノード
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。同じ値が複数のノードで生成されます。同じ理由で、「ギャップレス」シーケンス生成の通常の戦略はBDRでは機能しません。ほとんどの場合、アプリケーションは、 二相コミットを使用して外部ソースからのギャップレスである必要があるシーケンスの生成を調整するか、 BDRグループ内の1つのノードでのみ生成する必要があります。
UUIDとKSUUID¶
UUID
キーは、代わりにシーケンスを完全に回避し、128ビットのユニバーサル一意識別子を使用します。これらはランダムまたは擬似ランダムラージ値であり、同じ値を
2 回生成することはほとんど不可能です。 UUID
キーを使用する場合、ノードが継続的な通信を行う必要はありません。
非常にまれな衝突が発生したイベント、競合検出は、挿入された2つのレコードのうちの新しい方を選択して保持します。衝突ロギングは、有効にすると、そのようなイベントをレコードしますが、衝突は約
2^64
キーが生成された後にのみ発生するため、例外的に発生しません。
UUID
キーの主な欠点は、ややスペースとネットワークが非効率的であり、プライマリキーとしてだけでなく、外部キーで被参照される場所やネットワークで送信される場合にも多くのスペースを消費することです。さらに、すべてのアプリケーションが
UUID キーにうまく対応しているわけではありません。
BDRは、KSUUIDとして知られるUUID
データタイプのK-Sortableバリアントを操作するための関数を提供します。
KSUUID 値は、 UUID
標準に従って、タイムスタンプとランダムデータの両方を格納するという点でUUIDv1
に似ています。違いは、 KSUUID
はK-Sortable、つまりタイムスタンプで弱くソートできることです。これにより、よりコンパクトな
btree インデックスが生成され、
検索の有効性が向上し、結果データの自然な時間ソートが可能になるため、データベースキーとしてより便利になります。
UUIDv1 とは異なり、 KSUUID
の値には、それらが生成されたコンピュータのMACが含まれないため、
KSUUID sを使用してもセキュリティ上の問題はありません。
KSUUID
v2はすべての場合に推奨されます。生成された値は、通常の比較演算子で直接ソートできます。
BDRには、v1とv2の2つのバージョンがあります。レガシーのKSUUID
v1は非推奨になりましたが、既存のインストールをサポートするオーダーに保持されているため、新規インストールには使用しないでください。
v1とv2の内部コンテンツは互換性がなく、それらを操作する機能も互換性がありません。
KSUUID のv2には、 UUID バージョン番号も保存されなくなりました。
ステップとオフセットのシーケンス¶
オフセットステップシーケンスでは、各ノードで通常のPostgreSQLシーケンスが使用されます。各シーケンスは同じ量でインクリメントし、異なるオフセットで開始します。例、ステップ1000では、ノード1のシーケンスは1001、2001、3001などを生成し、ノード2は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レプリケーション を参照してください。
概要sql bdr.alter_sequence_set_kind(seqoid regclass, seqkind text)¶
パラメーター¶
seqoid- 変更されるシーケンスの名前またはOIDseqkind- 標準のPostgreSQLシーケンスの場合はlocal、グローバルに一意のBDRシーケンスの場合はsnowflakeidまたはgalloc、またはレガシーのグローバルに一意のシーケンスの場合はtimeshard
注意事項¶
シーケンスの種類をgalloc
に変更すると、そのシーケンスに最初に割り当てられたレンジはシーケンスのスタート値を開始点として使用します。
galloc
に変更される前にシーケンスで使用されている既存の値がある場合は、次のコマンドを使用して、新しく生成された値が既存の値と競合しないように開始点を移動することをお勧めします。
ALTER SEQUENCE seq_name START starting_value RESTART
このファンクションは、 DDL
ステートメントと同じレプリケーションメカニズムを使用します。これは、レプリケーションが ddl filters 構成の影響を受けることを意味します。
このファンクションは、グローバルな DDL
ロックを取得します。また、シーケンスをローカルでロックします。
このファンクションはトランザクションです。効果はトランザクションの
ROLLBACK
でロールバックでき、変更は現在のトランザクションで可視です。
bdr.alter_sequence_set_kind ファンクションは、
bdr.backwards_compatibility
が30618以下に設定されていない限り、シーケンスの所有者のみが実行できます。
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¶
このファンクションは、タイムスタンプ値をダミーのスノーフレークIDシーケンス値に変換します。
これは、 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 -スノーフレークイドシーケンス生成に使用されるタイムスタンプ¶
注意事項¶
このファンクションはローカルノードでのみ実行されます。
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 v2Functions¶
KSUUID v2データ、K-Sortable UUIDデータを操作するためのFunctions。
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 v1Functions¶
KSUUID v1データ、K-Sortable
UUIDデータ（v1）を操作するためのFunctions。
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値
注意事項¶
このファンクションはローカルノードでのみ実行されます。
