UUIDジェネレーター

UUIDは、次に利用可能な番号を割り当てる中央調整機関なしで、任意の数の別々のシステムによっていつでも独立して生成されるよう設計された128ビットの識別子であり、それでいて2つの生成された値が決して衝突しないという圧倒的な統計的保証を持っています。これは、次の番号を順番に追跡して割り当てるために単一のデータベースを必要とする自動増分の整数IDとは根本的に異なります — UUIDは、ネットワーク接続のないスマートフォン上、サーバーレス関数の中、あるいは千の並行マイクロサービスインスタンス全体で、それらの間でまったく調整を必要とせずに同時に生成できます。数の空間の単なる大きさが、独立して生成される数にかかわらず偶発的な衝突を天文学的にありそうにないものにするためです。

UUIDバージョン4は本質的に128ビット全体を暗号学的にランダムなデータで埋め、これにより生成される各値は完全に予測不可能になり、それがいつ作られたか、あるいは他のどのUUID v4との相対的な順序についても一切のヒントを与えません — セキュリティトークンのようなものにとってはまさに望ましい性質であり、予測可能性自体が脆弱性になってしまうものです。RFC 9562（2024年）でずっと最近標準化されたUUIDバージョン7は、その不透明性の一部を意図的に犠牲にします: 先頭ビットにミリ秒精度のタイムスタンプを配置するため、後で生成されたUUID v7は常に前に生成されたものより後ろに並びますが、残りのビットはv4と同じくランダムで推測不可能なままです。この2つは、片方が単純に「優れている」競合するデザインではありません — 順序付けか均一な予測不可能性のどちらが特定のユースケースで本当に重要かに応じて、同じ基礎となるランダム性を異なる性質と交換しているのです。

主キーを支えるデータベースインデックスは通常B-treeとして保存されます。これは新しい値が既存のソート順の最後またはその近くに挿入されるときに最もよく機能する構造であり、まさに従来の自動増分整数キーが振る舞う方法です。均一にランダムなUUID v4の主キーは、毎回そのソートされた構造内の効果的にランダムな位置に挿入され、データベースは最後にただ追加するのではなく、木全体に散らばったインデックスページを繰り返し分割・再バランスすることを強いられます。小規模ではこのオーバーヘッドは見えませんが、数百万行の規模になると、これはインデックス断片化と書き込みの遅延の本物の測定可能な原因になります — まさにこれが、UUID v7の先頭タイムスタンプが特に解決するために標準化された問題であり、UUIDが一意で推測不可能なIDを維持しながら、なおおおよそ連続した順序で挿入され続けることを可能にします。