En algunos casos, el componente de marca de tiempo de UUID versión 1 es realmente bastante útil. En Apache Cassandra, se llaman «TimeUUID«. En Cassandra, los TimeUUID se pueden ordenar por marca de tiempo, bastante útil cuando se necesita ordenar aproximadamente por tiempo. La implementación intercambia algunos de los bits aleatorios con una marca de tiempo y un identificador de host. La ID del host se deriva de las direcciones IP del nodo, que también forman el identificador único en un clúster Cassandra.

La implementación ha sufrido debilidades al tratar de comprometer la singularidad frente al sesgo del reloj. Más importante aún, la información de identificación del host está incrustada en los UUID, que si vemos en el pasado no es una gran idea. Incluso si estas ID se derivan de direcciones de red locales, las mejores prácticas de seguridad desalientan la exposición activa de esta información al mundo exterior, incluso indirectamente.

La capacidad de ordenar las identificaciones por tiempo fue en gran medida la motivación detrás de Snowflake de Twitter, que popularizó en gran medida el concepto de k–ordering por marca de tiempo. Twitter necesitaba una forma de ordenar montones de tweets arbitrarios por tiempo de creación sin coordinación global. Incrustar una marca de tiempo en el ID proporciona esta funcionalidad sin la sobrecarga de un campo de marca de tiempo adicional.

El orden K es una forma más precisa de decir más o menos ordenado. En Snowflake, gran parte del diseño fue impulsado por la necesidad de ajustar estas ID en un espacio numérico de 64 bits. Esto incluye requerir servidores dedicados de generación de ID que usen un mecanismo de coordinación fuerte separado (ZooKeeper) para asignar ID de host y almacenar puntos de control de secuencia.

Inspirado por Snowflake, el equipo de Boundary lanzó Flake a principios de 2012. También utiliza procesos de servidor de generación de ID dedicados, pero no requiere un mecanismo de coordinación sólido. Flake es similar a UUID versión 1 en que utiliza un espacio de números de 128 bits mucho más grande y un identificador de host de 48 bits derivado de la dirección de hardware para proteger contra la superposición en un entorno distribuido. Se diferencia principalmente de la versión 1 en que está estructurado para el ordenamiento lexicográfico. Los bits de una identificación de Flake están organizados de tal manera que los usuarios pueden esperar que se les ordene por su marca de tiempo, independientemente de dónde estén escritos. En contraste, Cassandra debe implementar una lógica de clasificación específica para obtener el mismo comportamiento de su TimeUUID.

Desafortunadamente, parece que Flake ID puede exponer la información de identificación del host a los usuarios finales ya que esta información está integrada en las ID generadas. Si bien la implementación proporcionada se defiende contra situaciones de sesgo en el reloj, su propiedad de unicidad depende en gran medida del movimiento hacia adelante del reloj de pared.

Una característica notable incluida en Flake es la codificación base62, que proporciona una representación mucho más «portátil» que UUID. La representación de cadena de UUID es una de sus características más débiles. Esto puede parecer trivial, pero la inclusión del carácter guión (-) los hace menos utilizables. Un ejemplo de esto es cuando los UUID son indexados por un motor de búsqueda, donde los guiones probablemente se interpretarán como delimitadores de tokens. La codificación base62 evita este obstáculo y conserva las propiedades de ordenación lexicográfica de la codificación binaria.

Fuente:

1. Branson, «A brief history of the UUID,» segment.com, blog; Published: 2017.06.07; visited: 2020.03.14. URL: https://segment.com/blog/a-brief-history-of-the-uuid/. Traducción de Dr. Eduardo René Rodríguez Ávila.