メインコンテンツまでスキップ

2. Motivation (動機)

2. Motivation (動機)​

UUID を使用する主な理由の 1 つは, それらを管理するために集中管理機関が必要ないことです (2 つの形式ではオプションの IEEE 802 ノード ID を利用する場合がありますが, 他の形式では利用しません)。その結果, オンデマンドの生成を完全に自動化し, さまざまな目的に使用できます。ここで説明する UUID 生成アルゴリズムは, 必要に応じて, マシンごとに毎秒 1000 万以上の非常に高い割り当て率をサポートするため, トランザクション ID としても使用できます。

UUID は固定サイズ (128 ビット) であり, 他の代替手段と比較して適度に小さいです。これは, あらゆる種類のソート, 順序付け, ハッシュ化; データベースへの保存; 簡単な割り当て; および一般的なプログラミングの容易さに適しています。

UUID は一意で永続的であるため, 優れた URN になります。登録プロセスなしで新しい UUID を生成できる独自の機能により, UUID は最も低いミントコストの URN の 1 つになります。

2.1. Update Motivation (更新の動機)​

UUID が最初に作成されて以来, 多くのことが変わりました。最新のアプリケーションでは, データベースキー, ファイル名, マシンまたはシステム名, イベント駆動型トランザクションの識別子など, 複雑な計算システムのさまざまなアイテムのプライマリ識別子として UUID を作成および利用する必要があります。

UUID が人気を博している分野の 1 つはデータベースキーです。これは, 最新のアプリケーションがますます分散化されていることに起因しています。このような場合, データベースでよく使用される "自動インクリメント" スキームはうまく機能しません: ネットワーク全体で連続する数値識別子を調整するために必要な作業は容易に負担になる可能性があります。UUID を使用すると, 調整を必要とせずに分散システムで一意で適度に短い値を作成できるという事実により, UUID は優れた代替手段になりますが, [RFC4122] によって最初に定義された UUID バージョン 1-5 には, 次のような他の望ましい特性が欠けています:

  1. UUIDv4 (セクション 5.4 で説明) などの時間順序付けされていない UUID バージョンは, データベースインデックスの局所性が低くなります。これは, 連続して作成された新しい値がインデックス内で互いに近くないことを意味します; したがって, ランダムな場所で挿入を実行する必要があります。このために使用される一般的な構造 (B ツリーとそのバリアント) に対する結果として生じる負のパフォーマンス効果は劇的になる可能性があります。

  2. UUIDv1 タイムスタンプで使用される 100 ナノ秒のグレゴリオ紀元 (セクション 5.1 で説明) は一般的ではなく, [IEEE754] で説明されている標準の数値形式を使用して正確に表現することは困難です。

  3. 単純なバイトごとの比較を実行できるのとは対照的に, 時系列で順序付けるには自己検査/解析が必要です。

  4. UUIDv1 のノードフィールドでメディアアクセス制御 (Media Access Control, MAC) アドレスを使用すると, プライバシーとネットワークセキュリティの問題が発生します。公開された MAC アドレスは, 攻撃面として使用してネットワークインターフェースを特定し, そのようなマシンに関するその他のさまざまな情報 (最小限でも製造元, および潜在的には他の詳細) を明らかにすることができます。さらに, 仮想マシンとコンテナの出現により, MAC アドレスの一意性は保証されなくなりました。

  5. [RFC4122] で指定された実装の詳細の多くには, すべてのアプリケーションに対して指定することも, 相互運用可能な実装を生成するために必要でもないトレードオフが含まれています。

  6. [RFC4122] は, UUID を生成するための要件と単に保存するための要件を区別していませんでしたが, それらはしばしば異なります。

上記の問題により, 多くの広く配布されているデータベースアプリケーションと大規模なアプリケーションベンダーは, データベースキーとして使用するために, より優れた時間ベースでソート可能な一意の識別子を作成する問題を解決しようとしてきました。これにより, 過去 10 年以上にわたって, わずかに異なる方法で同じ問題を解決する多数の実装が生まれました。

本仕様を準備する際に, 次の 16 の異なる実装が, 合計 ID 長, ビットレイアウト, 字句形式とエンコーディング, タイムスタンプタイプ, タイムスタンプ形式, タイムスタンプ精度, ノード形式とコンポーネント, 衝突処理, およびマルチタイムスタンプティック生成シーケンスの傾向について分析されました:

  1. [ULID]
  2. [LexicalUUID]
  3. [Snowflake]
  4. [Flake]
  5. [ShardingID]
  6. [KSUID]
  7. [Elasticflake]
  8. [FlakeID]
  9. [Sonyflake]
  10. [orderedUuid]
  11. [COMBGUID]
  12. [SID]
  13. [pushID]
  14. [XID]
  15. [ObjectID]
  16. [CUID]

これらの実装と上記の問題の検査により, これらの問題に対処するために新しい UUID が適応されたこの文書が生まれました。

さらに, [RFC4122] 自体は, 次のようなトピックに対処するために全面的な見直しが必要でした:

  1. さまざまな正誤表レポートの実装。主にビットレイアウトの明確化に関するもので, これにより一貫性のない実装 [Err1957], [Err3546], [Err4975], [Err4976], [Err5560] などが生じました。

  2. 他の UUID バージョンを UUIDv1 ビットレイアウトから切り離して, "time_hi_and_version" などのフィールドを時間ベースではない UUID 内で参照する必要がないようにし, 同時に UUIDv3, UUIDv4, および UUIDv5 について UUIDv1 と同様の定義セクションを提供します。

  3. 既存およびプロトタイプ実装によって観察された多くの実際のシナリオとコーナーケースに関する実装のベストプラクティスを提供します。

  4. MAC アドレス, ハッシュアルゴリズム, 安全な乱数性, およびその他のトピックに関連する現代のセキュリティのベストプラクティスと考慮事項に対処します。

  5. 実装固有および/または実験的な UUID 設計のための標準ベースのオプションを実装に提供します。

  6. 仕様に従って作成された実際の UUID を示すより多くのテストベクトルを提供します。

に最終更新