Generátor UUID v7: identifikátory s časovým razítkem přímo ve vašem prohlížeči
Struktura UUID v7
UUID v7 je 36znakový identifikátor ve standardizovaném textovém tvaru xxxxxxxx-xxxx-7xxx-xxxx-xxxxxxxxxxxx. Prvních 48 bitů (12 hexadecimálních znaků) tvoří Unixové milisekundové časové razítko – počet milisekund od 1. ledna 1970 00:00 UTC. Zbývajících 80 bitů je náhodných. Celkem jde o 128 bitů, z nichž verze (7) je zakódována do 4 bitů na pozici 13. šestnáctkového řetězce.
Pro představu: pokud je aktuální čas 1. června 2025 12:34:56,789 UTC, odpovídá to přibližně 1 748 999 696 789 milisekundám Unixového času. V hexadecimálním zápisu to bude 196F1E4F3D5 – těchto 12 znaků tvoří začátek UUID v7. Zbytek je náhodný, takže výsledný identifikátor může vypadat například jako 196f1e4f-3d5a-7b8c-9d0e-1f2a3b4c5d6e.
Rozdíl oproti běžnému UUID v4 je zásadní: zatímco v4 je celé náhodné, v7 obsahuje explicitní časovou složku. To umožňuje, aby identifikátory vzniklé dříve měly v lexikografickém uspořádání nižší hodnotu než identifikátory novější. Funguje to jako přirozené řazení podle času vzniku.
Proč záleží na časovém řazení
Databázové indexy, zejména B‑stromy (B‑trees), trpí při vkládání náhodných hodnot. Každý nový záznam s UUID v4 padne do jiné části indexu, což způsobuje fragmentaci a časté přestavby stránek. Výsledkem je pomalejší zápis, vyšší spotřeba místa a neefektivní využití cache.
UUID v7 tento problém řeší: protože první bajty obsahují časové razítko, nové záznamy se v indexu hromadí na konci. B‑strom může přidávat listy sekvenčně, aniž by musel často rozdělovat stránky nebo přeuspořádávat data. U tabulek s primárním klíčem typu UUID v7 může být rychlost vkládání až o 30–50 % vyšší než u UUID v4, v závislosti na velikosti tabulky a konfiguraci databáze.
Důležité upozornění: UUID v7 nezaručuje striktní řazení pro identifikátory vygenerované v téže milisekundě. V rámci jedné milisekundy se pořadí řídí náhodnou složkou. Pro aplikace, které vyžadují přesné sekvenční pořadí i v rámci milisekundy, je třeba použít jiný formát – například ULID s explicitním náhodným komponentem, nebo přidat vlastní počítadlo.
UUID v7 versus další formáty
Porovnání nejběžnějších identifikátorů vychází z jejich struktury a vlastností:
| Formát | Délka | Časové razítko | Náhodná část | Zaručené pořadí v rámci ms |
|---|---|---|---|---|
| UUID v4 | 36 znaků | ne | 122 bitů | není relevantní |
| UUID v7 | 36 znaků | 48 bitů (ms) | 74 bitů | ne |
| ULID | 26 znaků | 48 bitů (ms) | 80 bitů | ne |
| NanoID | 21 znaků (výchozí) | ne | 126 bitů (při 21 znacích) | není relevantní |
| Snowflake | 19 číslic | 41 bitů (ms) | 22 bitů | ano – pomocí sekvenčního čísla |
Klíčový rozdíl mezi UUID v7 a ULIDem je v textové reprezentaci: UUID v7 používá standardní 36znakový formát s pomlčkami, ULID je kratší (26 znaků) a používá Crockfordovo base32 kódování. Oba formáty jsou časově řaditelné, ale stejně jako UUID v7 negarantují pořadí v rámci jedné milisekundy. Snowflake od Twitteru (nyní X) toto řeší přidáním sekvenčního čísla, je však závislý na centrálním generátoru a není vhodný pro distribuované prostředí bez koordinace.
Z hlediska kryptografické neuhodnutelnosti poskytuje UUID v7 74 bitů náhody, což je dostatečné pro prakticky všechny aplikace. Pro srovnání: UUID v4 poskytuje 122 bitů náhody, tedy o 48 bitů více. Pokud útočník zná časové razítko s přesností na milisekundu, musí uhodnout 2^74 možností – při současném výpočetním výkonu nereálné.
Nastavení generátoru: jaké možnosti ovlivňují výstup
Nástroj na stránce uuid-v7-generator nabízí tři parametrizovatelné volby:
- Počet identifikátorů: celé číslo od 1 do 100 včetně. Po změně se všechny identifikátory okamžitě regenerují.
- Velká písmena (uppercase): přepínač, který změní hexadecimální písmena (a–f) na velká (A–F). Standardní UUID se běžně zapisují malými písmeny, některé systémy však vyžadují velká – například starší verze Microsoft SQL Serveru nebo některé nástroje pro logování.
- Pomlčky (hyphens): přepínač odstraní z výstupu pomlčky. Výsledkem je 32znakový hexadecimální řetězec, který je kompaktnější, ale není kompatibilní s RFC 9562. Některé systémy ukládají UUID jako binárních 16 bajtů, pomlčky jsou pak pouze formátovací záležitost.
Při každé změně kteréhokoli parametru se všechny identifikátory vygenerují znovu s novými náhodnými hodnotami. Časová razítka odpovídají okamžiku kliknutí nebo stisku klávesy – budou se tedy lišit o několik milisekund až desítek milisekund v závislosti na rychlosti interakce.
Lokální generování v prohlížeči
Všechny UUID v7 vznikají přímo v prohlížeči uživatele. Nástroj používá kryptograficky bezpečné rozhraní crypto.getRandomValues(), které je dostupné ve všech moderních prohlížečích. Žádný údaj – ani časové razítko, ani náhodné hodnoty – není odeslán na server BroBroGo.
Tento přístup má dva praktické důsledky:
- Ochrana soukromí: časová razítka by mohla prozradit, kdy uživatel nástroj používá, a náhodné hodnoty by teoreticky mohly být zneužity pro fingerprinting. Lokální generování tato rizika eliminuje.
- Žádná závislost na serveru: nástroj funguje offline (po prvním načtení stránky) a není ovlivněn výpadky sítě nebo latencí. Generování probíhá v milisekundách bez ohledu na připojení.
V praxi to znamená, že pokud vygenerujete 100 identifikátorů, všech 100 vznikne v časovém rozpětí několika milisekund až desítek milisekund. Jejich časová razítka budou velmi blízká, ale nebudou striktně vzestupná – některé identifikátory s pozdějším časovým razítkem mohou být zobrazeny dříve, pokud byly vygenerovány o několik málo milisekund dříve. To je důsledek toho, že náhodná složka převažuje nad jemnými rozdíly v čase.
Časté chyby a očekávání
Mnoho vývojářů očekává, že UUID v7 budou pevně seřazena vzestupně i v rámci jedné milisekundy. To není pravda. Náhodná složka (74 bitů) je natolik dominantní, že při generování více identifikátorů v téže milisekundě bude jejich pořadí náhodné. Pokud potřebujete sekvenční číslování v rámci milisekundy, musíte implementovat vlastní počítadlo – například pomocí atomických operací nebo databázového auto-incrementu.
Další častý omyl se týká kolizí. Při 74 bitech náhody je pravděpodobnost kolize mezi dvěma identifikátory vygenerovanými v téže milisekundě zhruba 1 ku 2^74. Pro miliardu identifikátorů za sekundu (což je nereálné množství) by pravděpodobnost kolize byla stále extrémně nízká. V praxi je riziko zanedbatelné.
Třetí častá chyba je mylná představa, že UUID v7 je možné použít jako primární klíč v MySQL InnoDB a automaticky získat stejné výhody jako u auto-increment celých čísel. Ano, indexová lokalita je výrazně lepší než u UUID v4, ale 36znakový řetězec zabírá více místa než 4bajtové celé číslo. Kompromis je: lepší výkon vkládání a menší fragmentace než u v4, ale horší využití cache a větší indexy než u celočíselných klíčů.
FAQ
Proč není UUID v7 striktně seřazeno podle času? Protože první 48 bitů je časové razítko s přesností na milisekundu. Všechny identifikátory vygenerované v téže milisekundě mají stejný začátek – jejich pořadí určuje až náhodná složka. Řazení je proto deterministické pouze na úrovni milisekund, ne uvnitř nich.
Jaké jsou výhody pomlček v UUID? Pomlčky rozdělují 32 hexadecimálních znaků do pěti skupin (8-4-4-4-12) podle RFC 9562. Usnadňují čtení a manuální kontrolu. Při ukládání do databáze se obvykle ukládá binární reprezentace (16 bajtů) bez pomlček – pomlčky jsou pouze formátovací záležitost.
Je možné použít UUID v7 pro kryptografické účely?
Ne. UUID v7 není navrženo jako kryptografický primitiv. Náhodná složka je sice generována pomocí crypto.getRandomValues(), ale samotný identifikátor neposkytuje žádné záruky autenticity nebo integrity. Pro šifrování, podpisy nebo tokeny používejte specializované nástroje.
Co se stane, když vygeneruji 100 identifikátorů najednou? Všechny identifikátory obdrží časové razítko odpovídající okamžiku stisku tlačítka nebo změny parametru. Pokud je generování dokončeno během několika milisekund, budou mít všechna časová razítka velmi blízká, ale ne nutně stejná – některá se mohou lišit o 1–2 ms kvůli prodlevě mezi jednotlivými iteracemi smyčky.
Může se UUID v7 opakovat? Teoreticky ano – pokud v téže milisekundě vzniknou shodné náhodné hodnoty. Pravděpodobnost je však 2^(-74), tedy zhruba 1 ku 10^22. Pro srovnání: pravděpodobnost, že vás během vteřiny zasáhne meteorit, je odhadována na 1 ku 10^16. V praxi ke kolizím nedochází.
Jaký je rozdíl mezi UUID v7 a ULIDem pro databázové indexy? Oba formáty výrazně zlepšují indexovou lokalitu oproti UUID v4. ULID je kratší (26 znaků oproti 36) a negeneruje pomlčky, což může ušetřit místo v indexu. UUID v7 je naopak standardizován v RFC 9562 a je široce podporován knihovnami v jazycích jako Python, Java nebo JavaScript. Volba závisí na kompatibilitě s existujícími nástroji a osobních preferencích.