Generátor UUID v4

Generátor UUID v4 – 122 bitů čisté náhody bez časové kotvy

Tento nástroj generuje identifikátory UUID verze 4 přímo ve vašem prohlížeči. Na rozdíl od mnoha jiných generátorů ID zde nenajdete žádný časový údaj ani sekvenční číslo. Každý vygenerovaný řetězec v sobě nese 122 bitů čisté náhodnosti. Zbylých 6 bitů je pevně daných – 4 bity určují variantu UUID (vždy 10xx v binární podobě) a 2 bity verzi (vždy 0100 pro v4). Tato struktura je definována standardem RFC 4122 a je neměnná bez ohledu na to, jaké přepínače na stránce použijete.

Klíčový důsledek: UUID v4 nelze řadit podle času ani podle žádné logické posloupnosti. Každý identifikátor je nezávislý na všech ostatních. Pokud taková ID použijete jako primární klíč v databázi s B‑stromovým indexem (například PostgreSQL, MySQL s InnoDB, SQL Server), nové záznamy se ukládají na náhodné pozice v indexu. To způsobuje jeho fragmentaci, protože strom se musí neustále přestavovat. V praxi to znamená pomalejší zápisy a horší využití cache paměti – zvláště u tabulek s miliony řádků je rozdíl oproti časově řazeným identifikátorům (UUID v7, ULID) měřitelný v desítkách procent.

Samotná pravděpodobnost kolize je při 122 bitech entropie astronomicky nízká. Abyste měli 50% šanci na vznik duplicity, museli byste vygenerovat zhruba 2^61 identifikátorů – to je přibližně 2,3 × 10^18 kusů. Pro praktické nasazení (miliony či miliardy záznamů) je kolize natolik nepravděpodobná, že ji můžete zanedbat.

Struktura UUID v4 – co se skrývá uvnitř 36 znaků

Každé UUID v4 vypadá jako xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, kde x zastupuje hexadecimální číslici (0–f) a y hexadecimální číslici, jejíž první dva bity jsou 10. Rozložme si to:

• Časová část (8 znaků): Prvních 32 bitů je zcela náhodných – žádná časová informace.
• Druhá část (4 znaky): Dalších 16 bitů náhodných.
• Třetí část (4 znaky): Začíná vždy číslicí 4 (verze), zbylá 4 číslice jsou náhodné, celkem 12 bitů náhodnosti.
• Čtvrtá část (4 znaky): Začíná jednou z hodnot 8, 9, a nebo b (variantní bity 10), zbylá 3 číslice jsou náhodné, celkem 12 bitů náhodnosti.
• Pátá část (12 znaků): Zbylých 48 bitů náhodných.

Dohromady tedy: 32 + 16 + 12 + 12 + 48 = 120 náhodných bitů, plus 2 bity pro verzi a variantu, které jsou fixní. Standard říká 122 bitů náhodnosti – malá nepřesnost v součtu vzniká tím, že ne všechny náhodné bity v hexadecimálním zápisu jsou stejně „husté“ (například třetí část má jen 12 náhodných bitů, protože 4 bity zabírá číslice 4).

Pro zajímavost: celý řetězec v hexadecimálním tvaru (s pomlčkami) má 36 znaků, bez pomlček 32 znaků. Každý znak reprezentuje 4 bity – 32 × 4 = 128 bitů, z nichž 122 je náhodných a 6 pevných.

Proč UUID v4 devastuje B‑stromové indexy – a co s tím

Toto je nejčastější chyba, kterou vývojáři při použití UUID v4 dělají. Vezměme typický scénář: tabulka users s primárním klíčem typu UUID v4. Nový uživatel se zaregistruje, databáze vygeneruje náhodné UUID v4 a vloží ho do B‑stromu. Protože je náhodné, skončí někde uprostřed – strom se musí rozdělit a přeuspořádat.

Opakovaným vkládáním vzniká fragmentace indexu – listové stránky nejsou zaplněny souvisle, mezi nimi jsou mezery. Index je fyzicky větší, než by mohl být, a čtení vyžaduje více I/O operací. U sekvenčních (autoincrement) klíčů nové hodnoty vždy padají na konec stromu, takže se index rozrůstá lineárně a nedochází k přestavbám uprostřed.

Jak velký je rozdíl? Reálné benchmarky ukazují, že zápis do tabulky s UUID v4 jako primárním klíčem může být 3–4× pomalejší než s autoincrement celočíselným klíčem. U čtení (SELECT podle primárního klíče) je rozdíl menší, ale stále znatelný kvůli větší velikosti indexu v paměti. Pokud máte databázi s mnoha vkládáními (např. logování, události, session), je UUID v4 jedna z nejhorších možných voleb.

Kdy to přesto dává smysl:

• Pracujete v distribuovaném prostředí, kde nelze použít centrální sekvenci.
• Potřebujete generovat ID offline (bez spojení s databází).
• Chcete zabránit enumeraci záznamů (u autoincrement někdo snadno odhadne počet uživatelů).
• Identifikátory vznikají v mnoha nezávislých službách a je nutné je později sloučit.

Pokud potřebujete náhodně vypadající, ale časově seřaditelná ID, zvažte UUID v7 (časová razítka + náhodnost) nebo ULID. Oba formáty nabízí lepší indexovou lokalitu a přitom zachovávají vysokou náhodnost a bezkolizní charakter.

Srovnání s časově orientovanými identifikátory

UUID v7 a ULID jsou navrženy jako přímá náhrada UUID v4 pro databázové primary keys. Oba kombinují časové razítko s náhodností – první část identifikátoru je monotónně rostoucí podle aktuálního času, druhá část je náhodná. Výsledek: nové záznamy se v indexu ukládají blízko sebe, odpadá fragmentace. Zároveň se při shodě časových razítek (např. v rámci jedné milisekundy) použije náhodná část, takže kolize jsou i nadále extrémně nepravděpodobné.

Pokud na stránce přepnete z "UUID v4" na "UUID v7" nebo "ULID", uvidíte, že první znaky identifikátorů se v rámci jedné generace mění jen minimálně – právě kvůli časovému razítku. Naproti tomu UUID v4 vypadá pokaždé úplně jinak.

Kdy a proč používat UUID v4 – konkrétní případy

1. API tokeny a session ID – Nechcete, aby někdo z tokenu vyčetl, kdy byl vytvořen (časová korelace). UUID v4 je zcela neprůhledné.
2. Offline generování v distribuovaných systémech – Aplikace běžící na letadle, lodi nebo v odlehlé oblasti, která se připojuje k internetu jen občas. UUID v4 lze generovat lokálně bez konfliktu.
3. Bezpečnostní audity a logy – Potřebujete unikátní ID události, která nesmí odhalit nic o pořadí nebo počtu událostí.
4. Testovací data – Při generování vzorků dat pro vývoj a testování je UUID v4 ideální: je rychlé, náhodné a nikdy nekoliduje v rámci testovací sady.

Ve všech těchto případech je generování v prohlížeči (client‑side) výhodou – nic neodchází na server, latence je nulová. Stránka používá crypto.randomUUID() nebo ekvivalentní rozhraní, která čerpají z kryptograficky bezpečného generátoru náhodných čísel operačního systému.

Formátovací přepínače – pomlčky a velikost písmen

Dva přepínače na stránce – Uppercase a Include hyphens – ovlivňují pouze finální podobu řetězce, nikoli obsah.

• Hyphens off – Odstraní pomlčky: místo 550e8400-e29b-41d4-a716-446655440000 dostanete 550e8400e29b41d4a716446655440000 (32 znaků). Tento tvar se hodí do URL, HTTP hlaviček nebo do systémů, kde pomlčky vadí (např. některé databázové názvy sloupců). Nevýhoda: horší čitelnost pro člověka.
• Uppercase on – Hexadecimální písmena a–f se zobrazí jako A–F: 550E8400-E29B-41D4-A716-446655440000. To je užitečné při práci s protokoly nebo systémy, které očekávají velká písmena (např. některé REST API specifikace). Standard RFC 4122 je case‑insensitive, takže obě varianty jsou formálně stejné.

Kombinace obou přepínačů poskytuje všechny čtyři možné varianty. Generování se spouští automaticky při každé změně – není třeba mačkat tlačítko "Generovat".

Časté otázky (FAQ)

Je možné, že se dvě vygenerovaná UUID v4 shodnou? Ano, teoreticky možné to je – ale pravděpodobnost je při 122 bitech entropie tak nízká, že při miliardě identifikátorů je šance na kolizi menší než 10^-18. V praxi se to nestane.

Proč se UUID v4 nedoporučují jako primární klíče v databázích? Protože jsou náhodně rozložené – při vkládání nových záznamů dochází k fragmentaci B‑stromového indexu, což snižuje rychlost zápisu a zvyšuje paměťovou náročnost indexu.

Dají se z UUID v4 vyčíst nějaké informace o čase nebo zařízení? Ne. UUID v4 neobsahuje MAC adresu, časové razítko ani sekvenci. Je to čistě náhodné číslo.

Jaký je rozdíl mezi UUID v4 a v7? UUID v4 je zcela náhodné; UUID v7 kombinuje časové razítko (v milisekundách) s náhodnou částí. Díky tomu je v7 řaditelná podle času a nefragmentuje B‑stromy.

Proč bych chtěl vypnout pomlčky nebo zapnout velká písmena? Bez pomlček je UUID kratší a vhodnější do URL. Velká písmena vyžadují některé systémy (např. AWS, některé JWT implementace). Obojí je jen kosmetická úprava.

Je bezpečné generovat UUID v4 v prohlížeči na veřejné webové stránce? Ano. Veškeré generování probíhá lokálně pomocí crypto.randomUUID() – žádná data neopouštějí váš počítač. Stránka neodesílá identifikátory na server.