Beneficios y desventajas de Cassandra UUID vs TimeUUID

timestamp cassandra

Question

Dado que TimeUUID te permite usar now() en CQL, ¿hay alguna razón por la que no sigas adelante y siempre uses TimeUUID en lugar de UUID simple?

Answer 1

UUID y TIMEUUID se almacenan de la misma manera en Cassandra, y solo representan dos implementaciones de clasificación diferentes.

TIMEUUID columnas TIMEUUID se ordenan primero por sus componentes de tiempo y luego por sus bytes sin procesar, mientras que las columnas UUID se ordenan primero por su versión, luego, si ambas son la versión 1 por su componente de tiempo y, finalmente, por sus bytes sin formato. Curiosamente, las implementaciones de clasificación de componentes de tiempo se duplican entre UUIDType y TimeUUIDType en el código de Cassandra, excepto por el formato diferente.

Pienso en la pregunta UUID vs. TIMEUUID principalmente como documentación: si eliges TIMEUUID estás diciendo que estás almacenando cosas en orden cronológico, y que estas cosas pueden ocurrir al mismo tiempo, por lo que una simple marca de tiempo no es suficiente . El uso de UUID indica que no le importa el orden (incluso si en la práctica las columnas se ordenarán por tiempo si coloca los UUID de la versión 1 en ellas), solo quiere asegurarse de que las cosas tengan identificaciones únicas.

Incluso si usa NOW() para generar valores de UUID es conveniente, también es muy sorprendente para otras personas que leen su código.

Probablemente no importe mucho en el gran esquema de cosas, pero clasificar los UUID que no son de la versión 1 es un poco más rápido que la versión 1, de modo que si tiene una columna UUID y genera los UUID usted mismo, busque otra versión.

Answer 2

Un TimeUUID es un antiguo UUID simple de acuerdo con la documentación .

Un UUID es simplemente un valor de 128 bits . Piense en ello como un número inimaginablemente grande.

Los bits particulares pueden determinarse mediante cualquiera de varios métodos. El método original implicaba tomar la dirección MAC del hardware de red de la computadora, combinando la fecha y la hora actuales, más un número arbitrario y un número aleatorio. Agrupe todo eso para obtener un número virtualmente único.

Más tarde, por diversas razones (seguridad, privacidad), se inventaron otros métodos para ensamblar los bits al generar un valor de UUID. Estos otros métodos omiten la fecha y hora o la dirección MAC como ingrediente. El punto es: no todos los valores de UUID tienen un valor incrustado de fecha y hora.

El documento de Cassandra se refiere incorrectamente a que TimeUUID es un "UUID de tipo 1". El término correcto es la versión 1 UUID . Esta versión a veces se llama la "versión basada en el tiempo".

Un consejo

Cassandra parece identificar esta versión específica de UUID con el propósito de extraer la porción de fecha y hora de los 128 bits. Extraer la fecha y hora de un UUID es una mala idea .

Por un lado, UUID nunca fue pensado para ser usado para dicho seguimiento de historial. De hecho, la especificación para el UUID reconoce específicamente que (a) los relojes de la computadora pueden reiniciarse y, por lo tanto, (b) los UUID generados posteriormente pueden realmente registrar una fecha-hora anterior a los UUID anteriores. Otra razón para no extraer la fecha-hora de un UUID es porque es posible que tenga UUID que no fueron generados por el método de tiempo, por lo tanto construirá un valor de tiempo de datos basado en bits que de hecho no representan la fecha y hora de la creación Una tercera razón es que cuando el código de programación se refactoriza posteriormente, el UUID puede generarse en un momento diferente que el registro de la base de datos, por lo que usar la fecha-hora del UUID sería engañoso.

Si necesita realizar un seguimiento del historial de fecha y hora, hágalo explícitamente. Crea un campo de fecha y hora en tus datos. Por cierto, rastrea esa fecha y hora en UTC , pero ese es otro tema.