はじめに
アプリ開発において、切っても切り離せないIDですが、
本記事では、以下の 3 つの ID 生成方式について、その特徴、メリット、デメリットを説明します。
- Auto Increment ID
- UUID (Universally Unique Identifier
- ULID (Universally Unique Lexicographically Sortable Identifier)
また、各方式の違いを理解し、どのIDを使用するのかの選択基準を解説します。
Auto Increment ID（自動採番ID）
概要
-
仕組み
データベースがレコード追加時に連番（整数値）を自動的に付与する方式。
例：MySQL や PostgreSQL のINTやBIGINT型を用いる。
メリット
-
シンプルで高速
連番のため、クラスタインデックスに適しており、挿入性能が高い。 -
順序性が保証
レコードの挿入順に値が増加するため、時系列性が保たれる。
デメリット
-
分散システムでの課題
単一ノード向けのため、複数のデータベース間で採番を合わせると衝突リスクが発生する。 -
予測可能性
連番は容易に次の値が予測可能なため、セキュリティ上の懸念がある場合がある。
UUID (Universally Unique Identifier)
概要
-
仕組み
128 ビットの一意な識別子で、様々なバージョンがある。主に UUID v4（ランダム生成）が利用される。
例：550e8400-e29b-41d4-a716-446655440000
メリット
-
グローバルな一意性
各システム間での衝突リスクが非常に低く、中央管理不要。 -
分散環境向け
各ノードで独立して生成できるため、スケーラビリティが高い。
デメリット
-
サイズが大きい
16 バイト（文字列表現では 36 文字）と Auto Increment よりもストレージやインデックスに負担がかかる。
UUID v4
メリット
- 高いランダム性を持ち、衝突の可能性が極めて低い。
- 事前の調整なしに分散システムで一意性を確保できる。
デメリット
- ランダム生成のため、順序性がなく、B-treeインデックスでの挿入効率が低下する可能性がある。
- 可読性が低く、デバッグや手動管理が難しい。
- 生成コストが比較的高い。
UUID v7
メリット
- タイムスタンプベースで生成されるため、時系列順に並びやすく、B-treeインデックスの効率が向上する。
- UUID v4と同様に分散環境での一意性を確保できる。
デメリット
- システムの時刻が適切に同期されていない場合、順序の不整合が発生する可能性がある。
ULID (Universally Unique Lexicographically Sortable Identifier)
概要
-
仕組み
ULID は 128 ビットですが、先頭 48 ビットにミリ秒単位のタイムスタンプ、残り 80 ビットにランダム値を割り当て、Base32 でエンコードする。
例：01ARZ3NDEKTSV4RRFFQ69G5FAV
メリット
-
時系列順ソート可能
タイムスタンプ部分により、生成順にソートできるため、インデックスの効率が向上。
デメリット
-
標準化の進行状況
UUID ほど広く標準化されていない。
まとめと利用シーンの考察
利用シーンに応じた選択
-
シンプルなシングルノード環境
Auto Increment 型は、シンプルかつ高速なため、単一データベースや小規模なアプリケーションに最適。 -
分散システム
分散システムでは、各ノードで独立して一意な ID を生成できる UUID（特に v4）や ULID がいい。
UUID v7、ULID は、タイムスタンプによる順序性があるため、インデックス効率が向上する。