Què és UUID v7 i com funciona
UUID v7 és un format d’identificador de 128 bits definit per la proposta RFC 9562. A diferència del seu predecessor UUID v4, que és completament aleatori, UUID v7 incorpora una marca de temps Unix de 48 bits al principi de l’identificador. Aquesta marca de temps compta els mil·lisegons des de l’1 de gener de 1970 (epoch Unix) i ocupa els primers 12 caràcters hexadecimals del text de 36 caràcters. La resta de bits són aleatoris, generats amb criptografia forta del navegador.
L’estructura concreta és: ttttttttttttrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr, on t són dígits hexadecimals del timestamp i r són dígits hexadecimals aleatoris. Si s’inclouen guions (segons l’estàndard), el format passa a ser tttttttt-tttt-rrrr-rrrr-rrrrrrrrrrrr. La posició dels guions no altera el valor dels bits, només la llegibilitat.
La clau d’UUID v7 és que els primers caràcters (els del timestamp) fan que els identificadors es puguin ordenar cronològicament. Quan es generen en moments diferents, l’ordre lexicogràfic coincideix amb l’ordre de creació. Això resol un dels problemes crítics de UUID v4: la fragmentació dels índexos en bases de dades relacionals.
Per què l’ordenació cronològica és crítica per a bases de dades
En una base de dades com PostgreSQL, MySQL o SQL Server, les claus primàries sovint s’emmagatzemen en estructures B-tree o B+tree. Quan s’insereix una nova fila, el motor ha de localitzar el node del B-tree on ha d’anar la clau. Si la clau és aleatòria (UUID v4), les insercions salten per tot l’arbre, forçant reequilibris constants i fragmentació del disc.
Amb UUID v7, les claus noves sempre cauen al final de l’índex (o molt a prop del moment actual), perquè el timestamp creix monòtonament. Això comporta:
- Menys reequilibris del B-tree: les insercions es concentren en un rang reduït de pàgines.
- Major taxa de cache hits: les pàgines calentes (les del final) romanen a memòria.
- Reducció de la fragmentació: les dades s’emmagatzemen més contínuament.
El guany és especialment notable en taules amb moltes escriptures concurrents. Però UUID v7 no garanteix un ordre estricte dins del mateix mil·lisegon. Si dos ID es generen al mateix timestamp, la part aleatòria determina l’ordre, i aquest ordre pot no coincidir amb l’ordre real de creació (per exemple, si el primer ID generat obté aleatòriament un valor més alt que el segon). Això és un compromís assumit: la velocitat de generació en paral·lel és prioritària sobre l’ordenació fina.
Com es genera en local: privadesa i immediatesa
El generador que descriu aquesta pàgina treballa enterament al navegador. No s’envia cap dada al servidor de BroBroGo (ni a cap altre). La generació es fa amb l’API crypto.getRandomValues(), que proporciona bits aleatoris criptogràficament segurs. El timestamp s’obté amb Date.now(), que retorna el nombre de mil·lisegons des de l’epoch.
Les opcions disponibles són:
- Recompte: un nombre enter entre 1 i 100, que determina quants UUID v7 es generen en cada tirada.
- Majúscules (toggle): si està activat, els caràcters hexadecimals (
a–f) es mostren en majúscula (A–F). - Incloure guions (toggle): si està actiu, el format inclou els guions estàndard.
Qualsevol canvi en qualsevol d’aquests controls regenera totes les ID a l’instant. No cal prémer cap botó de “generar”. Això és útil per a proves ràpides: es pot ajustar el recompte o el format i veure el resultat immediatament.
Un cop generades, cada ID es pot copiar individualment fent clic sobre ella. També hi ha una opció per copiar totes alhora, moment en què l’estat canvia a “Copied all!”. L’estat general de la pàgina mostra “Ready.” en repòs i “Generated.” després d’una generació.
Opcions de format i el seu impacte pràctic
| Opció | Efecte | Consideracions |
|---|---|---|
| Majúscules | Mostra els dígits hexadecimals en majúscula | La majúscula no canvia el valor, però pot afectar la compatibilitat amb sistemes que distingeixen caixa (pocs, però existeixen). L’estàndard UUID no imposa caixa; és una elecció de presentació. |
| Guions | Insereix guions als intervals estàndard (8-4-4-4-12) | Els guions formen part de la representació textual canònica (RFC 4122). Si es guarden en base de dades, molts SGBD eliminen guions internament. Per a claus en URLs, de vegades és preferible eliminar-los. |
| Recompte (1–100) | Genera entre 1 i 100 ID | El límit de 100 evita sobrecàrrega a la interfície i garanteix que la generació sigui instantània. Per a necessitats superiors, cal executar el generador repetidament. |
Totes les opcions només afecten la presentació. L’estructura interna (48 bits de timestamp + 74 bits aleatoris + 6 bits de variant/versió) és la mateixa.
Comparació amb UUID v4 i ULID
UUID v4 (RFC 4122): completament aleatori, 122 bits d’aleatorietat. Ideal per a unicitat màxima, però dolent per a ordenació i índexos. És el format més comú per a claus primàries, tot i que la seva fragmentació d’índex ha motivat moltes migracions a formats temporals.
UUID v7: afegeix el timestamp sense perdre aleatorietat. Ofereix una ordenació aproximadament cronològica. El timestamp de 48 bits cobreix fins a l’any 10889 (2^48 mil·lisegons des de 1970), de manera que no hi ha risc de desbordament en cap aplicació real.
ULID: un format alternatiu de 128 bits que també combina timestamp i aleatorietat, però amb una representació diferent: 26 caràcters en base32 (Crockford), sense guions, i amb un timestamp de 48 bits en l’ordre oposat (els primers caràcters són el timestamp). ULID garanteix que dins del mateix mil·lisegon, els ID generats per un mateix procés són estrictament creixents (utilitza un comptador en lloc d’aleatorietat pura). UUID v7 no ofereix aquesta garantia; en el mateix mil·lisegon, l’ordre depèn de l’aleatorietat.
La tria entre UUID v7 i ULID sol dependre de si es necessita ordre estricte intra-mil·lisegon i de quin ecosistema d’eines es fa servir. Moltes llibreries modernes (ex: uuid de Node.js) ja suporten v7 nativament.
Casos d’ús reals
- Missatgeria i event sourcing: els events s’emmagatzemen amb una clau que es pot ordenar per temps sense necessitar una columna addicional de timestamp. Això simplifica les consultes de “següent event després de X”.
- Sistemes distribuïts sense rellotge coordinat: com que el timestamp és local al generador, dos nodes diferents poden generar ID amb timestamps desfasats. Però si l’aplicació tolera desviacions de rellotge (fins a uns quants ms), l’ordenació global és suficient.
- Auditoria de logs: cada entrada de log pot tenir un UUID v7 com a clau primària. La clau ja conté el moment de creació, evitant la duplicitat d’informació.
- Migració des de UUID v4: canviar el tipus de dades a UUID v7 pot millorar el rendiment de les insercions sense trencar les claus existents, sempre que es regenerin les noves claus amb v7. Les claus antigues (v4) es barrejaran al principi, però noves claus aniran al final de l’índex.
Preguntes freqüents (FAQ)
P: Hi ha risc de col·lisió entre dos UUID v7 generats al mateix navegador?
R: Extremadament baix. La part aleatòria té 74 bits (combinant bits de variància), cosa que dona espai per a 2^74 valors diferents per mil·lisegon. Generar un nombre de ID suficient per a una col·lisió requeriria una escala astronòmica.
P: Puc generar més de 100 ID de cop?
R: La pàgina limita el recompte a 100 per evitar sobrecàrrega visual i computacional. Per a generar-ne més, es pot fer múltiples generacions consecutives.
P: Els guions són opcionals? Què fa l’estàndard?
R: L’estàndard UUID (RFC 4122) especifica que la representació textual inclou guions (8-4-4-4-12). Tanmateix, molts sistemes emmagatzemen l’UUID en format binari o en text sense guions. L’opció “Incloure guions” permet adaptar-se a les convencions del projecte.
P: UUID v7 és segur per a claus públiques?
R: Sí, la part aleatòria prové d’una font criptogràficament segura (crypto.getRandomValues). No es pot endevinar la clau a partir del timestamp. Però no és un mecanisme d’autenticació; és un identificador amb aleatorietat forta.
P: Per què no es garanteix l’ordre dins del mateix mil·lisegon?
R: Perquè la part aleatòria es genera independentment per cada ID. ULID, en canvi, utilitza un comptedor seqüencial dins del mateix mil·lisegon, però amb el cost de requerir un estat compartit. UUID v7 prioritza la generació descentralitzada i sense estat.
P: Què passa si el sistema té un rellotge desviat?
R: El timestamp es pren del rellotge del navegador. Si està desviat, les ID es generaran amb marques de temps incorrectes. En sistemes distribuïts, és recomanable sincronitzar rellotges amb NTP o utilitzar un servei de timestamps centralitzat (per exemple, amb vectors de rellotge). Per a un generador local d’escriptori, la desviació típica és inferior a 10 ms.
El generador de UUID v7 en línia ofereix una manera senzilla i privada d’obtenir identificadors moderns, ordenats i segurs, sense dependre de servidors externs. Tant si s’està dissenyant un sistema nou com si es vol migrar des de v4, conèixer les propietats d’aquest format ajuda a prendre decisions informades sobre indexació i rendiment.