UUID v4 ģenerators

UUID v4 ģenerators — nejaušu identifikatoru ģenerēšana pārlūkprogrammā

Šī lapa ģenerē vienu vai vairākus UUID v4 identifikatorus — 36 rakstzīmju garas, nejaušas virknes standarta 8‑4‑4‑4‑12 heksadecimālajā formātā. Lietotājs kontrolē ģenerējamo ID skaitu (no 1 līdz 100), to, vai heksadecimālie burti tiek attēloti lielajiem burtiem, un vai iekļaut defises. ID parādās uzreiz pārlūkprogrammā, un katru var nokopēt, uzklikšķinot, vai ar vienu klikšķi nokopēt visus uzreiz.

Kas padara šo lapu atšķirīgu no citiem ID ģeneratoriem

Katrs UUID v4 satur 122 nejaušības bitus — atlikušie 6 biti ir fiksēti versijas un varianta biti. Tas nozīmē, ka vērtības nekārtojas secīgi — tām nav laika vai kārtas informācijas. Ja UUID v4 lieto kā primāro atslēgu relāciju datubāzē, tas sadrupina B‑koka indeksus, atšķirībā no laikā sakārtotiem formātiem, piemēram, UUID v7 vai ULID. Kolīziju varbūtība ir nenozīmīga praktiskiem nolūkiem. Lapa piedāvā formātam specifiskus iestatījumus (lielie burti, defises), kas attiecas tikai uz UUID (v4 un v7), nevis citiem ID veidiem, piemēram, Nanoid vai ULID.

UUID v4 uzbūve un nejaušība

UUID v4 definē RFC 4122 standarts. Katrs identifikators sastāv no 128 bitiem, no kuriem 122 tiek ģenerēti nejauši, izmantojot pārlūkprogrammas crypto.getRandomValues() vai crypto.randomUUID() metodi. Atlikušie biti ir:

• 4 biti versijai (vērtība 0100 — bināri 4, tātad versija 4)
• 2 biti variantam (vērtība 10 — bināri, kas atbilst RFC 4122 variantam)

Kanoniskais formāts ir 8‑4‑4‑4‑12 — 36 rakstzīmes, tai skaitā 4 defises un 32 heksadecimālie cipari. Piemēram: f47ac10b-58cc-4372-a567-0e02b2c3d479. Ja defises tiek izslēgtas, virknes garums samazinās līdz 32 rakstzīmēm.

Heksadecimālie cipari a–f pēc noklusējuma tiek rādīti mazajiem burtiem. Ieslēdzot “Uppercase” opciju, tie tiek attēloti kā A–F. Tas neietekmē nejaušības bitu saturu — mainās tikai displeja forma. Dažas sistēmas prasa lielos burtus (piemēram, noteiktās datubāžu konfigurācijās), bet vairumā gadījumu mazie burti ir standarts.

122 biti nejaušības nozīmē, ka katram jaunam UUID ir 2^122 iespējamo vērtību ( ≈ 5,3 × 10^36 ). Salīdzinājumam — Zemes okeānos ir aptuveni 1,3 × 10^21 litru ūdens. Pat ģenerējot miljardu UUID v4 sekundē, būtu nepieciešami triljoniem gadu, lai ar 50% varbūtību sastaptu vienu kolīziju.

Kolīziju varbūtība praktiskos apstākļos

Lai aprēķinātu kolīziju risku, izmanto dzimšanas dienu paradoksa formulu:

P(kolīzija) ≈ 1 − exp(−k² / (2×N))

kur k = ģenerēto UUID skaits un N = 2^122.

Piemēram, ja ģenerējat 1 miljardu UUID (10^9):

P ≈ 1 − exp(−(10^9)² / (2 × 2^122)) ≈ 1 − exp(−10^18 / (2 × 5,3×10^36)) ≈ 1 − exp(−9,4×10^-20) ≈ 9,4×10^-20

Tas ir aptuveni viens no 10^19 — daudz mazāk nekā iespēja, ka zemeslodi trāpīs meteorīts. Lai kolīziju varbūtība sasniegtu 50%, būtu jāģenerē aptuveni 2,6 × 10^18 UUID (≈ 2,6 kvintiljoni). Šī iemesla dēļ UUID v4 tiek uzskatīts par pietiekami nejaušu praktiski jebkuram mērogam, ieskaitot globālas izplatītas sistēmas.

Ietekme uz datubāzu indeksēšanu

Lai gan UUID v4 ir lieliski piemērots izkliedētām sistēmām, kur koordinācija nav iespējama, tā nejaušā secība rada nopietnas veiktspējas problēmas, ja to izmanto kā primāro atslēgu relāciju datubāzēs ar B‑koka indeksiem.

Standarta B‑koks sagaida, ka jauni ieraksti tiks pievienoti galvenokārt labajā pusē (ja atslēgas ir secīgas). UUID v4 vērtības parādās nejaušā secībā, tāpēc katrs jauns ieraksts var tikt ievietots jebkur B‑koka līmenī. Tas izraisa:

• Lapu sadalīšanu — bieži tiek sadalītas lapas, kas nav pilnas, kas palielina diska I/O.
• Indeksa fragmentāciju — B‑koks kļūst “izkliedēts”, un lasīšanas operācijas izmanto vairāk lapu nekā nepieciešams.
• Ieraksta ievietošanas palēnināšanos — katram jaunam ierakstam var būt nepieciešamas vairākas indeksa lapu pārlūkošanas, nevis tikai garākās lapas pievienošana.

Šo iemeslu dēļ datubāžu dizaineri bieži izvēlas UUID v7 (laikā sakārtots) vai ULID, kas apvieno laika zīmogu un nejaušību, tādējādi nodrošinot labāku indeksa lokalitāti. Tomēr, ja sistēmai nepieciešama pilnīga nejaušība (piemēram, lai slēptu ierakstu secību vai novērstu enumerāciju), UUID v4 joprojām ir labākā izvēle.

Lietojuma scenāriji un formatēšanas iespējas

Kam tas nepieciešams:

• Lietojumprogrammu izstrādātāji — nepieciešami lieli daudzumi unikālu objektu atslēgu (lietotāju sesijām, notikumiem, darba vienībām) bez centrāla koordinatora.
• Datu bāzu dizaineri — izprot indeksēšanas kompromisus un izmanto standarta nejaušo UUID izkliedētās sistēmās.
• Drošības inženieri — vajadzīgi neuzminami identifikatori (API žetoni, pieprasījumu ID), kur laikā balstīta korelācija nav vēlama.
• Testētāji un datu ģenerētāji — aizpilda parauga datu bāzes ar reālistiskām, unikālām atslēgām.

Formatēšanas iestatījumi:

Ja defises tiek izlaistas, identificators joprojām ir viennozīmīgs (tikai bez formatējuma). Uppercase maiņa neietekmē bitu saturu — tā ir tikai displeja opcija.

Kā ģenerators darbojas pārlūkprogrammā

Visa ID ģenerēšana notiek klienta pusē, izmantojot pārlūkprogrammas iebūvēto crypto objektu. Netiek nosūtīti nekādi dati uz serveri. Tas nodrošina:

• Privātumu — lietotāja radītie ID paliek tikai viņa ierīcē.
• Zemu latentumu — nav tīkla pieprasījumu, identifikatori parādās acumirklī.
• Drošību — crypto.getRandomValues() izmanto operētājsistēmas līmeņa nejaušības ģeneratoru, kas ir daudz spēcīgāks par JavaScript Math.random().

Kad lietotājs maina kādu no opcijām (formāts, skaits, lielie burti, defises), visi ID tiek uzreiz atkārtoti ģenerēti. Statusa ziņojums (“Ready.”, “Generated.”) norāda pašreizējo stāvokli. Pēc kopēšanas ar pogu “Copy all” parādās ziņojums “Copied all!”; pēc atsevišķa ID noklikšķināšanas tas tiek nokopēts starpliktuvē.

Biežāk uzdotie jautājumi

1. Vai UUID v4 ir pilnīgi nejaušs? Nē — precīzāk, 128 bitos 122 ir nejauši, bet 6 biti ir fiksēti (4 versijai, 2 variantam). Tas nodrošina atpazīstamību un atbilstību RFC 4122.

2. Kāda ir kolīziju iespējamība, ja ģenerēju 1000 UUID? Ārkārtīgi zema. Aprēķinot ar iepriekšējo formulu, iespēja ir aptuveni 10^-30 — praktiski nulle.

3. Vai es varu izmantot UUID v4 kā primāro atslēgu MySQL vai PostgreSQL? Jā, taču esiet gatavs indeksa fragmentācijai. Ja datubāzē rakstīšana ir intensīva, apsveriet UUID v7 vai ULID, lai uzlabotu veiktspēju.

4. Kāpēc lapā ir opcija “Uppercase”? Vai tas ietekmē unikalitāti? Nē — tikai displeja formu. Dažas sistēmas (piemēram, failu sistēmas) ir reģistrjutīgas, tāpēc var būt nepieciešama lielo burtu izmantošana. Bet bitu līmenī tie ir vienādi.

5. Vai varu ģenerēt vairāk nekā 100 UUID vienā reizē? Nē — maksimālais skaits ir ierobežots līdz 100, lai izvairītos no pārmērīgas pārlūkprogrammas ielādes. Ja nepieciešams vairāk, ģenerējiet atkārtoti.

6. Kurš ir labāks — UUID v4 vai v7? Tas ir atkarīgs no lietošanas mērķa. Ja nepieciešama pilnīga nejaušība (piemēram, slēpt ierakstu secību vai strādāt bez centrāla pulksteņa), izvēlieties v4. Ja nepieciešama indeksu veiktspēja un laika kārtošana, izvēlieties v7.