UUID v4 vs v7: melyik egyedi azonosítót válasszuk?

Az UUID egy 128 bites egyedi azonosító központi koordináció nélkül. A 4-es verzió, teljesen véletlenszerű, évek óta uralkodik. A 7-es verzió, az újabb (RFC 9562, 2024), egy időbélyeget tartalmaz az elején, hogy időrendezett azonosítókat állítson elő. Ez a látszólag ártalmatlan különbség gyökeresen megváltoztatja a teljesítményt az adatbázisban. Íme, melyiket válasszuk.

Mi az az UUID?

Az UUID (Universally Unique Identifier) egy 128 bites szám, amelyet 32 hexadecimális karakter képvisel öt blokkba csoportosítva, például 550e8400-e29b-41d4-a716-446655440000. Létezésének oka: egyedi azonosító létrehozása anélkül, hogy egy központi hatóságtól kérnénk, ami ideálissá teszi elosztott rendszerekhez. Generálhat ilyeneket a UUID generátorunkkal.

Több verzió létezik; ma a legrelevánsabbak a rekordkulcsokhoz a v4 (véletlenszerű) és a v7 (időrendezett).

UUID v4 (véletlenszerű)

Az UUID v4 122 véletlenszerű bitből áll (a többi a verziót és a variánst kódolja). Az ütközés valószínűsége olyan alacsony, hogy a gyakorlatban elhanyagolható. Ez az alapértelmezett verzió a legtöbb nyelvben és könyvtárban.

• Kiszámíthatatlan: tökéletes tokenekhez vagy nyilvános azonosítókhoz, amelyeket nem akarunk kitalálhatóvá tenni
• Nincs információszivárgás: nem fedi fel sem a létrehozás dátumát, sem a sorrendjét
• Hátrány: teljesen rendezetlen, ami megviseli az adatbázis-indexeket

UUID v7 (időrendezett)

Az UUID v7 egy Unix időbélyeget helyez ezredmásodpercben az első 48 bitjére, amelyet véletlenszerű bitek követnek. Két különböző pillanatban generált UUID v7 tehát a létrehozásuk sorrendjében rendeződik, miközben egyedi és gyakorlatilag kitalálhatatlan marad.

• Rendezhető: a lexikografikus sorrend megfelel a kronologikus sorrendnek
• Indexbarát: a beszúrások az index végén történnek, mint egy auto-increment esetén
• Ellentételezés: felfedi a létrehozás pillanatát, ami nemkívánatos lehet egy nyilvános azonosítónál

Összehasonlító táblázat

Hatás az adatbázisokra

Ez a téma lényege. A relációs adatbázisok az indexeiket B-fákban (B-tree) tárolják. A véletlenszerű kulcsok (v4) beszúrása szétszórja az írásokat az indexben, fragmentációt, oldalfelosztásokat és kevésbé hatékony gyorsítótárat okozva. Nagy mennyiségeken a beszúrási teljesítmény jelentősen romlik.

A rendezett kulcsok (v7) mindig az index végére szúródnak be, mint egy auto-increment azonosító. Gyors beszúrásokat, jobb lokalitást és kompaktabb indexet kapunk. Ez különösen szembetűnő egy elsődleges kulccsal InnoDB-ben (MySQL), ahol az elsődleges kulcs határozza meg a sorok fizikai sorrendjét.

Mikor melyiket válasszuk

Válassza az UUID v4-et, ha

• Az azonosító nyilvánosan ki van téve és semmit sem szabad felfednie
• Tokeneket, megosztási linkeket, titkokat generál
• A sorrend és a létrehozás dátuma nem lehet kitalálható
• Maximális kompatibilitást szeretne a meglévővel

Válassza az UUID v7-et, ha

• Az UUID elsődleges kulcsként szolgál egy adatbázisban
• A beszúrások mennyisége magas és az index teljesítménye számít
• Létrehozási sorrend szerint szeretne rendezni dedikált oszlop nélkül
• A létrehozás pillanatának felfedése nem probléma

Ajánlás

Egy adatbázis elsődleges kulcsához mostantól részesítse előnyben az UUID v7-et: megtartja az UUID elosztott egyediségét, miközben elkerüli a v4 index-büntetését. Tartsa meg az UUID v4-et a nyilvános azonosítókhoz, tokenekhez és titkokhoz, ahol a teljes kiszámíthatatlanság és az időbeli szivárgás hiánya az elsődleges.

Mindazonáltal ellenőrizze a v7 támogatását a nyelvében és az ORM-jében: az RFC friss, de az elterjedtsége gyorsan halad.

Gyakori kérdések