UUID v4 vs. v7: jaký jedinečný identifikátor zvolit?

UUID je jedinečný identifikátor o 128 bitech bez centrální koordinace. Verze 4, zcela náhodná, dominuje už léta. Verze 7, novější (RFC 9562, 2024), zahrnuje časové razítko na začátku, aby produkovala identifikátory seřazené v čase. Tento rozdíl, zdánlivě bezvýznamný, radikálně mění výkon v databázi. Zde je, kterou zvolit.

Co je UUID?

UUID (Universally Unique Identifier) je číslo o 128 bitech reprezentované 32 hexadecimálními znaky seskupenými do pěti bloků, například 550e8400-e29b-41d4-a716-446655440000. Jeho smysl: generovat jedinečný identifikátor bez dotazu na centrální autoritu, což jej činí ideálním pro distribuované systémy. Můžete jej generovat naším generátorem UUID.

Existuje několik verzí; nejrelevantnější dnes pro klíče záznamů jsou v4 (náhodná) a v7 (seřazená v čase).

UUID v4 (náhodný)

UUID v4 je tvořen 122 náhodnými bity (zbytek kóduje verzi a variantu). Pravděpodobnost kolize je tak nízká, že je v praxi zanedbatelná. Je to výchozí verze ve většině jazyků a knihoven.

• Nepředvídatelný: ideální pro tokeny nebo veřejné identifikátory, které nechceme mít uhodnutelné
• Žádný únik informací: neprozrazuje datum ani pořadí vytvoření
• Nevýhoda: zcela neuspořádaný, což sužuje indexy databáze

UUID v7 (seřazený v čase)

UUID v7 umístí časové razítko Unix v milisekundách do svých prvních 48 bitů, následovaných náhodnými bity. Dva UUID v7 generované v různých okamžicích se tedy řadí v pořadí svého vytvoření, přičemž zůstávají jedinečné a prakticky neuhodnutelné.

• Řaditelný: lexikografické pořadí odpovídá chronologickému pořadí
• Přátelský k indexům: vkládání probíhá na konci indexu, jako automatické inkrementování
• Protihodnota: prozrazuje okamžik vytvoření, což může být nežádoucí pro veřejný identifikátor

Srovnávací tabulka

Vliv na databáze

To je jádro věci. Relační databáze ukládají své indexy do B-stromů (B-tree). Vkládání náhodných klíčů (v4) rozptyluje zápisy všude po indexu, což způsobuje fragmentaci, štěpení stránek a méně účinnou cache. U velkých objemů se výkon vkládání citelně zhoršuje.

Seřazené klíče (v7) se vkládají vždy na konec indexu, jako automaticky inkrementovaný identifikátor. Vracejí se rychlá vkládání, lepší lokalita a kompaktnější index. To je obzvlášť patrné u primárního klíče v InnoDB (MySQL), kde primární klíč určuje fyzické pořadí řádků.

Kdy zvolit jeden či druhý

Zvolte UUID v4, když

• Identifikátor je vystaven veřejně a nesmí nic prozradit
• Generujete tokeny, odkazy ke sdílení, tajemství
• Pořadí a datum vytvoření nesmí být uhodnutelné
• Chcete maximální kompatibilitu se stávajícím

Zvolte UUID v7, když

• UUID slouží jako primární klíč v databázi
• Objem vkládání je vysoký a výkon indexu má význam
• Chcete řadit podle pořadí vytvoření bez vyhrazeného sloupce
• Prozrazení okamžiku vytvoření není problém

Doporučení

Pro primární klíč databáze nyní upřednostněte UUID v7: zachováte distribuovanou jedinečnost UUID a zároveň se vyhnete penalizaci indexu u v4. Ponechte UUID v4 pro veřejné identifikátory, tokeny a tajemství, kde mají přednost úplná nepředvídatelnost a absence časového úniku.

Přesto ověřte podporu v7 ve vašem jazyce a ORM: RFC je nedávná, ale rozšíření postupuje rychle.

Časté dotazy