Az UUIDv4 ütközési számítását csak a megőrzött véletlen bitek és a generálási feltételek ismeretében használd. A teljes azonosító megjelenítését át lehet alakítani, de a tartalmának csonkolása már más állapotteret ad. Az adatbázisban az azonosító- és üzleti egyediség külön szabályt igényel.
Az UUID-generátor kipróbálásánál először nézd meg, mely verziót állítod elő. A cikk kizárólag a szabványos, megfelelő véletlenforrással létrehozott v4 változat idealizált ütközési modelljét tárgyalja. Más verzióra ugyanaz a számítás változtatás nélkül nem vihető át.
Hány véletlen bit marad?
Az UUID teljes hossza 128 bit. A v4 verzió- és variánsmezői rögzített biteket foglalnak el, így a véletlen rész 122 bit. Az idealizált lehetséges véletlenértékek száma ezért 2¹²², hozzávetőleg 5,3169 × 10³⁶.
A szövegesen látható kötőjelek nem növelik az állapotteret, és a kis- vagy nagybetűs hexadecimális megjelenítés sem jelent új véletlen adatot. Az azonosító szöveghossza és a benne lévő véletlen bitek száma külön fogalom.
A párok számából indulunk
Ha n azonosítót hozunk létre, az összehasonlítható párok száma n × (n − 1) / 2. Egy pár idealizált egyezési esélye 1 / 2¹²². Kis teljes valószínűségnél az ütközési esély közelítése:
p ≈ n × (n − 1) / (2 × 2¹²²).
Egymillió generált azonosítónál a közelítés körülbelül 9,404 × 10⁻²⁶. Egymilliárdnál körülbelül 9,404 × 10⁻²⁰. Ezek dimenzió nélküli valószínűségek; százalékos alakhoz százzal kell szorozni.
A modell egyenletes, egymástól független generálást feltételez. Nem ad pontossági ígéretet bármilyen, UUID-alakú karakterláncot készítő programra. Egy hibásan újraindított vagy kis állapotterű generátor nagyságrendekkel rosszabb helyzetet teremthet.
Elméleti ütközés és másolási hiba
Egy importfájlba véletlenül kétszer bemásolt UUID nem ritka véletlen ütközés. Ugyanaz az adat két példányban került a rendszerbe. Ha az import új rekord helyett felülírja a régit, a hiba adatvesztéshez vezethet, még tökéletes generátor mellett is.
Tegyük fel, hogy egy 100 000 soros import 99 998 különböző azonosítót tartalmaz. A két többletelőfordulást ki kell vizsgálni. Lehet két kettőzött rekord vagy egy háromszor szereplő azonosító. A darabszám eltérését a kapcsolódó adatok összevetése oldja fel.
Az egyedi adatbázis-korlát ezért a program szerződésének része. Sikertelen beszúrásnál a rendszer ne hallgassa el a problémát, és ne írjon felül másik rekordot pusztán az azonosító egyezése miatt.
Azonosító és üzleti egyediség
Két külön UUID alatt ugyanaz a számla vagy ugyanaz a külső rendelés is bekerülhet. A technikai kulcs egyedisége nem akadályozza meg az üzleti duplikációt. Ha a külső rendelésazonosítónak is egyedinek kell lennie, arra külön szabály szükséges.
Érdemes megnevezni a rendszerben a belső rekordkulcsot, a külső azonosítót és az üzleti duplikáció feltételét. Ezek együtt adják az ellenőrizhető adatmodellt, egy véletlen kulcs önmagában nem helyettesíti őket.
Hozzáférésvédelem
A nehezen kitalálható rekordazonosító nem jogosultságellenőrzés. Egy felhasználó kérésénél a szervernek meg kell vizsgálnia, hogy az adott rekordhoz hozzáférhet-e. Az UUID megjelenhet naplóban, megosztott linkben vagy böngészőelőzményben.
Jelszavak, munkamenetkulcsok és egyszer használatos hozzáférési tokenek külön biztonsági tervezést igényelnek. A jelen cikk ütközési számítása ezek megfelelőségéről nem ad értékelést.
A rövidítés elveszítheti a nagy állapottér előnyét
Egymillió független, egyenletesen véletlen, teljes UUIDv4 közelítő ütközési esélye a korábbi számítás szerint 9,404 × 10⁻²⁶. Hasonlíts ehhez egy külön, idealizált azonosítórendszert, amely csak 64 egyenletes véletlen bitet tart meg. Ugyanannyi azonosítónál a képlet nevezőjében ekkor 2⁶⁴ szerepel, és p ≈ 2,711 × 10⁻⁸ adódik.
A két közelítés aránya 2¹²² / 2⁶⁴ = 2⁵⁸, közel 2,882 × 10¹⁷. A 64 bites esetben is kis számot kaptunk, de a teljes v4-re számolt kockázatot már nem használhatjuk rá. Egy UUID első néhány karakterének levágása ráadásul rögzített verzióbiteket is megtarthat, ezért a megmaradt karakterekből a véletlenbitek száma külön vizsgálandó.
A kötőjelek elhagyása ezzel szemben az összes hexadecimális számjegy megőrzése mellett csak megjelenítési változás. Ha rövid feliratot szeretnél, a teljes kulcsot őrizd meg a háttérben, és a felirat egyezését ne tekintsd rekordazonosságnak. Importnál továbbra is ellenőrizd a teljes kulcsot és az üzleti azonosítót; a fenti képlet a másolási hibákat nem modellezi.
Gyakori kérdések
A v4-ben minden bit véletlen?
A szabványos változatban 122 véletlen bit marad. A verzió és a variáns egyes bitjei rögzítettek.
A nagyon kicsi esély miatt elhagyható az egyedi index?
Az index a véletlen ütközés mellett import- és programhibákat is megfoghat. Az adatok épségét érdemes külön adatbázis-szabállyal védeni.
Egy új UUID biztosan új üzleti rekordot jelent?
Nem bizonyítja. Azonos ügylethez több technikai azonosító is keletkezhet, ezért üzleti egyezésvizsgálat szükséges.
Módszertani forrás
IETF RFC 9562 – UUID-azonosítók
Záró tudáspróba
Válassz kérdésenként egy választ, és jegyezd fel a betűjelét. Minden helyes válasz 1 pont; a hibás, kihagyott vagy több betűvel jelölt válasz 0 pont. Legfeljebb 3 pontot szerezhetsz. A megoldókulcsot a válaszadás után olvasd el.
1. Eltávolítod a kötőjeleket, de minden hexadecimális számjegyet megtartasz. Csökken a v4 véletlen állapottere?
- A) Nem, a rögzített elválasztók nem hordoztak véletlen bitet.
- B) Igen, mert rövidebb a szöveg.
- C) Igen, pontosan a felére.
2. Csak 64 egyenletes véletlen bitet használsz. Melyik nevező tartozik a kis valószínűségű közelítéshez?
- A) 2 × 2⁶⁴
- B) 2 × 2¹²²
- C) 64 × 122
3. Két külön teljes UUID alatt ugyanaz a külső rendelés szerepel. Mi ellenőrzi ezt?
- A) A kötőjelek száma.
- B) A külső rendelésre vonatkozó üzleti egyediségi szabály.
- C) Csak a v4 verziómező.
Megoldókulcs és értelmezés
1. A. A kötőjelek formázási jelek. Az összes azonosítóbit megmarad.
2. A. A lehetséges állapotok száma az új modellben 2⁶⁴. A párok számából származó képlet ehhez igazodik.
3. B. A technikai kulcsok különböznek, ezért a külső ügylet azonosítóját vagy megfelelő üzleti feltételét is vizsgálni kell.
0–1 pont: Nézd át, mi számít formázási változtatásnak és mi csökkenti a véletlen állapotteret; utána ismételd át az üzleti egyediség példáját.
2 pont: A hibás vagy kihagyott válasz magyarázata alapján keresd vissza a kapcsolódó számítást, majd oldd meg újra azt a kérdést.
3 pont: A három feladatban helyesen alkalmaztad a cikk összefüggéseit. Ellenőrizd a tárolás és import minden lépésén, hogy megmarad-e a teljes azonosító és érvényesül-e a szükséges üzleti kulcsszabály. A rövid próba csak ezeket a tanulságokat ellenőrzi.