UUID
UUID の書式
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
xは16進([0-9A-Fa-f])
それぞれの桁は 8, 4, 4, 4, 12
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
Nの上位1～3bit分が用途
table:variant
0 1 2
0 * *
1 0 * RFC4122
1 1 0
1 1 1 将来のための予約
Mの4bitがバージョン
なぜこの書式なのか?
元々の生成ルール(バージョン1)による
UUID のバージョンは、バージョンというより種別という認識が正しい。
UUID v1
TTTTTTTT-TTTT-1TTT-sSSS-AAAAAAAAAAAA
table:uuid_v1_format
T 60 タイムスタンプ(バージョンを挟んでいることに注意)
sSSS 16 クロックシーケンス
A 48 MACアドレス
タイムスタンプ
1582-10-15 00:00:00 (UTC) (グレゴリオ暦実施日) からの100ns 単位のシリアル時刻
最大で西暦5235年まで使える
クロックシーケンス
上位2bitは10固定 (RFC4122)
残り14bitは生成する度にインクリメントされる。
MACアドレスは世界で1つしかないこと(ユニーク性)が保証されているので、これで十分にユニークであるIDが発行できる。
MACアドレスはトラッキングされてしまうので、現在は使われない方向になっている。
(MACアドレスから、マシンが特定できてしまう。)
ただし、各種仮想環境ではMACアドレスはランダム生成されている。(つまり、確率的に衝突する可能性がある。)
UUID v4
完全にランダムにIDを発行している。
このため、わずかに衝突する可能性がある。
128bit - 4bit(バージョン) - 2bit(バリアント)で、122bit
乱数の生成に問題がなければ、2^64個生成しても 1/2^58の確率でしか当たらない。
UUID v6
UUID v1 のタイムスタンプをビット順を時系列順(大きい物から順)に並べ直したもの
UUID v7
先頭にタイムスタンプ(48bitのUnixタイムスタンプ)を付け、後方は74bitのランダム値としたもの。
タイムスタンプがあるので時系列に並べることができる。(前後関係が必要な場合に都合が良い)
データベースなどのキーではタイムスタンプでデータが集中するので、検索効率が良くなる。
UUID v8
完全実装依存
ユーザーが自由に設計してよい。
バージョン1
時刻(+シリアル)とユニークなノードID(通常はネットワークカードのMACアドレス)で生成。
MACアドレスがユニークであるため、基本的に衝突しない。
このため、バージョン1を使う方が妥当だが、MACアドレスが分かってしまうため、意図しないトラッキング(個人の特定)が発生する可能性がある。
仮想環境では、MACアドレスが乱数で発行されている。このため、24bit程度の分離度しかない。仮想環境が単純コピーされて利用されている場合はそのまま衝突する。
バージョン3/5はハッシュ(バージョン3はMD5、バージョン5はSHA-1)なので衝突する可能性がある。
MD5, SHA-1 自体は128bit以上だが、UUIDには設定できるビットが122bitしかないため、本質的にそれを越えることができない。
このため、積極的にバージョン5の方を使う理由はない。
バージョン4 は乱数(乱数部122bit)なので一定の確率で衝突する可能性がある。
疑似乱数を使うと122bitまでの分離ができていない可能性がある。
暗号用の乱数を使う必要がある。
バージョン5 は名前(文字列)から sha1 ハッシュを求めて UUID とするもの。
あくまでハッシュ値なので、異なる文字列で同一のハッシュ値になることが考えられる。
通常の使用では問題ならない程度になると思われる。
バージョン6 は時間+ランダム値
関連
GUID