featured image

Últimamente, cada más sistemas, y cada más sitios emplean algo llamado UUID, cuyas siglas vienen a decir: Universally Unique ID; aunque suene algo arrogante, el cálculo de un UUID casi que podríamos decir que garantiza el que sea único. Es más, su grado de colisión es tan bajo que si lo colocásemos como identificador de clave primaria de una tabla que alberga elementos recogidos aleatoriamente de otras tablas de bases de datos de todo el mundo, que hayan empleado este tipo de dato, garantizamos que no habrá repetidos.

Suena excitante, pero...

¿Cómo funciona esto?

Referenciado en el RFC 4122 del IETF (Internet Engineering Task Force), el UUID se puede definir como un número de 16 bytes (128-bits) que se representa por 32 dígitos hexadecimales, mostrados en cinco grupos separados por guiones:

12345678-abcd-1b3d-a2c4-0123456789ab

Cada uno de los cinco grupos identifica un dato específico para garantizar su carácter único. En principio, se toma el timestamp de la hora actual con precisión de 100 nanosegundos y en formato UTC desde el 15 de octubre de 1582 (la fecha de la reforma gregoriana para el calendario cristiano) de la siguiente forma:

  • time_low el campo bajo del timestamp, este ocupa los primeros 32 bits.
  • time_mid el campo medio del timestamp, ocupa los siguientes 16 bits.
  • time_high la última parte del timestamp, este no ocupa todo el grupo, sino solo los bits de menor peso, los primeros 12 bits.

Para llegar a los primeros 64 bits nos faltan 4, esto es porque estos se emplean para identificar la versión de UUID que se emplea, según el RFC4122, de momento se contemplan 5:

  1. Versión basada en tiempo. Especificada en el RFC4122.
  2. Versión de Seguridad DCE con UIDs POSIX embebidos.
  3. Versión basada en nombre que usa MD5 (también se especifica en el RFC4122).
  4. Versión aleatoria o pseudo-aleatoria de generación (también se especifica en el RFC4122).
  5. Versión basada en nombre que usa SHA-1 (también se especifica en el RFC4122).

El 4º campo se divide en dos, pero para un mismo concepto, que es la secuencia de reloj. Se escribe con datos de 8 bits especificando el de mayor y menor peso, quedando en este orden almacenados en el cuarto grupo. Aunque el grupo ocupa 16 bits, las versiones 3, 4 y 5 lo emplean como un dato de 14 bits, siendo en las versiones 3 y 5 una secuencia de reloj construida desde un nombre, y en la versión 4 una secuencia de reloj aleatoria o pseudo-aleatoria.

El 5º grupo es denominado el nodo. Ocupa 48 bits. En la versión 1 de UUID este dato se corresponde con la dirección MAC (dirección física de una interfaz de red) definida en el IEEE 802. Para equipos sin interfaz de red, se emplea un dato aleatorio o pseudo-aleatorio. Para las versiones 3 y 5 de UUID, este dato cambio construyéndose a través de una elección de nombre y codificándola con MD5 o SHA-1. Para la versión 4, este dato se construye a través de un número aleatorio o pseudo-aleatorio.

Conclusiones

Los UUID son identificadores únicos y muy difíciles de que se produzcan dos iguales dados los parámetros que se emplean para su generación. Al igual que los datos que se emplean para la generación del conference ID de la comunicación de H.323, este dato puede ser empleado como identificador de tablas y estar seguro que, aunque la tabla esté fraccionada y después se mezcle en una, los datos no colisionarán nunca.