¿Cuál es el tipo de columna UUID más eficiente?

15

Para almacenar un UUID de 128 bits, hay varias opciones de almacenamiento:

una columna de byte [16]
dos columnas bigint / long (64 bits)
una columna CHAR (36) - 32 dígitos hexadecimales + 4 guiones.
una columna específica de la base de datos UUID, si db lo admite

Desde el punto de vista de la indexación, ¿cuáles son los más eficientes? Si la base de datos no admite un tipo de uuid dedicado, ¿cuáles de 1, 2, 3 son los mejores candidatos?

— Vlad Mihalcea
fuente

1

Esto es un poco demasiado "depende": muchos detalles de implementación.

— Craig Ringer

2

Nunca elegiría 3: nunca almacene algo en 36 bytes cuando se pueda hacer en 16. Lo uso raw(16)en Oracle y uuiden PostgreSQL.

— Colin 't Hart

1

cuanto más simple, mejor.

— akuzminsky

uuid>> bytea>> textcon CHECKrestricción> varchar(36)>> char(36). Ver: dba.stackexchange.com/a/89433/3684 y dba.stackexchange.com/a/115316/3684 .

— Erwin Brandstetter

15

Un uuidtipo dedicado es su mejor apuesta para PostgreSQL. Difícil de decir con otros DB: no es imposible que alguien implique un uuidtipo que se almacena de manera menos eficiente que un tipo de byte simple.

Nuevamente en PostgreSQL, byteasería una forma razonable de almacenar UUID si no tuviera el uuidtipo. Para otros DB depende de cómo almacenan los datos binarios.

Siempre que sea posible, evitaría utilizar hex-with-guiones. Es mucho menos eficiente comparar, ordenar y almacenar.

Así que realmente, "no (2) o (3)". Nunca. Utilice (4) donde sea compatible, (1) de lo contrario.

— Craig Ringer
fuente

Una cosa a tener en cuenta es que el tipo UUID de PostgreSQL no se admite de forma nativa en las matrices o ¿se ha solucionado? postgresql.org/message-id/…

— Christophe Roussy el

@ChristopheRoussy Eso es de 2013. Fue un descuido menor. SELECT ARRAY['ef1e0638-072e-4caa-88b3-97bfa5b2e8c3']::uuid[]

— Craig Ringer el

3

En orden de preferencia: 4,1,2,3 No use UUID como clave de agrupación si usa el servidor SQL, ya que no solo se fragmentará mal, la clave de agrupación se usa en todos los índices no agrupados y agregaría esos bytes a cada fila de índice. La fragmentación se puede mitigar utilizando NEWSEQUENTIALID, pero generalmente prefiere una identidad de bingint para su Clustering Key sobre un GUID para evitar la hinchazón en otros índices.

La diferencia entre elegir 1 sobre 2 dependerá de cuán más eficiente sea la base de datos para manejar dos columnas de tipos básicos sobre una matriz fija de una sola columna. Debería ser lo suficientemente fácil de probar con datos ficticios. Observe la velocidad de sus consultas, así como el tamaño de los índices y los datos. Pequeño + rápido es lo mejor!

— GilesDMiddleton
fuente

1

Uno debería suponer que cualquier tipo de datos con soporte nativo estaría mejor optimizado en el producto que cualquier cosa que se pueda reunir como cliente de ese producto. Después de eso, lo que tenga el recuento de bytes más pequeño para que obtenga las filas máximas por página.

— Michael Green
fuente

Es cierto, pero ¿es solo el tamaño del byte lo que importa? ¿El tipo no afecta el algoritmo de indexación?

— Vlad Mihalcea

@Vlad Yo uso SQL Server. AFAIK todos los tipos de datos se manejan de la misma manera cuando se construye un árbol B (o un índice hash para 2104 en memoria). Hay buenas razones para mantener esto lo más estrecho posible.

— Michael Green