Effektiv CUID-generator for unike identifikatorer i systemer

Hva er en CUID?

En CUID (kollisjonsresistent unik identifikator) er en kort streng med bokstaver og sifre som brukes til å merke en post, fil eller hendelse, slik at ingen to elementer har samme navn. Dette verktøyet genererer CUID2, den gjeldende versjonen av formatet, ved hjelp av biblioteket @paralleldrive/cuid2. Hver ID er 25 tegn lang, inneholder bare små bokstaver og sifre, og opprettes helt i nettleseren – ingenting sendes til en server.

Slik bruker du denne CUID-generatoren

1. Klikk på Generate New CUID for å opprette en ID.
2. Klikk på Copy to Clipboard for å kopiere den.
3. Lim inn ID-en i en database, et filnavn eller et program.
4. Klikk på genereringsknappen igjen for å få en ny ID. Kollisjoner mellom separate CUID2-verdier er svært usannsynlige, men ikke matematisk umulige.
5. Klikk på Reset for å tømme resultatet.

Den genererte ID-en lagres også i sidens URL, slik at en lenke til resultatet kan deles eller bokmerkes.

Struktur og formel for CUID2

En CUID2 bygges slik:

1id = randomLetter + base36( SHA3-512( time + entropy + counter + fingerprint ) ).substring(1, length)
2

Hashfunksjonen blander fire private inndata: gjeldende tidspunkt, en øktspesifikk teller, et fingeravtrykk av vertsmaskinen og tilfeldig entropi. Den kjører dem gjennom SHA3-512, konverterer resultatet til grunntall 36 (sifrene 0–9 og bokstavene a–z), og beholder 24 av disse tegnene. Den tilfeldige innledende bokstaven gir den ferdige ID-en 25 tegn, som er lengden dette verktøyet er satt til.

Bare det første tegnet står alene: en tilfeldig bokstav plassert først, slik at alle ID-er begynner med en bokstav i stedet for et siffer. Mange systemer, for eksempel navn på SQL-tabeller og -kolonner, krever at identifikatorer begynner med en bokstav. Derfor kan en CUID2 trygt brukes som navn nesten hvor som helst. Hvert tegn etter den første bokstaven er del av én sammenhengende, ugjennomsiktig hashstreng – den består ikke av separate deler.

Siden hashen bare går én vei, kan ingen av inndataene hentes ut fra den ferdige ID-en. En CUID2 har ikke noe gjenopprettbart tidsstempel, ingen gjenopprettbar teller og ikke noe gjenopprettbart fingeravtrykk. Dette er et bevisst valg av hensyn til personvern og sikkerhet: En ID alene kan ikke avsløre når eller hvor den ble opprettet.

Regneeksempel

Generering av en ID med dette verktøyet kan gi:

1vcpuhcj51eomj1o31dnlqopu0
2

Her er v den tilfeldige innledende bokstaven, og cpuhcj51eomj1o31dnlqopu0 (24 tegn) er hashkroppen. De to delene ser bare forskjellige ut fordi det første tegnet garantert er en bokstav – hashkroppen kan inneholde en blanding av bokstaver og sifre.

Hvorfor systemer bruker CUID2

• Ingen koordinering er nødvendig. Enhver maskin kan generere en gyldig ID på egen hånd, uten å be en sentral server eller database om neste verdi.
• Kollisjonsresistens. Blandingen av tidspunkt, teller, vertsfingeravtrykk og tilfeldig entropi gjør det svært usannsynlig at to maskiner produserer samme ID, selv når de genererer mange ID-er per sekund.
• URL-vennlig. En CUID2 bruker bare små bokstaver og sifre, så den trenger aldri kodes for bruk i en nettadresse.
• Rask og privat generering. Siden dette verktøyet kjører generatoren i nettleseren, opprettes ID-er umiddelbart og forlater aldri enheten.

CUID2-ID-er kan ikke sorteres etter opprettelsestidspunkt. I motsetning til et automatisk inkrementert databasetall eller det eldre CUID-formatet (versjon 1) skjuler en CUID2 tidsstempelet i hashen i stedet for å lagre det synlig. Programmer som trenger å sortere poster etter opprettelsesrekkefølge, bør lagre en separat tidsstempelkolonne sammen med ID-en.

CUID2 kontra UUID kontra automatisk inkrementerte ID-er

CUID2 og UUID v4 løser samme problem: å generere ID-er uten sentral koordinering. CUID2 er kortere og bruker et mindre tegnsett, noe som gjør den enklere å lese og lime inn i en URL. En UUID er også trygg i en nettadresse, fordi bindestreken er et ureservert tegn i URL-er, men den er 11 tegn lengre.

Vanlige bruksområder

• Primærnøkler i distribuerte databaser, der flere servere setter inn rader uavhengig av hverandre
• Forespørsels- eller sporings-ID-er som brukes til å følge én handling på tvers av flere mikrotjenester
• Filnavn for opplastinger, slik at to filer aldri overskriver hverandre
• Økt- eller token-ID-er for nettapplikasjoner
• Meldings-ID-er i køer som Kafka eller RabbitMQ

En kort historie

Det opprinnelige CUID-formatet ble lansert av Eric Elliott i 2012 som et alternativ til UUID-er for distribuerte applikasjoner. CUID2, som ble publisert av det samme Paralleldrive-prosjektet, redesignet formatet rundt en kryptografisk hash og fjernet tidsstempelet og telleren som kunne hentes ut fra den opprinnelige versjonen. Dette verktøyet genererer bare CUID2-ID-er.

Ofte stilte spørsmål

Hva er forskjellen mellom CUID (v1) og CUID2? CUID v1 lagret et synlig tidsstempel og en teller i ID-en. Det gjorde ID-ene sorterbare, men avslørte også når og hvor mange ID-er som var opprettet. CUID2 erstatter disse synlige feltene med en enveis-hash, slik at ingen informasjon kan leses ut av ID-en.

Kan CUID-ene fra dette verktøyet sorteres etter opprettelsestidspunkt? Nei. En CUID2 har ikke noe gjenopprettbart tidsstempel, så ID-ene kan ikke ordnes etter når de ble generert bare ved å se på strengen.

Hvor lang er en generert ID, og kan lengden endres? Dette verktøyet genererer alltid ID-er på 25 tegn. Det finnes ikke noe alternativ i dette verktøyet for å be om en annen lengde.

Kan to forskjellige maskiner generere samme CUID2 samtidig? Det er teoretisk mulig, men svært usannsynlig i praksis. Hver ID blander et vertsspesifikt fingeravtrykk med tilfeldig entropi, så uavhengige maskiner vil svært sannsynlig aldri produsere samme hash.

Sender dette verktøyet data til en server? Nei. ID-en genereres av JavaScript som kjører i nettleseren, ved hjelp av den lokale systemklokken og tilfeldige verdier fra nettleseren. Ingenting overføres.

Kan jeg bruke en CUID2 som primærnøkkel i en database? Ja. ID-er av typen CUID2 egner seg godt som primærnøkler i distribuerte databaser, siden enhver node kan generere en uten å måtte avklare det med en sentral sekvens. De sorteres ikke naturlig etter innsettingstidspunkt, så et program som trenger denne rekkefølgen, bør beholde en separat created_at-kolonne.