Ventajas y desventajas de las claves de base de datos GUID / UUID

222

He trabajado en varios sistemas de bases de datos en el pasado donde mover entradas entre bases de datos habría sido mucho más fácil si todas las claves de la base de datos hubieran sido valores GUID / UUID . He considerado seguir este camino varias veces, pero siempre hay un poco de incertidumbre, especialmente en lo que respecta al rendimiento y a las URL que no se pueden leer por teléfono.

¿Alguien ha trabajado mucho con GUID en una base de datos? ¿Qué ventajas obtendría al ir por ese camino y cuáles son las posibles trampas?

Matt Sheppard
fuente
1
Jeff tiene una publicación al respecto " Claves primarias: ID frente a GUID ".
jfs
1
también puede usar Hi-Lo para clientes remotos: stackoverflow.com/questions/282099/whats-the-hi-lo-algorithm
Neil McGuigan
Ubicación actualizada para la publicación de Jeff Atwood sobre " Claves primarias: ID versus GUID ". Gracias a @jfs por la referencia.
Adam Katz

Respuestas:

229

Ventajas:

  • Puede generarlos sin conexión.
  • Hace que la replicación sea trivial (a diferencia de int, lo que lo hace REALMENTE difícil)
  • ORM generalmente les gusta
  • Único en todas las aplicaciones. Entonces, podemos usar los PK de nuestro CMS (guid) en nuestra aplicación (también guid) y saber que NUNCA vamos a tener un choque.

Desventajas

  • Mayor uso del espacio, pero el espacio es barato (er)
  • No se puede ordenar por ID para obtener el orden de inserción.
  • Puede parecer feo en una URL, pero realmente, ¿qué está haciendo WTF poniendo una clave REAL DB en una URL? (Este punto se discute en los comentarios a continuación)
  • Es más difícil hacer la depuración manual, pero no es tan difícil.

Personalmente, los uso para la mayoría de los PK en cualquier sistema de un tamaño decente, pero me "entrené" en un sistema que fue replicado en todo el lugar, así que TENÍAMOS que tenerlos. YMMV.

Creo que lo de los datos duplicados es basura: puedes obtener datos duplicados como lo hagas. Las claves sustitutas generalmente están mal vistas dondequiera que haya estado trabajando. Sin embargo, utilizamos el sistema similar a WordPress:

  • ID único para la fila (GUID / lo que sea). Nunca visible para el usuario.
  • La ID pública se genera UNA VEZ desde algún campo (por ejemplo, el título; conviértalo en el título del artículo)

ACTUALIZACIÓN: Así que este obtiene +1 'mucho, y pensé que debería señalar un gran inconveniente de GUID PK's: Clustered Indexes.

Si tiene muchos registros y un índice agrupado en un GUID, su rendimiento de inserción SUGERIRÁ, ya que obtendrá inserciones en lugares aleatorios en la lista de elementos (ese es el punto), no al final (que es rápido)

Entonces, si necesita un rendimiento de inserción, tal vez use un INT de autoinc y genere un GUID si desea compartirlo con otra persona (es decir, mostrarlo a un usuario en una URL)

Nic Wise
fuente
184
[¿¡WTF estás haciendo poner una clave REAL DB en una URL !?] No estoy seguro de por qué eso te molesta. ¿Qué más usarías? Mire el desbordamiento de pila ... Tiene valores de IDENTIDAD en la URL por todas partes, y funciona bien. El uso de claves DB en las URL no le impide hacer cumplir la seguridad.
Euro Micelli
20
No, no lo hace, pero cosas como el SEO generalmente son mejores si no hay una clave, especialmente algo tan largo como un GUID. Por supuesto, se puede solucionar fácilmente, así que supongo que fue un poco exagerado
Nic Wise
77
Buena respuesta, sería bueno si también agrega información sobre las desventajas de rendimiento del uso de GUID; por ejemplo, unirlos, ordenarlos e indexarlos será más lento que usar números enteros. Las guías son fantásticas, pero tienen un costo que puede ser una molestia cuando el rendimiento es crítico.
Doctor Jones
26
Tenga en cuenta una cosa, las personas a menudo cambian los títulos de las páginas, las preguntas y los foros. Para SEO, es BUENO tener algo así como una pequeña ID en la URL, de modo que si el título cambia, todavía se sabe dónde reenviar a las personas que provienen de una URL ANTIGUA example.com/35/old-and-bustedacaba de convertirse example.com/35/new-hotnessy su aplicación puede verificar el título y reenviar al usuario con un 301.
Xeoncross
99
La indexación de un GUID es costosa y lenta, lo que los convierte en candidatos realmente pobres para las claves primarias.
Matthew James Davis
14

@ Matt Sheppard:

Digamos que tienes una mesa de clientes. Seguramente no desea que exista un cliente en la tabla más de una vez, o sucederá mucha confusión en sus departamentos de ventas y logística (especialmente si las múltiples filas sobre el cliente contienen información diferente).

Por lo tanto, tiene un identificador de cliente que identifica al cliente de forma exclusiva y se asegura de que el cliente lo conozca (en las facturas), de modo que el cliente y el personal de servicio al cliente tengan una referencia común en caso de que necesiten comunicarse. Para garantizar que no haya registros de clientes duplicados, agregue una restricción de unicidad a la tabla, ya sea a través de una clave primaria en el identificador del cliente o mediante una restricción NOT NULL + UNIQUE en la columna del identificador del cliente.

A continuación, por alguna razón (que no se me ocurre), se le pide que agregue una columna GUID a la tabla de clientes y que sea la clave principal. Si la columna de identificador de cliente ahora queda sin una garantía de unicidad, está solicitando problemas futuros en toda la organización porque los GUID siempre serán únicos.

Algún "arquitecto" podría decirle que "¡oh, pero manejamos la restricción de unicidad real del cliente en nuestro nivel de aplicación!". Correcto. La moda con respecto a los lenguajes de programación de propósito general y (especialmente) los marcos de nivel medio cambia todo el tiempo y, en general, nunca sobrevivirá a su base de datos. Y hay muchas posibilidades de que en algún momento necesite acceder a la base de datos sin pasar por la aplicación actual. == Problemas. (Pero afortunadamente, usted y el "arquitecto" se han ido hace mucho tiempo, por lo que no estará allí para limpiar el desorden). En otras palabras: mantenga restricciones obvias en la base de datos (y también en otros niveles, si tiene el tiempo).

En otras palabras: puede haber buenas razones para agregar columnas GUID a las tablas, pero no caiga en la tentación de reducir sus ambiciones de coherencia dentro de la información real (== no GUID).

Troels Arvin
fuente
1
¡Escucha Escucha! Me encanta tu página de comparación de SQL por cierto. Extremadamente útil. Lo único que extraño es un registro de cambios.
Henrik Gustafsson
3
Creo que esta respuesta necesita alguna aclaración: esto supone que los UUID nunca se usan como claves principales. No sé de dónde viene esta suposición, pero aún no he visto un sistema que no le permita usarlos como tal. Sé que es una respuesta antigua, supongo que las ventajas de usar UUID en sistemas distribuidos no se entendían tan ampliamente en ese entonces (?).
TNE
12

¿Por qué nadie menciona el rendimiento? Cuando tiene múltiples combinaciones, todas basadas en estos desagradables GUID, el rendimiento irá por el suelo, allí :(

Andrei Rînea
fuente
1
¿Puede explicar esto como estoy en la situación en la que necesito introducir UUID (o similar), pero me preocupa usarlos como clave principal?
JoeTidee
1
Los UUID son solo 4 veces el tamaño de los enteros ... (si su base de datos tiene un tipo de UUID)
Jasen
11

Los GUID pueden causarle muchos problemas en el futuro si se usan como "unificadores", permitiendo que los datos duplicados entren en sus tablas. Si desea usar GUID, considere seguir manteniendo restricciones ÚNICAS en otras columnas.

Troels Arvin
fuente
11
Este es el corazón del problema: la introducción de un GUID hace que cualquier fila sea única. Pero las partes no artificiales de las filas pueden contener repentinamente duplicados (varias versiones de la verdad).
Troels Arvin el
8
+1 para compensar. Entiendo lo que quieres decir, pero está mal expresado.
Stefano Borini
11

Las principales ventajas son que puede crear identificadores únicos sin conectarse a la base de datos. Y los ID son globalmente únicos, por lo que puede combinar fácilmente datos de diferentes bases de datos. Estas parecen pequeñas ventajas, pero me han ahorrado mucho trabajo en el pasado.

Las principales desventajas son un poco más de almacenamiento necesario (no es un problema en los sistemas modernos) y los ID no son realmente legibles para los humanos. Esto puede ser un problema al depurar.

Hay algunos problemas de rendimiento como la fragmentación del índice. Pero esos son fácilmente solucionables (guías de peine por Jimmy Nillson: http://www.informit.com/articles/article.aspx?p=25862 )

Editar fusionó mis dos respuestas a esta pregunta

@ Matt Sheppard Creo que quiere decir que puede duplicar filas con diferentes GUID como claves principales. Este es un problema con cualquier tipo de clave sustituta, no solo los GUID. Y, como dijo, se resuelve fácilmente agregando restricciones únicas significativas a columnas sin clave. La alternativa es utilizar una clave natural y esas tienen problemas reales.

Mendelt
fuente
Sé sobre las guías de peine y aquellas que ayudan a resolver el problema de indexación (INSERTAR el rendimiento). "Las principales desventajas son un poco más de almacenamiento necesario " ¿Esto afectará el rendimiento debido al gran tamaño del archivo de la base de datos?
Amit Joshi
8

Otro pequeño problema a considerar con el uso de GUIDS como claves principales si también está usando esa columna como un índice agrupado (una práctica relativamente común). Vas a recibir un golpe en la inserción debido a que la naturaleza de un guid no comienza de manera secuencial, por lo que habrá divisiones de página, etc. cuando insertes. Solo algo a considerar si el sistema va a tener un alto IO ...

WIDBA
fuente
6

Primary-Keys-ID-versus-Guids

El costo de los GUID como claves principales (SQL Server 2000)

Mitos, GUID vs. Aumento automático (MySQL 5)

Esto es realmente lo que quieres.

UID Pros

  • Único en cada tabla, cada base de datos, cada servidor
  • Permite combinar fácilmente registros de diferentes bases de datos
  • Permite una fácil distribución de bases de datos en múltiples servidores
  • Puede generar ID en cualquier lugar, en lugar de tener que hacer un viaje de ida y vuelta a la base de datos
  • La mayoría de los escenarios de replicación requieren columnas GUID de todos modos

Contras GUID

  • Es la friolera de 4 veces más grande que el valor de índice tradicional de 4 bytes; Esto puede tener serias implicaciones de rendimiento y almacenamiento si no tiene cuidado
  • Incómodo de depurar (donde userid = '{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
  • Los GUID generados deben ser parcialmente secuenciales para obtener el mejor rendimiento (por ejemplo, newsequentialid () en SQL 2005) y para permitir el uso de índices agrupados
Wener
fuente
1

Hay una cosa que realmente no se aborda, es decir, el uso de ID aleatorios (UUIDv4) como claves primarias dañará el rendimiento del índice de clave primaria . Sucederá independientemente de si su tabla está agrupada alrededor de la clave.

Los RDBM generalmente aseguran la unicidad de las claves primarias, y aseguran las búsquedas por clave, en una estructura llamada BTree, que es un árbol de búsqueda con un gran factor de ramificación (un árbol de búsqueda binario tiene un factor de ramificación de 2). Ahora, una ID entera secuencial causaría que las inserciones ocurran solo una lado del árbol, dejando la mayoría de los nodos de hoja intactos. Agregar UUID aleatorios hará que las inserciones dividan los nodos hoja en todo el índice.

Del mismo modo, si los datos almacenados son en su mayoría temporales, a menudo es necesario acceder a los datos más recientes y unirlos con la mayoría. Con UUID aleatorios, los patrones no se beneficiarán de esto, y alcanzarán más filas de índice, por lo que necesitarán más de las páginas de índice en la memoria. Con ID secuenciales si la información más reciente es la que más se necesita, las páginas de índice en caliente requerirían menos RAM.

Antti Haapala
fuente