UUID v7 generátor

UUID v7 generátor: időbélyeg-alapú egyedi azonosítók böngészőben

Az UUID v7 a 128 bites egyedi azonosítók családjának legújabb tagja, amely egy 48 bites Unix milliszekundumos időbélyeget kombinál véletlenszerű bitekkel. Ennek a generátornak a használata annyiból áll, hogy megad egy darabszámot 1 és 100 között, néhány megjelenítési beállítást, és az oldal azonnal visszaadja a kért számú UUID v7 azonosítót – időrendben rendezhető, 36 karakter hosszú sztringeket, amelyeket egyenként vagy egyszerre is a vágólapra másolhat.

Ami ezt az oldalt igazán mássá teszi, az az, hogy a UUID v7 beágyazza a 48 bites Unix milliszekundumos időbélyeget az azonosító elejére, majd ezt véletlenszerűség követi. Ez azt eredményezi, hogy az azonosítók kronológiailag rendezhetők a létrehozás ideje szerint – ezzel orvosolva az UUID v4 index-lokalitási problémáját –, miközben kriptográfiai szempontból kitalálhatatlanok maradnak. A testvére formátumokkal (v4, ULID, NanoID) ellentétben a v7 egy 36 karakteres sztring, amelynek első karakterei az időbélyeget hordozzák; nem garantál szigorú rendezést az ugyanabban a milliszekundumban generált azonosítók között.

A UUID v7 szerkezete és működése

A UUID v7 formátum a 128 bitet a következőképpen osztja fel:

A 36 karakteres szöveges reprezentáció a xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx mintát követi, ahol az első 8 karakter – a kötőjelek elhagyása esetén az első 12 hexadecimális számjegy – az időbélyeget kódolja. Ez teszi lehetővé, hogy az azonosítók születési sorrendben rendezhetők legyenek: két, különböző milliszekundumban generált v7-es string összehasonlításakor a korábban keletkezett mindig kisebb lesz.

A 48 bites időbélyeg körülbelül 8920 évig elegendő, mielőtt túlcsordulna. Ez a gyakorlatban bőven meghaladja bármely rendszer várható élettartamát. A fennmaradó 74 bit (62 random + a verziószámot és alváltozatot kódoló bitek) 2^37 körüli azonosítót tesz lehetővé milliszekundumonként, ami bőven elég a párhuzamos generáláshoz is.

Időalapú rendezés és adatbázis-indexek

Az UUID v4 teljesen véletlenszerű eloszlása jól ismert problémát okoz a B-fa indexekben, különösen az adatbázisok elsődleges kulcsaként használva. Az új sorok beszúrása szinte véletlenszerű helyre történik a táblában, ami gyakori oldalhasadásokhoz, az indexgyökér-frissítésekhez és a buffer poolban lévő lapok folyamatos cseréléséhez vezet. Ez a teljesítmény akár 80%-os romlását is okozhatja nagy írási terhelés mellett.

Az UUID v7 időbélyeg-kezdete ezt a problémát hivatott orvosolni: az új azonosítók egymás után, sorban keletkeznek, így az indexbe való beszúrás szinte mindig a B-fa jobb szélén történik. Ez minimálisra csökkenti az index átrendeződését, és javítja a gyorsítótár kihasználtságát, mivel a nemrég beszúrt sorok fizikailag is közel vannak egymáshoz.

Azonban fontos korlátozást kell megjegyezni: az UUID v7 nem garantál szigorú sorrendiséget az ugyanabban a milliszekundumban generált azonosítók között. Ha több ezer rekordot szúr be egyetlen ezredmásodpercen belül, a sorrendjük véletlenszerű lesz. Ez a tervezési döntés lehetővé teszi a párhuzamos generálást anélkül, hogy központi koordinációra lenne szükség, ami elengedhetetlen a elosztott rendszerekben.

UUID v4 versus UUID v7

A két formátum közötti választás gyakorlati hatással van az alkalmazás méretezhetőségére. Íme a legfontosabb különbségek:

• UUID v4 – 122 bit véletlenszerűség, nincs időbélyeg. Kiváló kitalálhatatlanság, de káros az index teljesítményre.
• UUID v7 – 48 bit időbélyeg + 74 bit véletlenszerűség. Időrendi rendezhetőség, kisebb eséllyel okoz indexfragmentációt, de a véletlen bitszám csökkenése miatt elméletileg kisebb a kitalálhatatlansági távolság.

A gyakorlatban mindkettő elegendő kriptográfiai erősséget nyújt a legtöbb alkalmazáshoz; a különbség a 74 vs 122 véletlen bit között csak elméleti jelentőségű, mivel a 74 bit még mindig 2^74 lehetőséget jelent, ami gyakorlatilag kimeríthetetlen.

Egy másik fontos különbség: az UUID v4 hipotetikus esélye a ütközésre 2^122-hez 1, ami lényegében nulla; az UUID v7 esetében ez 2^74-hez 1 ugyanabban a milliszekundumban. Mivel az időbélyeg különböző milliszekundumokban elválasztja a generálásokat, a tényleges ütközési valószínűség sokkal kisebb.

Böngészőbeli generálás és adatvédelem

A generálás teljes egészében a böngészőben történik, a crypto.getRandomValues() API használatával, amely erős kriptográfiai véletlenszám-generátort biztosít. Semmilyen adat nem kerül a BroBroGo szervereire – az azonosítók helyben, a felhasználó gépén készülnek.

Ennek a megközelítésnek több előnye van:

• Adatvédelem: a generált azonosítók soha nem hagyják el a böngészőt, így nem rögzíthetők, nem naplózhatók és nem használhatók fel a felhasználó tevékenységének nyomon követésére.
• Sebesség: nincs hálózati késleltetés; a generálás szinte azonnali, akár 100 azonosító esetén is.
• Offline működés: az oldal betöltése után internetkapcsolat nélkül is használható.

A crypto.getRandomValues() a modern böngészőkben elérhető, és a kriptográfiai szempontból erős véletlenszám-generátorokra támaszkodik, nem a gyengébb Math.random() függvényre. Ez garantálja, hogy a véletlen bitek valóban kitalálhatatlanok.

Formátum-beállítások: kötőjelek, kis- és nagybetűk

A generátor lehetőséget ad a formátum módosítására:

• Kis- és nagybetű: alapértelmezés szerint a UUID kisbetűs, de a "Nagybetűs" kapcsolóval a teljes 36 karakteres sztring nagybetűsre váltható. Ez befolyásolja a tárolást: a nagybetűs azonosítók emberileg könnyebben olvashatók, de a kisbetűsek általában szabványosabbak.
• Kötőjelek elhagyása: ha a felhasználó kikapcsolja a kötőjeleket, a sztring 32 karakteressé válik (36 helyett). Ez gyakran hasznos, ha az azonosítót URL-be vagy más, rövidített formátumot igénylő környezetbe kell beilleszteni.

Érdekes hatás: a "kötőjelek nélküli, nagybetűs" beállítás eredménye olyan 32 karakteres, csupa hexadecimális számjegyből álló sztring, amely emlékeztet a megszokott UUID formátumra, de nem tartalmaz elválasztójeleket. Ezt a formátumot néha "UUID kompakt" néven emlegetik, bár a hivatalos szabvány megköveteli a kötőjeleket.

Használati esetek és gyakorlati tanácsok

Az UUID v7 elsődleges célközönsége a fejlesztők és adatbázis-adminisztrátorok, akik elosztott rendszereket építenek. A leggyakoribb alkalmazási területek:

• Eseményforrás (event sourcing): az események időrendi feldolgozásához használt azonosítók. Az UUID v7 időbélyeg-alapú rendezése lehetővé teszi, hogy az események sorrendje megegyezzen az azonosítók sorrendjével.
• Auditnaplók: ahol a naplóbejegyzések időrendi sorrendjét fontos megőrizni, de nem áll rendelkezésre központi időbélyeg.
• Üzenetkezelő rendszerek: üzenetek azonosítása, ahol a sorrendiség fontos, de a párhuzamos feldolgozás is szükséges.
• Adatbázis-elsődleges kulcsok: nagy terhelésű (1000+ beszúrás/másodperc) rendszerekben, ahol az UUID v4 indexfragmentációja már érezhető.

Gyakorlati tanácsok:

• Ha 100-nál több azonosítót kell generálnia egyszerre, futtassa le többször a generálást, mivel az oldal egyszerre legfeljebb 100-at állít elő.
• Ha a rendezés fontos, ne támaszkodjon arra, hogy az ugyanabban a milliszekundumban generált azonosítók sorrendje megegyezik a generálás sorrendjével. Terjessze ki ezt a logikát másodlagos időbélyeggel (pl. nanosecundum) vagy sorszámmal.
• Tesztelje, hogy az adatbázisa támogatja-e az UUID v7 natív típusaként. Egyes adatbázisok (pl. modern PostgreSQL verziók) közvetlenül kezelik a uuid típust, mások sztringként tárolják, ami hatással van a rendezésre és az indexelésre.

GYIK – gyakran ismételt kérdések

1. Mi a különbség az UUID v7 és az ULID között? Mindkettő időbélyeget használ a rendezéshez, de az ULID 26 karakteres, csupa nagybetűs alfanumerikus sztring, míg a UUID v7 36 karakteres hexaformátumú. Az ULID időbélyege 10 karakterre van kódolva (Crockford Base32), a UUID v7-é 12 hexadecimális számjegyre. A véletlen rész is különbözik: ULID 80 bit, UUID v7 74 bit random adatot tartalmaz.

2. Mennyire biztonságos a crypto.getRandomValues()? A crypto.getRandomValues() a böngésző beépített kriptográfiai véletlenszám-generátorát használja, amely az operációs rendszer entrópiaforrásaira támaszkodik. Ez ugyanaz a forrás, mint amit a TLS-kapcsolatok kulcsgenerálásához is használnak. Praktikusan kimeríthetetlen, és megfelel a legmagasabb biztonsági követelményeknek.

3. Miért nem garantál szigorú rendezést az UUID v7 ugyanabban a milliszekundumban? Mert a 48 bites időbélyeg minden generáláskor az éppen aktuális milliszekundumot képviseli. Ha két generálás ugyanabban a milliszekundumban történik, az időbélyeg azonos lesz, és a sorrendet a 74 véletlen bit dönti el, ami véletlenszerűen oszlik el. Ez a tulajdonság lehetővé teszi a párhuzamos generálást, de fel kell készülni rá, hogy a rendezés nem lesz teljes.

4. Hogyan lehet a generált UUID-kat másolni? Két módon: Kattintson egy adott azonosítóra – az egy másolja azt a vágólapra. Vagy kattintson a "Minden másolása" gombra – ez az összes generált azonosítót egyben másolja a vágólapra, vesszőkkel vagy sortörésekkel elválasztva (az oldal beállításaitól függően). A "Mindet másolva!" felirat jelenik meg, ha sikeres volt a másolás.

5. Milyen esetekben érdemes használni az UUID v7-t az UUID v4 helyett? Amikor az azonosítók időrendi rendezése előnyt jelent, különösen adatbázis-indexeknél. Ha nagy mennyiségű beszúrás várható (több ezer/másodperc), és a B-fa indexek teljesítménye kritikus, a v7 jelentős javulást hozhat. Egyszerű alkalmazásokban, ahol a rekordok száma kicsi (pár ezer), a v4 továbbra is tökéletesen megfelelő.

6. Van-e korlátja a generálható azonosítók számának? Az oldal egyszerre 1 és 100 közötti darabszámot enged meg. Többszöri generálással azonban korlátlan számú azonosító előállítható, mivel a böngésző entrópiája gyakorlatilag kimeríthetetlen. A 100-as korlát pusztán használhatósági okokból létezik – a hosszú lista kezelése a vágólapon és a képernyőn kényelmetlen lenne.