Herramientas de desarrollo · UUID generador
ULID, Snowflake, KSUID y UUIDv7: ID ordenables comparados
· Antecedentes
uuid criptografía APIS del navegador
Los UUID aleatorios no se ordenan por hora de creación, por lo que varios formatos colocan una marca de tiempo primero. Esta publicación compara ULID, Snowflake, KSUID y UUIDv7 en cuanto a diseño, tamaño, monotonicidad y compatibilidad.
ID aleatorios y el índice que los odia: el problema que resuelven los identificadores ordenados por tiempo
Los UUID v4 aleatorios dispersan puntos de inserción en una clave primaria de árbol B a medida que llegan nuevos registros, lo que provoca divisiones y reorganizaciones de páginas. Las inserciones en posiciones aleatorias degradan el rendimiento de escritura y aumentan significativamente la fragmentación del disco. Las bases de datos de alto rendimiento toleran este costo (el precio de identificadores verdaderamente independientes y no coordinados), pero el costo es real. Si necesita UUID para ordenar por hora de creación, puede mejorar drásticamente las características del índice agregando un prefijo de marca de tiempo. Han surgido varios formatos: ULID, Snowflake, KSUID y RFC 9562 v7. Cada uno hace diferentes concesiones en tamaño (26 caracteres a 128 bits), precisión de la marca de tiempo (segundos a nanosegundos), compatibilidad UUID y si la coordinación del generador de ID requiere centralización. Las pruebas comparativas de bases de datos muestran que el rendimiento de inserción mejora significativamente.
ULID: una marca de tiempo de milisegundos de 48 bits más 80 bits aleatorios en 26 caracteres Crockford base32, con una opción monótona
ULID (Identificador universalmente único lexicográfico ordenable) codifica una marca de tiempo de milisegundos de 48 bits y una carga útil aleatoria de 80 bits en 26 caracteres de Crockford base32. La representación del texto se ordena correctamente en orden lexicográfico, lo que hace que los ULID sean adecuados para sistemas donde el orden de las marcas de tiempo y la legibilidad son importantes: procesamiento de registros, rastreo distribuido, microservicios donde los identificadores deben ser fácilmente legibles en la salida de cara humana. ULID ofrece una variante monótona en la que múltiples identificadores generados en el mismo milisegundo incrementan la porción aleatoria en lugar de repetirse, lo que garantiza que incluso las ráfagas de identificación rápidas mantengan un orden de generación estricto. La desventaja es que ULID no es un UUID: no cabe en una columna de base de datos estándar de 128 bits UUID sin conversión de codificación. La precisión de ULID cubre aproximadamente 8925 años.
Copo de nieve: ID de 64 bits de una marca de tiempo, un ID de trabajador y una secuencia, y la coordinación que requieren
Snowflake es un identificador de 64 bits diseñado originalmente por Twitter, estructurado como una marca de tiempo de milisegundos de 41 bits, una identificación de trabajador de 10 bits y un número de secuencia de 12 bits. La marca de tiempo de 41 bits cubre aproximadamente 69 años y se desborda en 2106, lo que requiere coordinación de época y planificación de migración. La ID de trabajador distingue los identificadores generados por diferentes servidores o procesos: cada generador de Snowflake debe conocer su propia ID de trabajador única sin entrar en conflicto con otros. Snowflake tiene 64 bits en lugar de 128, lo que lo hace la mitad del tamaño de un UUID, más rápido de indexar y más eficiente en almacenamiento por identificador. Ordena por hora e ID de trabajador, lo que resulta útil para enrutar solicitudes o registros por fuente. El inconveniente es operativo: a cada generador se le debe asignar una identificación de trabajador y los relojes deben mantenerse sincronizados.
KSUID: marca de tiempo de segundos con una carga útil aleatoria grande, ordenada como bytes
KSUID (Identificador único ordenable K) es un identificador de 128 bits que consta de una segunda marca de tiempo Unix de 32 bits y una carga útil aleatoria de 96 bits, generalmente codificada como caracteres 27 base62. El formato se puede ordenar en orden lexicográfico y la parte aleatoria es criptográficamente sólida para su tamaño. KSUID se adopta menos ampliamente que ULID o Snowflake, pero ofrece una semántica distinta: la marca de tiempo se decodifica fácilmente a un segundo legible por humanos (útil en registros y depuración), y la porción aleatoria de 96 bits es lo suficientemente grande como para que múltiples KSUID generados en el mismo segundo tengan efectivamente una probabilidad de duplicación cero sin coordinación de secuencia. A diferencia de Snowflake, KSUID no requiere coordinación de identificación de trabajadores ni asignación central. KSUID opera en segundos en lugar de milisegundos, por lo que múltiples ID dentro de un segundo se ordenan aleatoriamente a menos que implemente lógica adicional.
UUIDv7: la respuesta de seguimiento de estándares que se adapta a las columnas y herramientas de uuid existentes
RFC 9562 v7 es un identificador de 128 bits que consta de una marca de tiempo de milisegundos Unix de 48 bits, 12 bits de precisión de submilisegundos (utilizables como contador de secuencia) y 62 bits aleatorios, todos combinados. Ordena correctamente como cadena lexicográfica y como bytes de 128 bits en bases de datos. Fundamentalmente, es un UUID válido: establece la versión nibble en 7 y los bits variantes en el estándar RFC 9562, lo que lo hace compatible con todas las herramientas, columnas de bases de datos y API que manejan UUID. No se necesita conversión de codificación y la infraestructura UUID existente no requiere modificación. Si se generan varios identificadores v7 en el mismo milisegundo, RFC 9562 recomienda utilizar el campo de submilisegundo como contador monótono en lugar de bits aleatorios. V7 representa una elección pragmática para mantener la compatibilidad con UUID.
Monotonicidad en un milisegundo: cómo cada formato maneja las ráfagas y por qué es importante para las garantías de pedido
La monotonicidad es la propiedad de que si dos eventos ocurren en orden observable, sus ID se comparan en ese mismo orden. En el nivel de granularidad de milisegundos en el hardware moderno, ocurren múltiples eventos de manera rutinaria dentro del mismo tic de reloj, por lo que cualquier esquema de identificación ordenable debe manejar correctamente el orden de submilisegundos. ULID ofrece un modo monótono explícito donde la porción aleatoria aumenta en lugar de aleatorizarse. Snowflake incluye un número de secuencia de 12 bits que se incrementa en un milisegundo. KSUID carece de un mecanismo integrado, por lo que los eventos de menos de un segundo se ordenan aleatoriamente a menos que se agregue lógica adicional. RFC 9562 v7 recomienda utilizar el campo de submilisegundos como contador monótono. Si su sistema genera miles de UUID por segundo, la monotonicidad dentro de un milisegundo afecta significativamente el orden de las consultas.
Lo que esto no cubre: puntos de referencia de rendimiento, que dependen del hardware y el idioma; la publicación sigue siendo cualitativa
Los puntos de referencia de rendimiento y los datos de rendimiento no se incluyen porque dependen en gran medida de la arquitectura del hardware, la implementación del lenguaje, el motor de base de datos y la estrategia de almacenamiento en caché. Las características de rendimiento de la base de datos varían significativamente según se miden inserciones aleatorias, consultas de rango, sobrecarga de índice o rendimiento total bajo una carga de producción realista. La publicación sigue siendo cualitativa y compara formatos conceptualmente en función de sus diseños en lugar de proporcionar números específicos del entorno que podrían ser engañosos. La evaluación del desempeño en el mundo real requiere pruebas en su propio entorno con su propia carga de trabajo, base de código y limitaciones operativas. Comparar diferentes formatos de identificación es un ejercicio valioso.
Conclusión: la compatibilidad a menudo decide: el generador ToolAcre produce UUID aleatorios; use su verificación bien formada para confirmar que un UUIDv7 de su biblioteca se analiza como UUID
La compatibilidad a menudo decide qué formato elegir. Si el esquema de su base de datos ya requiere UUID columnas, la versión 7 es la respuesta moderna a la ordenación sin salir del ecosistema UUID. Si se construye un nuevo sistema con tipos de ID personalizados, ULID ofrece una representación de texto más pequeña y ventajas de precisión de milisegundos. Si necesita almacenamiento de 64 bits y puede gestionar la coordinación de la identificación de los trabajadores mediante una asignación centralizada, Snowflake es una opción comprobada en sistemas de gran volumen. La compensación fundamental es entre la compatibilidad estándar (elija v7) y propiedades alternativas como un tamaño más pequeño (Snowflake) o legibilidad base32 (ULID). Tomar decisiones basadas en las limitaciones del sistema y las decisiones del ecosistema.