Tenga en cuenta que hay una publicación de seguimiento más actualizada aquí: Almacenamiento de UUID y columnas generadas

Hace unos años, Peter Zaitsev escribió en una publicación titulada «UUID o no UUID»: «Hay una parte basada en la marca de tiempo en UUID que tiene propiedades similares a auto_increment y que podría usarse para tener valores generados en el mismo punto en el tiempo físicamente local en el índice BTREE».

Para esta publicación, he reorganizado la parte de la marca de tiempo de UUID (identificador único universal) e hizo algunos puntos de referencia.

Mucha gente ve el UUID como un carácter (36) y lo usa como un valor de identidad de fila (CLAVE PRIMARIA) porque es único en cada tabla, cada base de datos y cada servidor y permite combinar fácilmente registros de diferentes bases de datos. Pero aquí viene el problema, usarlo como PRIMARY KEY provoca los problemas que se describen a continuación.

Problemas con UUID

• El UUID tiene 36 caracteres que lo hacen voluminoso.
• InnoDB almacena los datos en el orden PRIMARY KEY y todas las claves secundarias también contienen PRIMARY KEY. Luego, tener UUID como CLAVE PRINCIPAL hace que el índice sea más grande para que no se pueda insertar en la memoria
• Las inserciones son aleatorias y los datos están dispersos.

A pesar de los problemas con UUID, la gente todavía lo prefiere porque es ÚNICO en cada tabla, se puede generar en cualquier lugar. En este blog, explicaré cómo almacenar UUID de manera efectiva reorganizando la parte de marca de tiempo de UUID.

estructura UUID

MySQL usa UUID versión 1, que es un número de 128 bits representado por una cadena utf8 de cinco números hexadecimales.

• Los primeros tres números son generados por una marca de tiempo.
• El cuarto número conserva la unicidad temporal en caso de que el valor de la marca de tiempo pierda su monotonicidad (por ejemplo, debido a la hora del día).
• El quinto número es un número de nodo IEEE 802 que proporciona unicidad espacial. Se reemplaza un número aleatorio si este último no está disponible (por ejemplo, porque la computadora host no tiene una tarjeta Ethernet, o no sabemos cómo encontrar la dirección de hardware de una interfaz en su sistema operativo). En este caso, no se puede garantizar la unicidad espacial. Sin embargo, una colisión debe tener una probabilidad muy baja.

La marca de tiempo se asigna de la siguiente manera:

Cuando la marca de tiempo tiene el valor hexadecimal (60 bits): 1d8eebc58e0a7d7. Se establecen las siguientes partes del UUID: 58e0a7d7–eebc–11d8-9669-0800200c9a66. tu 1 antes de que los números más significativos (en 11d8) de la marca de tiempo indiquen la versión de UUID, para los UUID basados ​​en tiempo es 1.

Las partes cuarta y quinta serán en su mayoría constantes si son generadas por un solo servidor. Los tres primeros números se basan en la marca de tiempo, por lo que deben aumentar de forma monótona. Reorganizamos toda la secuencia al acercar el UUID a la secuencia. Esto hace que publicar y recuperar datos recientes sea más rápido. Los guiones (‘-‘) no tienen sentido, así que los eliminamos.
58e0a7d7-eebc-11d8-9669-0800200c9a66 => 11d8eebc58e0a7d796690800200c9a66

evaluación comparativa

Creé tres tablas.

• events_uuid – UUID binario (16) CLAVE PRINCIPAL
• events_int: columna de incremento automático BIGINT adicional y hacerlo como clave principal e índice en la columna UUID
• events_uuid_ordered – Reorganizar el UUID binario (16) como CLAVE PRINCIPAL

Creé tres procedimientos almacenados que insertan archivos aleatorios de 25K a la vez en las tablas respectivas. Hay tres procedimientos almacenados más que requieren procedimientos de inserción aleatorios en un ciclo y también calculan el tiempo necesario para insertar 25 000 filas y datos y el tamaño del índice después de cada ciclo. En total, inserté 25 millones de discos.

• • Tamaño de datos
    Eje Horizontal – Número de inserciones x 25.000
    Eje vertical: datos de tamaño en MB

    El tamaño de los datos de la tabla UUID es mayor que el de las otras dos tablas.

  • Tamaño del índice
    Eje horizontal – Número de inserciones x 25.000
    Eje vertical – Tamaño del índice en MB
    
  • Tamaño total
    Eje Horizontal – Número de inserciones x 25.000
    Eje vertical – Tamaño total en MB
    
  • Tiempo tomado
    Eje horizontal – Número de inserciones x 25.000
    Eje vertical – Tiempo tomado en segundos
    

Para la tabla con UUID como PRIMARY KEY, puede notar que a medida que la tabla crece, el tiempo necesario para insertar filas aumenta casi linealmente. Mientras que para otras mesas, el tiempo empleado es casi constante.

El tamaño de la tabla UUID es casi un 50 % más grande que la tabla UUID solicitada y un 30 % más grande que la tabla con BIGINT como PRIMARY KEY. Comparando la tabla UUID de la tabla BIGINT, el tiempo necesario para insertar las filas y el tamaño son casi iguales. Pero pueden variar ligeramente dependiendo de la estructura del índice.

Estructura de la mesa

Conclusiones para el almacenamiento de valores UUID

• • Crear una función para reorganizar los campos UUID y usarlos

anuncios

Seleccione

• • Definir UUID como binario (16) como binario no tiene un conjunto de caracteres

Referencias