Generáljon UUID v4-et, UUID v7-et, ULID-ot és NanoID-21-et egyetlen kattintással. Minden értéket helyben, a böngészőben számolunk crypto.getRandomValues() segítségével, szerver nélkül.
Válasszon variánst és darabszámot, a lista élőben frissül. Egyszerre 1 és 100 között.
100% a böngészőjében: Ez az oldal tiszta HTML+JavaScript. Nincs szerverforduló, minden UUID-t a Web Crypto API-n (`crypto.getRandomValues`) keresztül helyben húzunk.
Mi az az UUID?
Az UUID (Universally Unique Identifier, RFC 4122 / RFC 9562) egy 128 bites azonosító, amelyet központi hatóság nélkül hoznak létre, mégis gyakorlatilag globálisan egyedi. Szöveges formája 32 hex számjegy, öt csoportra (`8-4-4-4-12`) bontva kötőjelekkel, az elválasztókkal együtt 36 karakter.
Több verzió létezik. A v1 időt + MAC-címet használ (adatvédelmi aggály), a v3 és v5 névből plusz névtérből származtatja az ID-t (determinisztikus), a v4 tisztán véletlenszerű (a modern alapértelmezés), a v7 időrendezett, és megoldja a v4 adatbázis-index problémáját.
Mellettük az ULID és a NanoID nem-IETF, népszerű alternatívák. Az ULID egy 26 karakteres rendezhető string, a NanoID egy rövid, URL-biztos ID (gyakran 21 karakter). Hogy melyik variáns illik, főként a tervezett tárolástól és az URL-elrendezéstől függ.
v4 vs. v7 vs. ULID vs. NanoID
Gyors áttekintés a négy legfontosabb variánsról:
Formátum
Hossz
Ábécé
Rendezhető
Fő használati eset
UUID v4
36 (32 hex + 4 dash)
0-9 a-f
nem (véletlenszerű)
univerzális alapértelmezés, jó belső ID-khez
UUID v7
36
0-9 a-f
igen (időrendezett, 48 bites ms)
elsődleges kulcsok adatbázisokban (B-tree-barát)
ULID
26
0-9 A-Z (ohne I, L, O, U)
igen (időrendezett)
URL-ek / naplók, olvashatóbb a hexnél
NanoID-21
21
A-Z a-z 0-9 _ -
nem (véletlenszerű)
rövid URL-slugok, megosztási linkek
A Crockford base32 (ULID) kihagyja az I, L, O és U betűket, hogy elkerülje a 1, 0 és V összekeverését.
Mikor melyik variánst válasszam?
Ökölszabályok a valós használatból:
UUID v4: szolid alapérték nem rendezett ID-khez (session-ök, idempotency kulcsok, korrelációs ID-k). 122 bites entrópia, ütközési valószínűség elképesztően alacsony.
UUID v7: ajánlott adatbázis elsődleges kulcsoknak. Az első 48 bit unix-ms időbélyeg, így az új sorok a B-tree indexek végére kerülnek (alacsony page-split nyomás, jó locality).
ULID: amikor időrendezett ID-t szeretne, amely URL-ekben és naplókban is olvasható marad. 26 karakter, rövidebb, mint az UUID, de nem RFC-szabvány. Egyes eszközkészletekből hiányzik a natív támogatás.
NanoID-21: ideális látható megosztási linkekhez és slugokhoz. 21 karakter, URL-biztos, körülbelül 126 bites entrópia (több, mint az UUID v4) sokkal rövidebb hosszon.
Miért ne használjon auto-increment ID-ket éles környezetben?
Az auto-increment ID-k (pl. `BIGINT IDENTITY` vagy `SERIAL`) egyszerűek, gyorsak és index-barátok, de több modern követelménynek nem felelnek meg:
Üzleti metrikákat szivárogtatnak: egy versenytárs, aki két egymást követő rendelési számot lát, azonnal megtudja, hány rendelés folyik naponta.
Nem nyújtanak bot-védelmet: a `/users/123` az, amit minden brute-force crawler 1-től n-ig végigjár, minden ID triviálisan felsorolható.
Akadályozzák az elosztott rendszereket: egy multi-region telepítésnek vagy offline klienseknek (mobilalkalmazások, edge) szekvenciákat kell összehangolnia, vagy központi ID-szolgáltatást kell üzemeltetnie. Az UUID-k ezt teljesen elkerülik.
Nem oszthatók ki kliensoldalon: egy frontend nem foglalhat le auto-increment ID-t INSERT előtt (pl. optimistic UI-hoz). Az UUID-ket a kliensben generáljuk, és az `INSERT`-en keresztül továbbítjuk.
Nem tesztbarátak: a visszagörgető tesztek ütköznek a szekvenciaértékekkel, vagy lyukakat hagynak. Az UUID-k tesztek között stabilak maradnak.
Ajánlás: tartsa meg az auto-incrementet belső, tisztán operatív tábláknál (migrációs napló, számlálók), és használjon UUID v7-et alapértelmezett elsődleges kulcsként a domain entitásokhoz (User, Order, Document).
UUID teljesítmény adatbázisokban
A leggyakoribb kifogás az UUID-kal szemben az, hogy "tönkreteszik az index-teljesítményt". Részben régen igaz volt, de vagy könnyen orvosolható, vagy a v7/ULID teljesen elkerüli.
A valódi probléma nem a méret (16 byte 8 byte helyett egy bigintnél), hanem a véletlenszerű beszúrási sorrend: v4-nél minden insert valahol a B-tree közepén landol, ami page split-eket, hideg cache-t és write amplificationt okoz.
1. megoldás: használjon UUID v7-et vagy ULID-ot v4 helyett. Az időrendezett bitek biztosítják, hogy az új sorok az index végére kerüljenek.
2. megoldás: PostgreSQL-ben használja az `uuid` típust, MySQL-ben `BINARY(16)`-ot (`CHAR(36)` helyett), ezzel soronként 20 byte-ot takarít meg, és integer-gyors lesz az összehasonlítás.
3. megoldás: helyezze a clustered indexet egy másik kulcsra (pl. monoton növekvőre), és tartsa meg az UUID-t másodlagos kulcsként. Gyakori MS SQL Serverben.
4. megoldás: tömeges beszúrásnál szúrjon be rendezett sorrendben, vagy használjon olyan bulk loadert, amely a végén újraépíti az indexet.
A jelenlegi Postgres és MySQL verziókban az UUID v7 elsődleges kulcsként szinte minden munkaterhelésnél gyorsabb a v4-nél, és nagyjából egyenrangú a bigint auto-incrementtel, miközben minden előny megmarad (nincs leak, elosztott létrehozás, kliensoldali).
Magas áteresztőképességű backendek a KernelHostnál
Aki naponta milliós nagyságrendben tárol UUID-ket adatbázisban, NVMe-tárolót, ECC RAM-ot és stabil uplinket szeretne. A KernelHost saját dedikált és VPS-szervereket üzemeltet Frankfurt FRA01-ben DDoS-védelemmel, IPv4 + IPv6-tal és 1 Gbit/s sávszélességgel. Alacsony RTT a német és osztrák ügyfelek felé, fair árazás. Cégszékhely Bécs (AT), adatközpont Frankfurt (DE).
UUID GYIK
Az itt generált UUID-k kriptográfiailag biztonságosak?
Igen. Az UUID v4 a `crypto.randomUUID()`-t, a többi variáns a `crypto.getRandomValues()`-t használja. Mindkettő CSPRNG-forrás, alkalmas tokenekhez, kulcsokhoz és ID-generáláshoz.
Mekkora az ütközés valószínűsége?
Az UUID v4-hez (122 bites entrópia) körülbelül 2,71 milliárd ID kell az 50%-os ütközési határ eléréséhez (születésnapi paradoxon). A mindennapokban gyakorlatilag nulla.
Az UUID v7 már stabil?
Igen. Az UUID v7-et hivatalosan az RFC 9562 szabványosította (2024. május). A Postgres 17 natívan támogatja a v7-et, és minden nagyobb nyelvben létezik könyvtár.
Miért nem jelenik meg időbélyeg az UUID v4 és NanoID mellett?
Ezek a variánsok nem kódolnak időbélyeget. Csak az UUID v7 és az ULID rendezhető időben, ezért csak ott jelenik meg az ms időbélyeg extra információként.
Az oldal tárolja valahol a generált ID-ket?
Nem. A lista csak ennek az egy oldalnak a DOM-jában él. Egy újratöltés új ID-ket generál. Nincs szerverforduló, nincs `fetch`, nincs követés. Csak a legutóbbi variáns + darabszám marad meg a `localStorage`-ban, hogy a következő látogatás a megfelelő állapotban induljon.
Generálhatok 100-nál több ID-t egyszerre?
A felület 100-ra van korlátozva, hogy a renderelés gördülékeny maradjon. Szkriptes igényhez (pl. tesztadat) hívja közvetlenül a `crypto.randomUUID()`-t Node-ban vagy bármilyen nyelven.
Az eszköz tud UUID v3/v5-öt is létrehozni?
Pillanatnyilag nem. A v3 és v5 determinisztikus (hash a névtér + név felett), és inkább szerveroldali kódba illik. Ha szüksége van rá, írjon nekünk, vagy használjon olyan könyvtárat, mint az `uuid` Node-ban vagy a `python-uuid`.
Az UUID-ket stringként vagy byte-ként tároljam?
Ha a driver ismeri a natív UUID-típust (Postgres, .NET, MongoDB), használja a natív típust. Egyébként inkább `BINARY(16)`-ot, mint `CHAR(36)`-ot: 20 byte megtakarítás soronként, gyorsabb összehasonlítás, nincs extra padding vagy cast overhead.
Az összes KernelHost termék
Többre van szükséged, mint eszközökre? Nézd meg kereskedelmi tárhely-kínálatunkat.