A „használjunk UUID-t” döntés önmagában nem teljes technikai választás. A szabvány több verziót definiál, amelyek más forrásból építik fel a 128 bites értéket, ezért más tulajdonságokat adnak. Van, amelyik véletlen generálásra optimalizál, van, amelyik ugyanabból a névből mindig ugyanazt az azonosítót készíti, és van, amelyik időrendben közel növekvő kulcsot ad. A megfelelő verzió kiválasztásához előbb azt kell megnevezni, mire használjuk az ID-t.

A UUIDv4 jó általános alapérték

A 4-es verzió nagy részben véletlen bitekből áll. Nem igényel központi állapotot, nem tesz közzé időbélyeget vagy hálózati címet, és szinte minden modern platform támogatja. API-erőforrásokhoz, kliensoldali objektumlétrehozáshoz és elosztott rendszerek általános azonosítóihoz ezért gyakran ez a legegyszerűbb, védhető választás.

A biztonság azonban a random forrás minőségétől függ. A nyelvi standard könyvtár UUID-függvénye rendszerint megfelelő, egy saját Math.random()-alapú megoldás viszont kevés entrópiát vagy ismétlődő sorozatot adhat. A generálást nem érdemes kézzel újraimplementálni csak azért, mert a formátum egyszerűnek látszik.

A teljesen véletlen kulcs adatbázisban költséges lehet

Egy B-tree index a rendezett kulcsokkal dolgozik a leghatékonyabban. A véletlen UUID-k minden beszúrásnál más lapra kerülhetnek, page splitet, rosszabb cache-lokalitást és nagyobb indexet okozva. Kis vagy közepes rendszerben ez gyakran nem számít, nagy írási terhelésnél viszont mérhetővé válhat.

A probléma nem indokol automatikusan verzióváltást. Előbb valódi workloadon kell mérni, megfelelő bináris tárolással és adatbázis-beállításokkal. Sok esetben egy belső növekvő fizikai kulcs és egy publikus UUID együtt egyszerűbb, mint az egész doménmodell átalakítása egy optimalizáció kedvéért.

A UUIDv7 időrendezhető modern alternatíva

A 7-es verzió Unix-időn alapuló felső biteket kombinál véletlen komponenssel. Az ugyanabban az időszakban létrejövő értékek közel rendezve érkeznek az indexbe, miközben nincs szükség központi számlálóra. Ez jobb beszúrási lokalitást és idő szerinti alapvető rendezhetőséget adhat.

A „közel rendezett” nem azonos a globális eseménysorrenddel. Két gép órája eltérhet, egy milliszekundumban sok UUID készülhet, és a hálózat felcserélheti az eseményeket. Ha a domén kauzális vagy tranzakciós sorrendet igényel, külön sequence, verziószám vagy broker offset továbbra is szükséges.

Az időkomponens adatvédelmi következmény

Egy időrendezhető azonosítóból megközelítőleg kikövetkeztethető a létrehozás ideje. Ez működési szempontból hasznos, de olyan információt fedhet fel, amelyet a termék nem akart publikálni. Nyilvános URL-ben például következtetni lehet kampányindításra, ügyfélaktivitásra vagy rekordok korára.

A döntés threat modelt igényel. Az időbélyeg önmagában rendszerint nem titok, de más adatokkal kombinálva üzleti mintát mutathat. Ha ez elfogadhatatlan, a véletlen UUID vagy külön publikus token jobb lehet, még akkor is, ha az adatbázis számára kevésbé ideális.

A UUIDv1 történelmi kompromisszumokat hordoz

Az 1-es verzió időbélyeget és node-azonosítót használ. Eredeti formájában ez gyakran hálózati MAC-címből származott, ami eszközinformációt és összekapcsolhatóságot fedhetett fel. Modern implementáció helyettesítheti véletlen node-értékkel, de a formátum örökölt elrendezése adatbázis-rendezéshez sem mindig kényelmes.

Új általános rendszerhez ritkán ez az első választás. Legacy protokoll vagy meglévő adatmodell miatt továbbra is találkozhatunk vele, ezért a parsernek ismernie kell, de új generálási policy bevezetésekor érdemes a v4 vagy v7 tulajdonságait összevetni vele.

A névalapú verzió determinisztikus azonosítót készít

A UUIDv3 és UUIDv5 egy namespace UUID-t és egy nevet hash-el. Ugyanaz a namespace és pontosan ugyanaz a bemenet mindig ugyanazt az eredményt adja. Ez hasznos migrációban, ahol külső stabil kulcsból ismételhetően kell belső UUID-t készíteni, vagy szabványos névtérben szeretnénk azonosítani erőforrásokat.

A normalizálás itt kritikus. A kis- és nagybetű, Unicode-forma, whitespace, URL-kanonizálás vagy e-mail-cím szabályai megváltoztatják a bemenetet és így az UUID-t. A rendszernek byte-szinten dokumentálnia kell, miből készül a név, különben két szolgáltatás látszólag ugyanazt az adatot eltérően azonosítja.

A v3 és v5 hash-algoritmusa nem hitelesít

A 3-as verzió MD5-öt, az 5-ös SHA-1-et használ a név leképezésére. Ezek az algoritmusok digitális aláíráshoz már elavultak, de a UUID itt nem támadásálló bizonyítékot készít, hanem szabványos determinisztikus rövidítést. Ettől függetlenül új tervezésnél a támogatott szabvány és interoperabilitás alapján kell választani.

Egyik névalapú UUID sem bizonyítja, ki adta a nevet, és nem védi a titkos adatot. Ha a bemeneti tér kicsi, egy kívülálló végigpróbálhatja a lehetséges neveket. Titkos vagy személyes érték álnevesítéséhez kulcsolt konstrukció és külön adatvédelmi elemzés szükséges.

A verzióváltás kompatibilitási projekt

Az adatbázis UUID oszlopa több verziót is tárolhat, ezért technikailag könnyű új generátort bekapcsolni. A fogyasztók azonban feltételezhetik, hogy minden érték v4, regexük konkrét verzióbitet ellenőriz, vagy tesztfixture-jük egyetlen alakra épül. A változás előtt fel kell térképezni ezeket a rejtett szerződéseket.

Átmenetben a rendszer elfogadhatja a régi és új verziót, miközben csak az újat generálja. A metrika mutassa a beérkező verziókat, a dokumentáció pedig mondja meg, hogy a kliens opaque azonosítóként kezelje az értéket. A régi rekordokat rendszerint nem kell átírni pusztán az egységesség kedvéért.

A könyvtári támogatás és szabványverzió számít

Nem minden runtime támogatja ugyanazokat az új UUID-verziókat. Harmadik fél csomagjánál ellenőrizni kell a szabványkövetést, a monotonic viselkedést azonos milliszekundumban, a biztonságos random forrást és a hibás rendszeróra kezelését. A népszerű csomagnév önmagában nem elég garancia.

Interoperabilitási teszt generáljon értéket minden résztvevő platformon, majd parse-olja és rendezze a többiben. A verzió- és variánsbitek, a kanonikus string, valamint a bináris byte-sorrend is legyen ismert. Ez különösen fontos, ha adatbázis-specifikus UUID-függvény és alkalmazáskönyvtár egyszerre generál.

A választás a használati mintából következik

Általános, nem rendezett publikus azonosítóhoz a v4 egyszerű és széles körben támogatott. Nagy írási terhelésű adatbázishoz, ahol az időinformáció elfogadható, a v7 előnyös lehet. Stabil név determinisztikus leképezéséhez namespace-alapú verzió illik. Legacy integráció megkövetelhet más formát.

A csapatnak rövid architecture decision recordban érdemes rögzítenie a választást: mi a cél, hol generálódik az érték, milyen könyvtár készíti, mely verziók fogadhatók el és tartalmazhat-e megfigyelhető időt. Így a UUID nem véletlenszerű konvenció lesz, hanem tudatos része az adatmodellnek.

Az ID-t a fogyasztó kezelje opaque értékként

Még időrendezhető verziónál sem célszerű üzleti logikát építeni a string belső bitjeire. A specifikáció fejlődhet, a szolgáltatás később verziót válthat, a külső import pedig más változatot hozhat. Ha a létrehozási idő fontos, külön mezőben, megfelelő időtípussal kell tárolni.

A jó verzióválasztás javíthatja a teljesítményt és az üzemeltetést, de az azonosító elsődleges szerepe változatlan: stabilan megnevezni egy objektumot. A belső szerkezetből kinyerhető mellékes információ nem helyettesíti a domén saját mezőit, jogosultsági szabályait vagy eseménysorrendjét.