Generador de UUID

Qué contienen los 128 bits

Un UUID son dieciséis bytes, escritos como 32 dígitos hexadecimales en la conocida agrupación 8-4-4-4-12. No todos son libres: cuatro bits identifican la versión y otros dos o tres la variante, por eso el decimotercer dígito de todos los UUID de aquí es un 4 o un 7, y el decimoséptimo es siempre 8, 9, a o b.

Eso deja 122 bits que un UUID versión 4 rellena al azar. La versión 7 dedica sus primeros 48 bits a una marca de tiempo en milisegundos y rellena los 74 restantes con aleatoriedad, cambiando algo de imprevisibilidad por orden.

Los guiones no llevan información y las mayúsculas y minúsculas tampoco, aunque la RFC 9562 indica generar en minúsculas y aceptar ambas en la entrada. El prefijo urn:uuid: y las llaves que tanto gustan a las herramientas de Windows son presentación, no contenido.

Por qué existe la v7

Los UUID versión 4 son uniformemente aleatorios, que es justo lo que quieres en un identificador que no debe revelar nada, y justo lo que no quieres en una clave primaria.

Un índice B-tree mantiene sus entradas ordenadas. Inserta una clave aleatoria y caerá en cualquier punto de ese orden, así que cada inserción toca una página distinta, y cuando el conjunto de páginas en uso supera la memoria, cada inserción implica también una lectura además de una escritura. Las páginas se llenan de forma desigual y se dividen, el índice crece más que los datos que indexa y el rendimiento de escritura empeora a medida que crece la tabla. Con claves secuenciales, las inserciones van al final, una única página se mantiene activa y no pasa nada de esto.

La versión 7 coloca una marca de tiempo en los bits altos para que los ID generados después se ordenen tras los generados antes, recuperando esa localidad sin perder la unicidad global y sin necesidad de coordinación entre máquinas. Es la razón por la que la RFC 9562 la añadió, y hoy es la opción por defecto adecuada para una columna de clave.

El coste es real: un UUID v7 revela aproximadamente cuándo se creó la fila, y los consecutivos revelan el orden y un ritmo aproximado. Cuando un identificador se expone públicamente y cualquiera de las dos cosas es sensible, la v4 sigue siendo la elección correcta.

Colisiones

Dos UUID versión 4 colisionan cuando se repiten 122 bits aleatorios. La forma habitual de hacer comprensible esa cifra es el límite del cumpleaños: tendrías que generar unos mil millones de UUID por segundo durante unos 85 años para que la probabilidad de una sola colisión en todo el conjunto llegara al 50 %.

Así que, en la práctica, no. Los fallos realistas no son estadísticos. Son un generador mal inicializado - máquinas virtuales clonadas de la misma instantánea, dispositivos embebidos sin entropía al arrancar -, código que trunca un UUID para que quepa en una columna y destruye la mayor parte de la aleatoriedad, o una biblioteca que recurre en silencio a una fuente no criptográfica. Aquí los bits vienen del generador criptográfico del navegador, y en otros sitios el buen hábito es comprobar qué usa realmente tu biblioteca en lugar de suponerlo.

Cómo almacenarlos

La forma de texto tiene 36 caracteres. El valor ocupa 16 bytes. Guardar UUID como char(36) duplica con creces el espacio y, en bases de datos donde cada índice secundario lleva una copia de la clave primaria, multiplica ese coste por todo el esquema.

PostgreSQL tiene un tipo uuid nativo que almacena 16 bytes y acepta la forma de texto en la entrada. MySQL no tiene ese tipo; lo habitual es binary(16) con conversión en la frontera, y para los UUID versión 1 existe el conocido truco de reordenar los bytes de tiempo para recuperar el orden, algo que la versión 7 hace innecesario.

Si muestras UUID en una URL y te molesta su longitud, codifica esos mismos 16 bytes en base32 o base64url en lugar de acortar el valor. Truncar parece funcionar justo hasta el momento en que deja de hacerlo.

El conjunto completo de versiones

La versión 1 codifica una marca de tiempo de 60 bits y la dirección MAC de la máquina, lo que la hace ordenable y rastreable; esta segunda propiedad es la razón por la que cayó en desuso, ya que revela qué máquina generó un identificador. La versión 2 es una variante de seguridad de DCE que casi nadie usa. Las versiones 3 y 5 son deterministas: aplican un hash a un espacio de nombres y a un nombre, con MD5 y SHA-1 respectivamente, así que la misma entrada siempre produce el mismo identificador.

La versión 4 es pura aleatoriedad y se volvió el valor por defecto en todas partes porque no necesita coordinación, ni reloj, ni identidad de máquina. La versión 6 es la versión 1 reordenada para que la marca de tiempo ordene correctamente, y la versión 7 es la respuesta moderna: una marca de tiempo en milisegundos en los bits altos seguida de aleatoriedad, estandarizada en el RFC 9562 en 2024.

La versión 5 merece usarse más de lo que se usa. Cuando necesitas un identificador estable derivado de algo que ya tienes -una URL, una ruta de archivo, el nombre de un tenant-, convertirlo en un UUID mediante hash le da a todos los sistemas el mismo identificador, sin tabla de búsqueda y sin ningún paso de coordinación.

Las alternativas y cuándo encajan mejor

ULID codifica una marca de tiempo y aleatoriedad en 26 caracteres de base32 de Crockford: ordenable, sin distinción entre mayúsculas y minúsculas, y más corto que un UUID en forma de texto. Es anterior a la versión 7 y resuelve el mismo problema, así que los sistemas nuevos por lo general pueden simplemente usar v7 y quedarse dentro del estándar.

Los identificadores Snowflake, originarios de Twitter, empaquetan una marca de tiempo, un id de máquina y un número de secuencia en 64 bits. Son compactos, ordenables y requieren poca coordinación, a cambio de que cada nodo tenga un id distinto. También superan lo que un number de JavaScript representa con exactitud, y por eso las API que los usan devuelven cadenas.

nanoid produce cadenas aleatorias cortas para URLs, con un alfabeto configurable: los 21 caracteres predeterminados llevan aproximadamente la misma entropía que un UUID v4 en la mitad del texto. Y un entero autoincremental común y corriente sigue siendo la mejor opción en muchos sistemas: el más pequeño, el más rápido de indexar y perfectamente adecuado cuando los identificadores no salen del interior.

Qué revela un identificador cuando es público

Los enteros secuenciales en URLs públicas le cuentan a cualquiera tu volumen y permiten recorrer el rango: /orders/1001 implica que /orders/1000 existe. Combinado con una comprobación de autorización ausente, eso es la clase de vulnerabilidad conocida como referencia directa insegura a objetos, que sigue siendo una de las fallas que más se encuentran en aplicaciones web.

Un UUID v4 aleatorio elimina la enumeración, y nada más. No es control de acceso: un identificador que nadie puede adivinar sigue siendo un identificador que cualquiera que lo obtenga puede usar, y las URLs se filtran por cabeceras referrer, historial del navegador, registros, capturas de pantalla y enlaces compartidos. Cada petición sigue necesitando comprobar que ese usuario puede ver ese recurso.

La versión 7 devuelve un poco de esa opacidad. Revela aproximadamente cuándo se creó un registro, y los identificadores consecutivos dejan ver el orden y el ritmo: suficiente para deducir cuántos clientes se registraron en una semana. Cuando cualquiera de las dos cosas sea sensible en un identificador público, usa v7 internamente como clave primaria y expón un v4 o un slug aparte.

Claves primarias, índices y almacenamiento

Un índice B-tree mantiene las entradas ordenadas, así que las claves aleatorias dispersan las inserciones por todo el índice. Cuando el índice deja de caber en memoria, cada inserción se convierte también en una lectura, las páginas se llenan de forma despareja y se dividen, y el rendimiento de escritura cae a medida que la tabla crece. Las claves secuenciales se agregan al final, mantienen caliente una sola página y evitan todo eso, que es el argumento completo a favor de la versión 7.

El almacenamiento también cuenta. Un UUID ocupa 16 bytes; su forma en texto tiene 36 caracteres. PostgreSQL tiene un tipo uuid nativo que guarda la forma binaria y acepta texto en la entrada. MySQL no tiene ese tipo, así que la convención es BINARY(16) con conversión en la frontera de la aplicación. Guardarlo como texto más que duplica el espacio, y en motores donde cada índice secundario lleva una copia de la clave primaria, ese costo se multiplica por todo el esquema.

El punto medio habitual es una clave primaria entera y pequeña para los joins internos y un UUID como identificador externo con un índice único. Mantiene compacta la disposición física y a la vez le da al mundo exterior una referencia opaca.

Generarlos de forma segura en el código

Usa la función de la plataforma en lugar de armar uno a mano: crypto.randomUUID en navegadores y Node, uuid4 en Python, UUID.randomUUID en Java. Estas toman valores del generador criptográfico, que es lo que hace válido el argumento sobre las colisiones. Una biblioteca que recurre a Math.random -algunos paquetes de JavaScript antiguos lo hacían- produce identificadores que se ven idénticos y son predecibles.

Los modos de falla realistas no son estadísticos. Las máquinas virtuales clonadas del mismo snapshot pueden arrancar con el mismo pool de entropía; los dispositivos embebidos pueden tener casi nada al encenderse; y el código que trunca un UUID para que quepa en una columna destruye la mayor parte de la aleatoriedad y deja algo que todavía parece un identificador.

Dos hábitos evitan el resto. Compara los identificadores sin distinguir mayúsculas de minúsculas, ya que el RFC 9562 indica emitirlos en minúsculas pero aceptar ambas formas, y quita las llaves y el prefijo urn:uuid: que agregan las herramientas de Windows. Y valida en la entrada en lugar de confiar en la forma, porque una cadena con aspecto de UUID dentro de una URL sigue siendo entrada del usuario.