A véletlen UUIDv4 alkalmas lehet több rendszerben keletkező rekordok azonosítására, de a nagyon kicsi elméleti ütközési esély nem teszi feleslegessé az adatbázis egyediségi szabályát. A gyakorlati hiba származhat másolásból, importból vagy rossz generálásból is.
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.
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.