UUID v7 -generaattori

Luo UUID v7 -arvoja verkossa: ajan mukaan lajiteltavat UUID-tunnisteet 48-bittisellä millisekuntiaikaleimalla ja 74 satunnaisella bitillä.

Muoto
Luodut tunnisteet
Valmis. Luo UUID v7 -arvoja selaimessasi.

Miten tämä tunniste muodostuu

Rakenne
48-bittinen Unix-millisekuntiaikaleima, version 7 bitit, RFC-varianttibitit ja satunnaistäyttö.
Entropia
Tässä toteutuksessa 74 satunnaista bittiä; monotonista laskuria ei käytetä.
Aika
Kyllä. Ensimmäiset 48 bittiä koodaavat luontiajan, joten tunnisteet lajitellaan ajan mukaan eri millisekunneissa.
Törmäysriski
Yhden millisekunnin sisällä törmäykset riippuvat 74 satunnaisesta bitistä; erittäin suuria määriä samalla millisekunnilla luovien järjestelmien tulisi käyttää koordinoitua ID-palvelua.
Esimerkki
01a044bc-597f-79ae-8da8-47a214db71a3

Tunnisteesi luodaan paikallisesti selaimen vahvalla satunnaisgeneraattorilla. Mitään ei lähetetä BroBroGo-palveluun.

Usein kysytyt kysymykset

Miksi valita UUID v7 eikä UUID v4?

UUID v7 säilyttää UUID-muodon mutta lajittelee ajan mukaan, mikä auttaa pitämään lokit, tietokantaindeksit ja tapahtumavirrat likimain kronologisessa järjestyksessä.

Piilottaako UUID v7 luontiajan?

Ei. Aikaleima on osa tunnistetta. Käytä UUID v4- tai NanoID-tunnistetta, jos tarvitset läpinäkymättömän tunnisteen ilman aikatetoja.

Mikä UUID v7 on ja miksi se on tärkeä?

UUID v7 on 128-bittinen tunniste, joka paketoi 48-bittisen Unix-millisekuntiaikaleiman alkuunsa ja täydentää loput satunnaisbiteillä. Lopputulos on 36-merkin pituinen merkkijono, joka näyttää tältä: 018e7c9e-3f4a-7b00-8000-000000000000. Tämä ei ole mikä tahansa satunnaisluku – aikaleiman ansiosta tunnisteet asettuvat aikajärjestykseen luontiajan mukaan, mikä ratkaisee UUID v4:n pahimman ongelman tietokantaindekseissä.

Tällä sivulla voit luoda 1–100 UUID v7 -tunnistetta kerralla. Voit vaikuttaa siihen, näytetäänkö tunnisteet isolla kirjaimilla ja sisältävätkö ne yhdysviivoja. Kaikki luonti tapahtuu selaimessasi – yhtään bittiä ei lähetetä BroBroGo-palvelimelle.

Miten UUID v7 eroaa UUID v4:stä ja muista aikapohjaisista tunnisteista?

UUID v4 on täysin satunnainen. Se on hyvä tietoturvan kannalta (tunnistetta ei voi arvata), mutta tietokannassa se aiheuttaa indeksifragmentaatiota, koska B-puulle uusi rivi ilmestyy aina satunnaiseen kohtaan. UUID v7 sen sijaan alkaa aikaleimalla, joten peräkkäin luodut tunnisteet menevät tietokannassa lähekkäin. Tämä parantaa kirjoitusnopeutta ja vähentää levyn hajanaisuutta.

Vertailu:

Ominaisuus UUID v4 UUID v7
Bittien määrä 128 128
Aikaleima ei 48-bittinen millisekunti
Järjestys satunnainen aikajärjestys (samalla millisekunnilla ei takuuta)
Arvattavuus erittäin vaikea erittäin vaikea (satunnaisosa 74 bittiä)
Idelokalisuus indeksissä huono hyvä

Verrattuna ULID:hen (26-merkkinen, Crockford base32) UUID v7 on 36-merkkinen ja noudattaa IETF RFC 9562 -standardia. ULID on tiiviimpi, mutta UUID v7 on yhteensopiva olemassa olevien UUID-kirjastojen kanssa. Molemmat sisältävät aikaleiman, mutta UUID v7:n aikaleima on 48-bittinen, kun ULID käyttää 48-bittiä millisekunteina (sama tarkkuus). Ero tulee esitysmuodossa.

Miksi saman millisekunnin järjestystä ei taata?

UUID v7:n spesiaatio määrittää, että aikaleiman jälkeen tuleva satunnaisosa ei ota kantaa samalla hetkellä luotujen tunnisteiden keskinäiseen järjestykseen. Tämä on tietoinen valinta: se mahdollistaa rinnakkaisen luonnin useissa säikeissä tai koneissa ilman koordinaatiota. Jos tiukka aikajärjestys tarvitaan, käytetään esimerkiksi UUID v6:ta (jossa satunnaisosa on korvattu sekvenssilaskurilla) tai ULID:ä, joka base32-koodauksensa ansiosta säilyttää satunnaisosassakin aikajärjestyksen osittain.

Tämä tarkoittaa: jos luot kaksi UUID v7 -tunnistetta samalla millisekunnilla, ne saavat saman aikaleiman, mutta kumpi tulee ensin riippuu satunnaisluvuista. Käytännössä tällä ei ole väliä, koska millisekuntitarkkuus riittää yleensä ihmistoiminnoille. Tietokanta indeksoi ne kuitenkin lähekkäin, ja niiden järjestys samalla aikaleimalla on deterministinen (satunnaisosan numeerinen arvo).

Työkalun käyttöliittymän toiminnot tarkasti

Sivu tarjoaa seuraavat asetukset:

  • Muoto: valittuna UUID v7 (muita vaihtoehtoja ei tällä sivulla ole, mutta format picker on olemassa).
  • Määrä: liukusäädin tai kenttä, arvot 1–100. Oletusarvo todennäköisesti 5 tai 10.
  • Uppercase: valintaruutu, joka muuttaa kaikki kirjaimet ISOILLA KIRJAIMILLA (esim. 018E7C9E-3F4A-7B00-8000-000000000000).
  • Include hyphens: valintaruutu, joka poistaa yhdysviivat (esim. 018e7c9e3f4a7b008000000000000000). Oletuksena hypenit ovat mukana, koska standardi UUID esitetään niillä.

Kun muutat mitä tahansa asetusta, tunnisteet luodaan uudelleen heti. Tämä on tärkeä käyttäjäkokemus: sinun ei tarvitse painaa "Generoi"-nappia erikseen.

Tulostuslistassa jokainen tunniste on oma kopioitava elementtinsä. Klikkaamalla yksittäistä tunnistetta se kopioituu leikepöydälle ja tilaksi päivittyy "Copied all!" vasta kun kaikki tunnisteet on kopioitu (tai "Generated." kun luonti tapahtuu). Tilan "Ready." tarkoittaa, että sivu on latautunut eikä mitään ole vielä tehty.

Tekninen toteutus: paikallinen satunnaisuus ja yksityisyys

Kaikki UUID v7 -tunnisteet generoidaan selaimessa käyttäen crypto.getRandomValues()-metodia. Tämä on vahva kryptografinen satunnaislähde, jota käyttävät myös selainten modernit UUID-kirjastot. Yhtään tietoa ei lähetetä BroBroGolle. Tämä tarkoittaa:

  • Tunnisteet ovat yksityisiä – mikään palvelin ei näe niitä.
  • Generointi toimii offline-tilassa (jos sivu on välimuistissa).
  • Nopeus on hyvä: 100 tunnisteen luonti kestää alle millisekunnin.

Jos haluat varmistaa, että satunnaisosa on todella vahva, voit tarkistaa selaimen konsolista: window.crypto.getRandomValues(new Uint8Array(1)). Tämä tuottaa kryptografisesti vahvaa satunnaisuutta, toisin kuin Math.random(), jota ei pidä koskaan käyttää tunnisteiden luontiin.

Yleisiä virheitä ja sudenkuoppia

1. Uppercase vs lowercase tietokannassa

Monet tietokannat tallentavat UUID:t oletuksena pienaakkosilla (lowercase). Jos valitset isona, saat 36-merkkinen merkkijono, jossa on isoja kirjaimia. Tämä on standardin mukaan sallittua (RFC 4122 §3 mukaan kirjainkoolla ei ole väliä), mutta jos indeksi on luotu pienaakkosille, hakuehto WHERE id = '018E...' voi toimia, mutta kannattaa tarkistaa, käyttääkö tietokanta binääristä vertailua (MySQL:n oletus on case-insensitive, PostgreSQL case-sensitive). Yksinkertaisin on pitäytyä pienaakkosissa.

2. Hyphenien poistaminen

Tietokannassa UUID voidaan tallentaa joko 36 merkkisenä merkkijonona (hyphenit mukana) tai 32 merkkisenä hex-muodossa (ilman hyphenejä). Jos poistat hyphenit, saat puhtaan hex-esityksen, jonka pituus on 32 merkkiä. Tämä on hyödyllistä, jos haluat tallentaa UUID:n BINARY(16)-kenttään: silloin tarvitset hex-dekoodauksen. Mutta jos kopioit 32-merkkisen hex-merkkijonon ja liität sen SQL-kyselyyn, joka odottaa standardimuotoa, se ei toimi.

3. Saman millisekunnin ongelma testauksessa

Kun testaat työkalua ja luot nopeasti monta tunnistetta, huomaat, että niiden aikaleimat ovat usein samat (koska generointi tapahtuu alle millisekunnissa). Tämä on odotettua, eikä se ole virhe. Jos tarvitset tarkempaa aikajärjestystä, käytä UUID v6:ta tai ULID:ä, jotka tarjoavat paremman saman millisekunnin erottelukyvyn.

4. Älä sekoita UUID v7:tä UUID v1:een

UUID v1 käyttää MAC-osoitetta ja aikaa 100 nanosekunnin tarkkuudella, mikä paljastaa laitteen. UUID v7 ei sisällä MAC-osoitetta, joten se on yksityisempi.

Usein kysytyt kysymykset

1. Voinko käyttää UUID v7:tä ensisijaisena avaimena MySQL:ssä?

Kyllä, ja se on suositeltavaa verrattuna UUID v4:ään. UUID v7 vähentää indeksin jakautumista, koska peräkkäiset tunnisteet menevät lähekkäin. Mutta muista, että UUID v7 ei ole täysin järjestyksessä samalla millisekunnilla, joten jos kirjoitat tuhansia rivejä sekunnissa, voit silti nähdä satunnaista hajaantumista.

2. Miten UUID v7 eroaa UUID v6:sta?

UUID v6 on samanlainen, mutta aikaleiman jälkeen tulee "clock sequence" (14 bittiä) ja satunnaisosa (74 bittiä). UUID v6 takaa tiukemman järjestyksen samalla aikaleimalla, koska clock sequence kasvaa jokaisella luonnilla. UUID v7 taas sallii rinnakkaisuuden paremmin, koska satunnaisosa voi olla mikä tahansa.

3. Ovatko UUID v7 -tunnisteet uniikkeja?

Teoriassa törmäys on mahdollinen, mutta käytännössä erittäin epätodennäköinen. Satunnaisosan koko on 74 bittiä (version ja variantin jälkeen). Törmäystodennäköisyys sadan miljardin tunnisteen joukossa on alle 1e-12. Työkalun luomat 1–100 tunnistetta eivät aiheuta riskiä.

4. Miksi en näe "Generate"-painiketta?

Koska luonti tapahtuu automaattisesti, kun muutat mitä tahansa asetusta. Tämä on tarkoituksellista: näet tulokset välittömästi.

5. Voinko luoda yli 100 tunnistetta kerralla?

Ei, raja on 100. Jos tarvitset enemmän, luo ne erissä. Rajan syy on todennäköisesti käyttöliittymän selkeys ja suorituskyky (100:n kopiointi leikepöydälle on silti nopeaa).

6. Miten varmistan, että tunnisteet ovat oikeassa järjestyksessä?

Avaa selaimen kehittäjätyökalut (F12) ja tarkastele tunnisteiden aikaleimoja: ensimmäinen 12 hex-merkkiä (ensimmäiset 48 bittiä) edustaa Unix-aikaa millisekunteina. Jos kaksi tunnistetta on luotu samalla millisekunnilla, niiden aikaleima on sama. Voit verrata niitä esim. tällä JavaScript-koodilla konsolissa: parseInt(tunniste.substr(0,12), 16).