ユニバーサルユニーク識別子

ユニバーサルユニーク識別子（UUID）は、コンピュータシステム内のオブジェクトを一意に識別するために使用される128ビットの ラベルです。グローバルユニーク識別子（GUID ）という用語も、主にMicrosoftシステムで使用されます。^{[1] [2]}

標準的な方法に従って生成されたUUIDは、実用上は一意です。他のほとんどの番号体系とは異なり、UUIDの一意性は、中央登録機関や生成者間の調整に依存しません。UUIDが重複する確率はゼロではありませんが、一般的にはゼロに十分近いため無視できると考えられています。^{[3] [4]}

したがって、誰でも UUID を作成し、それを使用して何かを識別できます。その識別子は、すでに何かを識別するために作成された、または今後作成される識別子と重複しないというほぼ確実な証拠が得られます。したがって、独立した当事者によって UUID でラベル付けされた情報は、後で単一のデータベースに統合したり、同じチャネルで送信したりすることができ、重複する可能性はごくわずかです。

UUID は広く採用されており、多くのコンピューティング プラットフォームが UUID の生成とテキスト表現の解析をサポートしています。

1980年代、アポロコンピュータはネットワークコンピューティングシステム（NCS）でUUIDを最初に使用しました。その後、オープンソフトウェア財団（OSF）は分散コンピューティング環境（DCE）でUUIDを使用しました。DCE UUIDの設計は部分的にNCS UUIDに基づいています。 ^[5] NCS UUIDの設計は、アポロコンピュータが設計したオペレーティングシステムであるDomain/OSで定義され、広く使用されている（64ビット）一意の識別子に触発されました。^[6]その後、^{[いつ？ ]} Microsoft WindowsプラットフォームはDCE設計を「グローバル一意識別子」（GUID）として採用しました。

RFC  4122はUUIDのURN名前空間を登録し、同じ技術的内容で以前の仕様を要約しました。^{[2] 2005年7月に}RFC 4122がIETF標準 案として公開されたとき、ITUも以前の標準とRFC  4122の初期バージョンに基づいてUUIDを標準化していました。2024年5月7日にはRFC  9562が公開され、3つの新しい「バージョン」が導入され、いくつかの曖昧さが明確になりました。

UUIDは、分散コンピューティング環境（DCE）の一部としてOpen Software Foundation（OSF）によって標準化されています。^{[7] [8]}

UUIDはISO / IEC 11578:1996「情報技術- 開放型システム間相互接続 -リモートプロシージャコール（RPC）」の一部として文書化されており、最近ではITU-T勧告X.667 | ISO / IEC 9834-8:2014にも記載されています。^[9]

インターネット技術特別調査委員会（IETF）は、RFC  4122 ^[2 ]の改訂版として、「Revise Universally Unique Identifier Definitions Working Group」^{[10]から標準化過程の}RFC  9562 ^{[1]を公開しました。RFC 4122}は 技術的には ITU-T Rec. X.667 | ISO/IEC 9834-8 と同等ですが、現在は廃止されています。

UUID は 128 ビットのサイズで、そのうち 2 ～ 4 ビットはフォーマットのバリアントを示すために使用されます。現在使用されている最も一般的なバリアントである OSF DCE では、バージョン用にさらに 4 ビットが定義されています。

残りのビットの使用は、選択されたバリアント/バージョンによって決まります。

バリアントフィールドは、 UUID の形式を示します (レガシー UUID の場合は、ノード フィールドに使用されるアドレス ファミリも示します)。次のバリアントが定義されています。

• Apollo NCS バリアント (1 ビット パターン 0xxx ₂で示される) は、1988 年頃に開発された、現在は廃止された Apollo Network Computing System 1.5 UUID 形式との下位互換性を保つためのものです。細部は異なりますが、現代の UUIDv1 との類似性は明らかです。現在の UUID 仕様のバリアント ビットは、 NCS UUID のアドレス ファミリ オクテットの上位ビットと一致します。アドレス ファミリは 0..255 の範囲の値を保持できますが、これまで定義されたのは 0..13 の値だけです。したがって、このビット パターンは0xxx、データベースにまだ存在する歴史的な NCS UUID との競合を回避します。^[11]このバリアントは、「ファミリ」をサブタイプとして定義します。
• OSF DCE バリアント (10xx _{2 ) は、元の}インターネット ドラフトの作成者にちなんで、RFC 4122/DCE 1.1 UUID、または「Leach–Salz」UUID と呼ばれます。このバリアントは、「バージョン」をサブタイプとして定義します。
• Microsoft COM/DCOM バリアント (110x ₂ ) は、RFC では「予約済み、Microsoft Corporation の下位互換性」とされており、Microsoft Windowsプラットフォームの初期の GUID に使用されていました。
• 予約済みのバリアント空間は現在、どの仕様でも使用されていません。

OSF DCE バリアントは、標準で 8 つの「バージョン」を定義しており、特定の使用例では、各バージョンが他のバージョンよりも適切である場合があります。バージョンは、UUID の 7 番目のバイトの上位ニブル(上位 4 ビット、つまり上位 16 進数字) の値によって示されます。16 進数では、これは 2 番目のダッシュの後の文字です。たとえば、 では2 番目のダッシュの後の数字が 4 であるため、UUID はバージョン 4 です。 9c5b94b1-35ad-49bb-b118-8e8fc24abf80...-49bb-...

バージョン 1では、「ノード」(つまり、UUID を生成するコンピュータ) の48 ビットのMAC アドレスと、60 ビットのタイムスタンプを連結します。タイムスタンプは、 1582 年 10 月 15 日の協定世界時(UTC) の深夜からの 100ナノ秒間隔の数です。この日付は、ヨーロッパの大部分でグレゴリオ暦が初めて採用された日付です。RFC 4122 では、時間値は 3400 年頃にロールオーバーすると規定されています^{[2] : 使用されるアルゴリズムに応じて3}であり、これは 60 ビットのタイムスタンプが符号付き量であることを意味します。ただし、libuuid ライブラリなどの一部のソフトウェアでは、タイムスタンプを符号なしとして扱い、ロールオーバー時間を 5623 年に設定します^[12]。ITU-T 勧告 X.667 で定義されているロールオーバー時間は 3603 年です^{[13] :  v}

13 ビットまたは 14 ビットの「一意化」クロック シーケンスは、プロセッサ クロックの進みが十分でない場合や、ノードごとに複数のプロセッサと UUID ジェネレータがある場合に対応するために、タイムスタンプを拡張します。UUID がシステム クロックの進みよりも速く生成される場合、タイムスタンプ フィールドの下位ビットは、UUID が生成されるたびに増分して生成され、高解像度のタイムスタンプをシミュレートできます。各バージョン 1 UUID は、空間 (ノード) と時間 (間隔とクロック シーケンス) の 1 つのポイントに対応しているため、適切に生成された 2 つのバージョン 1 UUID が意図せずに同じになる可能性は実質的にゼロです。時間とクロック シーケンスの合計は 74 ビットなので、2 ⁷⁴ (1.8 × 10^{1ノードIDあたり22}（18兆）のバージョン1 UUIDを生成でき、最大平均速度は1ノードIDあたり毎秒1630億です。 ^[2]

他の UUID バージョンとは対照的に、ネットワーク カードの MAC アドレスに基づくバージョン 1 およびバージョン 2 の UUID は、その一意性に関して、中央登録機関によって発行された識別子、つまりMAC アドレスの組織固有識別子(OUI) 部分に部分的に依存しています。この識別子は、 IEEEによってネットワーク機器の製造元に発行されます。^[14]ネットワーク カードの MAC アドレスに基づくバージョン 1 およびバージョン 2 の UUID の一意性は、ネットワーク カードの製造元がカードに一意の MAC アドレスを適切に割り当てることにも依存しますが、他の製造プロセスと同様に、これはエラーの影響を受けます。仮想マシンは、ハイパーバイザーで構成可能な範囲の MAC アドレスを受け取ります。^[15]さらに、一部のオペレーティング システムでは、エンド ユーザーが MAC アドレスをカスタマイズできます。特にOpenWRT がそうです。^[16]

ノードIDにノードのネットワークカードのMACアドレスを使用すると、バージョン1のUUIDを作成したコンピュータまで追跡できます。文書は、ワードプロセッサソフトウェアによって埋め込まれたUUIDを通じて、作成または編集されたコンピュータまで追跡できる場合があります。このプライバシーホールは、メリッサウイルスの作成者を見つける際に使用されました。^[17]

RFC  9562 では、ノードに MAC アドレスがないか、または MAC アドレスを公開したくないという理由で、バージョン 1 (または 2) UUID の MAC アドレスをランダムな 48 ビットのノード ID に置き換えることが許可されています。その場合、RFC では、ノード ID の最初のオクテットの最下位ビットを 1 に設定する必要があります。^[2]これはMAC アドレスのマルチキャストビットに対応しており、これを設定することで、ネットワーク カードの MAC アドレスに基づいて UUID からノード ID がランダムに生成される UUID (通常はユニキャストMAC アドレスを持つ) を区別できます。^[2]

バージョン 6 は、すべてのタイムスタンプ ビットが最上位から最下位の順に並べられている点を除いてバージョン 1 と同じです。これにより、システムは UUID を単に語彙的に並べ替えるだけで作成順に並べ替えることができますが、これはバージョン 1 では不可能です。

RFC  9562 ではバージョン 2 を「DCE セキュリティ」UUID 用に予約していますが、詳細は提供されていません。このため、多くの UUID 実装ではバージョン 2 が省略されています。ただし、バージョン 2 UUID の仕様は、DCE 1.1 認証およびセキュリティ サービス仕様で提供されています。^[8]

バージョン 2 の UUID はバージョン 1 と似ていますが、クロック シーケンスの最下位 8 ビットが「ローカル ドメイン」番号に置き換えられ、タイムスタンプの最下位 32 ビットが指定されたローカル ドメイン内で意味のある整数識別子に置き換えられます。POSIXシステムでは、ローカル ドメイン番号 0 と 1 はそれぞれユーザー ID ( UID ) とグループ ID ( GID ) 用であり、その他のローカル ドメイン番号はサイト定義です。^[8] POSIX以外のシステムでは、すべてのローカル ドメイン番号はサイト定義です。

UUID に 40 ビットのドメイン/識別子を含める機能にはトレードオフがあります。一方では、40 ビットではノード ID ごとに約 1 兆のドメイン/識別子値を使用できます。一方、クロック値が 28 の最上位ビットに切り捨てられるため (バージョン 1 では 60 ビット)、バージョン 2 の UUID のクロックは 429.49 秒 (7 分強) ごとに 1 回しか「刻み」ません (バージョン 1 では 100 ナノ秒ごと)。また、クロック シーケンスがバージョン 1 の 14 ビットに対して 6 ビットしかないため、7 分間のクロック刻みごとにノード/ドメイン/識別子ごとに 64 個の一意の UUID しか生成できません (バージョン 1 では 16,384 個のクロック シーケンス値)。^[18]

バージョン3とバージョン5のUUIDは、名前空間識別子と名前をハッシュすることによって生成されます。バージョン3ではハッシュアルゴリズムとしてMD5が使用され、バージョン5ではSHA-1が使用されます。^[1]

名前空間識別子自体は UUID です。仕様では、URL、完全修飾ドメイン名、オブジェクト識別子、およびX.500 識別名の名前空間を表すために UUID が提供されていますが、任意の UUID を名前空間指定子として使用できます。

特定の名前空間と名前に対応するバージョン 3 UUID を決定するには、名前空間の UUID をバイト文字列に変換し、入力名と連結して MD5 でハッシュし、128 ビットにします。次に、6 ビットまたは 7 ビットを固定値、4 ビット バージョン (バージョン 3 の場合は 0011 ₂など)、および 2 ビットまたは 3 ビットの UUID「バリアント」( RFC 9562 UUIDを示す10 ₂ や、従来の Microsoft GUID を示す 110 ₂など) に置き換えます。このように 6 ビットまたは 7 ビットは事前に決定されているため、UUID の一意性に寄与するのは 121 ビットまたは 122 ビットのみです。

バージョン 5 の UUID も同様ですが、MD5 の代わりに SHA-1 が使用されます。SHA-1 は 160 ビットのダイジェストを生成するため、バージョン ビットとバリアント ビットが置き換えられる前に、ダイジェストは 128 ビットに切り捨てられます。

バージョン 3 とバージョン 5 の UUID には、同じ名前空間と名前が同じ UUID にマップされるという特性があります。ただし、名前空間も名前も、たとえどちらかが指定されていても、総当たり検索以外では UUID から特定することはできません。RFC 4122では 、バージョン 3 (MD5) よりもバージョン 5 (SHA-1) を推奨しており、どちらのバージョンの UUID もセキュリティ認証情報として使用しないように警告しています。^[2]

バージョン 4 の UUID はランダムに生成されます。他の UUID と同様に、バージョン 4 を示すために 4 ビットが使用され、バリアントを示すために 2 または 3 ビットが使用されます (バリアント 1 の場合は 10 ₂、バリアント 2 の場合は 110 ₂ )。したがって、バリアント 1 (つまり、ほとんどの UUID) の場合、ランダムなバージョン 4 UUID には 6 つのバリアント ビットとバージョン ビットが事前に決定され、ランダムに生成される部分には 122 ビットが残り、合計 2 ¹²²、つまり 5.3 × 10³⁶ (5.3 厘) 個のバージョン 4 バリアント 1 UUID が可能です。使用可能なランダム ビットが 1 つ少なく、バリアントに 3 ビットが消費されるため、バージョン 4、バリアント 2 UUID (レガシー GUID) の数は半分になります。

RFC 9562によれば 、7 番目のオクテットの上位 4 ビットは、UUID がどのバージョンに準拠しているかを示します。つまり、UUIDv4 では、3 番目のグループの最初の 16 進数字は常に で始まります。視覚的には、これは のように見えます。ここで、 はUUID バージョン フィールドです。数字の上位 2 ビットまたは 3 ビットはバリアントをエンコードします。値は、2 ビット表示の場合は 、 、または で、3 ビット表示の場合はまたはです。たとえば、ランダムな UUID バージョン 4、バリアント 1 は になる可能性があります 。^[19]4xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxxMN89ABCD8D8AC610-566D-4EF0-9C22-186B2A5ED793

バージョン 7 UUID (UUIDv7) は、高負荷データベースおよび分散システムのキー用に設計されています。

UUIDv7 は、約ミリ秒の粒度を持つ 48 ビットのビッグエンディアン Unix エポック タイムスタンプで始まります。タイムスタンプは、任意の時間シフト値でシフトできます。タイムスタンプの直後にバージョン ニブルが続き、その値は 7 である必要があります。バリアント ビットは である必要があります10x。残りの 74 ビットは、ランダム シード カウンター (オプション、12 ビット以上 42 ビット以下) とランダムです。

2 つのカウンターロールオーバー処理方法を併用できます。

• カウンターの最も重要な左端のガード ビットをゼロ シードします。
• 実際の時間より先にタイムスタンプを増分し、オーバーフローしたときにカウンターを再初期化します。

DBMS では、UUIDv7 ジェネレーターはスレッド間で共有 (テーブルまたは DBMS インスタンスに結び付ける) することも、スレッドローカルにすることもできます (単調性、局所性、パフォーマンスは低下します)。

バージョン 8 には 2 つの要件のみがあります。

• バリアントビットは である必要がある10ため、バリアントを含むニブルは 8 ( 0x1000)、9( 0x1001)、A( 0x1010)、または B( 0x1011) である必要があります。
• バージョン ニブルの値は 8 である必要があります。

これらの要件は、システムにそれがバージョン 8 の UUID であることを伝えます。残りの 122 ビットはベンダーがカスタマイズします。バージョン 4 との違いは、これらの 122 ビットはランダムですが、UUID バージョン 8 の 122 ビットはベンダー固有のルールに従うためランダムではないことです。

「nil」UUIDはUUIDです00000000-0000-0000-0000-000000000000。つまり、すべてのビットがゼロに設定されます。^[1]

「最大」UUIDは「オムニ」UUIDとも呼ばれ、FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFFすべてのビットが1に設定されているUUIDです。^[1]

当初、アポロコンピュータはUUIDを次のワイヤ形式で設計しました。^{[5] [11]}

その後、UUID は、従来のファミリー フィールドと新しいバリアント フィールドを組み合わせて拡張されました。ファミリー フィールドでは、これまで 0 から 13 までの値しか使用していなかったため、最上位ビットが 0 に設定された UUID が従来の UUID であると判断されました。これにより、ファミリー グループの表は次のようになります。

従来の Apollo NCS UUID の形式は、前の表で説明したとおりです。OSF DCE UUID バリアントは、RFC  9562 で説明されています。Microsoft COM / DCOM UUID のバリアントは、Microsoft のドキュメントで説明されています。

UUIDをバイナリ形式で保存する場合、ビッグエンディアンで順番にエンコードされます。たとえば、00112233-4455-6677-8899-aabbccddeeffはバイトとしてエンコードされます00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff。^{[21] [22]}

例外として、Microsoft のバリアント 2 UUID ("GUID") があります。これは歴史的にCOM/OLE ライブラリで使用されており、リトルエンディアン形式を使用しますが、UUID の最初の 3 つのコンポーネントがリトルエンディアン、最後の 2 つがビッグエンディアンであるため、混合エンディアンのように見えます。Microsoft の GUID 構造では、最後の 8 バイトを 8 バイト配列として定義し、昇順でシリアル化するため、バイト表現は混合エンディアンのように見えます。^[23]たとえば、はバイトとしてエンコードされます。^{[24] [25]}00112233-4455-6677-8899-aabbccddeeff33 22 11 00 55 44 77 66 88 99 aa bb cc dd ee ff

ほとんどの場合、UUID は 16 進数値として表されます。最もよく使用される形式は 8-4-4-4-12 形式 で、xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx各 はx4 ビットを表します。その他のよく知られている形式には{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}、Microsoft のシステム (Windows など) のように中括弧 が付いた 8-4-4-4-12 形式 やxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx、すべてのハイフンが削除された があります。場合によっては、xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx16 進数値を示すために、プレフィックス "0x" またはサフィックス "h" が付いた を使用することもできます。ハイフン付きの形式は、新しいバリアント システムで導入されました。それ以前は、従来の Apollo 形式ではわずかに異なる形式 が使用されていました: 34dc23469000.0d.00.00.7c.5f.00.00.00。最初の部分は時間 (time_high と time_low の組み合わせ) です。予約フィールドはスキップされます。ファミリ フィールドは最初のドットの直後に来るため、この場合は0d(10 進数で 13) DDS (データ配信サービス)になります。ドットで区切られた残りの部分は、ノード バイトです。

16 進数値の小文字形式は、一般的に推奨される形式です。特に、ITU-T Rec. X.667 で定義されているような一部のコンテキストでは、テキストの生成時に小文字が必要ですが、大文字バージョンも受け入れられる必要があります。

UUID は 128 ビットの整数として表すことができます。たとえば、UUID は550e8400-e29b-41d4-a716-446655440000113059749145936325402354257176981405696 として表すこともできます。UUID の最初のビットが 1 に設定されている場合、符号付き値と符号なし値の両方を持つことができることに注意してください。

UUID は 128 ビットの2 進数として表すことができます。たとえば、UUID は550e8400-e29b-41d4-a716-4466554400000101010100001110100001000000000001110001010011011010000011101010010011100010110010001000110011001010101010001000000000000000000 と表すこともできます。

RFC  9562 は、「uuid」名前空間を登録します。これにより、 のように、UUID から URN を作成できます。urn:uuid:550e8400-e29b-41d4-a716-446655440000これには通常の 8-4-4-4-12 形式が使用されます。 のように、UUID から OID URN を作成することもできますurn:oid:2.25.113059749145936325402354257176981405696。その場合は、符号なし 10 進形式が使用されます。「oid」URN よりも「uuid」URN の使用が推奨されます。

衝突は、同じ UUID が複数回生成され、異なる参照先に割り当てられたときに発生します。ネットワーク カードからの一意の MAC アドレスを使用する標準バージョン 1 およびバージョン 2 UUID の場合、衝突が発生する可能性は低く、実装が意図的または不注意で標準と異なる場合にのみ発生する可能性が高くなります。

MACアドレスを使用して生成されたバージョン1およびバージョン2のUUIDとは対照的に、ランダムに生成されたノードIDを使用するバージョン1およびバージョン2のUUID、ハッシュベースのバージョン3およびバージョン5のUUID、およびランダムなバージョン4のUUIDでは、実装上の問題がなくても衝突が発生する可能性がありますが、その確率は通常無視できるほど小さいです。この確率は、誕生日問題の分析に基づいて正確に計算できます。^[26]

例えば、少なくとも1回の衝突の確率が50%になるように生成する必要があるランダムバージョン4 UUIDの数は2.71京であり、次のように計算される。^[27]

${\displaystyle n\approx {\frac {1}{2}}+{\sqrt {{\frac {1}{4}}+\ln(2)\times 2^{123}}}\approx 2.71\times 10^{18}.}$

この数値は、約 86 年間にわたって毎秒 10 億個の UUID を生成することに相当します。UUID あたり 16 バイトでこれだけの UUID を含むファイルは約 43.4 エクサバイト(37.7  EiB ) になります。

衝突の確率がpになるために生成する必要があるバージョン4 UUIDの最小数は、次の式で近似されます。

${\displaystyle {\sqrt {2\times 2^{122}\times \ln {\frac {1}{1-p}}}}.}$

したがって、103 兆個のバージョン 4 UUID 内で重複が見つかる確率は 10 億分の 1 です。

衝突は、製造業者がマザーボードなどの製品にデフォルトのUUIDを割り当て、その後製造工程でデフォルトのUUIDを上書きしなかった場合などに発生します。たとえば、UUID 03000200-0400-0500-0006-000700080009は、Gigabyteブランドのマザーボードのさまざまなユニットで発生します。^[28]

重要な用途としては、ext2 / ext3 / ext4ファイルシステムのユーザー空間ツール（e2fsprogs はutil-linuxが提供する libuuid を使用）、LVM、LUKS暗号化パーティション、GNOME、KDE、macOS などがあり、^[29]そのほとんどはTheodore Ts'oによるオリジナルの実装から派生したものです。^[12] 「パーティション ラベル」と「パーティション UUID」はどちらもスーパーブロックに格納されます。これらはどちらもパーティションではなくファイルシステムの一部です。たとえば、ext2～4 には UUID が含まれますが、NTFS や FAT32 には含まれません。スーパーブロックはファイルシステムの一部であるため、パーティション内に完全に含まれているため、dd if=/dev/sda1 of=/dev/sdb1sda1 と sdb1 の両方に同じラベルと UUID が残ります。

Microsoft のコンポーネント オブジェクト モデル(COM)で使用される GUID にはいくつかの種類があります。

• IID – インターフェース識別子（システムに登録されているものはWindowsレジストリの[HKEY_CLASSES_ROOT\Interface]^[30]に保存されます）
• CLSID – クラス識別子; (保存場所[HKEY_CLASSES_ROOT\CLSID])
• LIBID – 型ライブラリ識別子（[HKEY_CLASSES_ROOT\TypeLib]^[31]に保存）
• CATID – カテゴリ識別子（クラスに存在することで、そのクラスが特定のクラスカテゴリに属していることが識別され、[HKEY_CLASSES_ROOT\Component Categories]^[32]にリストされる）

UUID は、データベーステーブル内の一意のキーとしてよく使用されます。Microsoft SQL Serverバージョン 4 Transact-SQLのNEWID関数は、標準のランダムなバージョン 4 UUID を返しますが、NEWSEQUENTIALID関数は、次のシステム再起動まで順番に昇順になるようにコミットされる UUID に似た 128 ビットの識別子を返します。^[33] OracleデータベースのSYS_GUID関数は、名前にもかかわらず、標準の GUID を返しません。代わりに、ホスト識別子とプロセスまたはスレッド識別子に基づいて、GUID に似た 16 バイト 128 ビットの RAW 値を返します。^[34] PostgreSQLにはUUIDデータ型が含まれており^[35]、モジュールの関数を使用してほとんどのバージョンの UUID を生成できます。^{[36] [37]} MySQL は、標準のバージョン 1 UUID を生成するUUID関数を提供します。^[38]

バージョン 3、4、5 の標準 UUID のランダムな性質と、標準バージョン 1 および 2 内のフィールドの順序付けにより、UUID を主キーとして使用すると、データベースの局所性またはパフォーマンスに問題が生じる可能性があります。たとえば、2002 年に Jimmy Nilsson は、キーとして使用されているバージョン 4 の UUID をシステム時間に基づく非ランダムなサフィックスを含むように変更すると、Microsoft SQL Server のパフォーマンスが大幅に向上したと報告しました。このいわゆる「COMB」(combined time-GUID) アプローチでは、Nilsson が認めているように、UUID が重複する可能性が大幅に高まりましたが、Nilsson が要求したのはアプリケーション内での一意性だけでした。^[39]タイムスタンプが最初に来るようにバージョン 1 および 2 の UUID を並べ替えてエンコードすることで、挿入パフォーマンスの低下を回避できます。^[40]

COMB のような UUID ペイロードの配置は、最終的にRFC  9562 で UUIDv6 および UUIDv7 として標準化されました。

• 誕生日攻撃
• オブジェクト識別子(OID)
• 統一リソース識別子(URI)
• スノーフレークID

• ITU-T X.667勧告（無料アクセス）
• ISO/IEC 9834-8:2014 (有料)
• テクニカルノート TN2166 - GPT の秘密 - Apple Developer
• UUID ドキュメント - Apache Commons Id
• CLSID キー - Microsoft Docs
• ユニバーサルユニーク識別子 - The Open Group ライブラリ
• UUID デコーダー ツール
• UUID の簡単な歴史
• UUIDの生成方法を理解する