Cuando son realmente obligados a usar UUID como parte del diseño?

https://stackoverflow.com/questions/703035

22-08-2019
|

Pregunta

Yo realmente no veo el punto de UUID.Sé que la probabilidad de una colisión es efectivamente nula, pero efectivamente nula no es ni cerca de lo imposible.

Puede alguien dar un ejemplo donde usted no tiene ninguna opción pero para usar UUID?De todos los usos que he visto, puedo ver una alternativa de diseño sin UUID.Asegurarse de que el diseño podría ser un poco más complicado, pero al menos no tiene una probabilidad no nula de error.

UUID huele a variables globales para mí.Hay muchas maneras en las variables globales hacer para diseño más simple, pero su pereza diseño.

Solución

escribí el UUID generador / analizador para Ruby, por lo que me considero razonablemente bien informados sobre el tema. Hay cuatro versiones de UUID:

versión 4 UUID son esencialmente sólo 16 bytes de aleatoriedad extraídos de un generador criptográficamente seguro de números aleatorios, con un poco de bit-haciendo girar para identificar la versión UUID y variante. Estos son extremadamente poco probable que chocan, pero podría suceder si se utiliza un PRNG o si simplemente sucede que tiene muy, muy, muy, muy, muy mala suerte.

Versión 5 y Versión 3 UUID utilizar las funciones de hash MD5 SHA1 y respectivamente, para combinar un espacio de nombres con un trozo de datos ya únicas para generar un UUID. Esto, por ejemplo, permitirá producir un UUID de una URL. Las colisiones aquí sólo son posibles si la función de hash subyacente también tiene una colisión.

Versión 1 UUID son los más comunes. Utilizan la dirección de la tarjeta de red MAC (que a menos falsa, debe ser único), además de una marca de tiempo, además de la habitual de bits haciendo girar para generar el UUID. En el caso de una máquina que no tiene una dirección MAC, los 6 bytes de nodo se generan con un generador criptográficamente seguro de números aleatorios. Si dos UUID se generan en la secuencia lo suficientemente rápido que la marca de tiempo coincide con el UUID anterior, la marca de tiempo se incrementa en 1. Las colisiones no debe ocurrir a menos que una de las situaciones siguientes: La dirección MAC es falsa; Una máquina que ejecuta dos aplicaciones de generación de UUID diferentes produce UUID en el mismo momento exacto; Dos máquinas sin una tarjeta de red o sin acceso a nivel de usuario a la dirección MAC se les da la misma secuencia de nodo de azar, y generan UUID en el mismo momento exacto; Nos quedamos sin bytes para representar la marca de tiempo y el vuelco de nuevo a cero.

Siendo realistas, ninguno de estos eventos ocurren por accidente dentro de un espacio de identificación de una sola aplicación. A menos que usted está aceptando los ID en, por ejemplo, una escala de Internet, o con un entorno sin confianza en que personas malintencionadas podrían ser capaces de hacer algo malo en el caso de una colisión de identificación, que no es sólo algo que debe preocuparse. Es fundamental entender que si quieres pasar a generar la misma versión 4 UUID como yo, en la mayoría de los casos, no importa. He generado el ID de ID en un espacio completamente diferente a la suya. Mi solicitud no tendrá conocimiento de la colisión por lo que la colisión no importa. Francamente, en un solo espacio de aplicaciones sin agentes maliciosos, la extinción de toda la vida en la tierra ocurrirá mucho antes de que usted tiene una colisión, incluso en un UUID la versión 4, incluso si se está generando bastantes UUID por segundo.

También, 2 ^ 64 * 16 es de 256 exabytes. Al igual que en, lo que se necesita para almacenar 256 exabytes por un valor de ID antes de tener una probabilidad del 50% de una colisión de identificación en un solo espacio de aplicación.

Otros consejos

La cosa que los Uuid comprar que es muy difícil hacerlo de otra manera es obtener un identificador único sin tener que consultar o coordinar con la autoridad central.El problema general de ser capaz de conseguir tal cosa sin algún tipo de infraestructura gestionada es el problema el Uuid de resolver.

He leído que de acuerdo a la paradoja de cumpleaños la posibilidad de un UUID de la colisión se produzca es del 50% una vez que 2^64 Uuid se han generado.Ahora 2^64 es un número bastante grande, pero un 50% de probabilidad de colisión parece demasiado arriesgado (por ejemplo, cuántas Uuid deben existir antes de que haya un 5% de probabilidad de colisión, incluso, que parece demasiado grande de una probabilidad).

El problema con que el análisis es doble:

Los uuid no son completamente aleatorios no son los principales componentes de la UUID que son el tiempo y/o basados en la ubicación.Así que para tener alguna oportunidad real de una colisión, la colisión de los Uuid necesidad de tobe generado en el exacto mismo tiempo desde diferentes UUID de los generadores.Yo diría que mientras exista una posibilidad razonable de que varios UUID puede ser generado al mismo tiempo, hay bastante similares (incluyendo información de ubicación o de bits aleatorios) para hacer el likeyhood de una colisión entre este conjunto muy pequeño de los Uuid casi imposible.
estrictamente hablando, Uuid sólo necesita ser único entre el conjunto de otros Uuid que podría ser comparado contra.Si estás generando un UUID para el uso como una base de datos de la clave, no importa si en alguna otra parte en un mal universo alternativo que el mismo UUID se utiliza para identificar una interfaz COM.Como va a causar ningún tipo de confusión si hay alguien (o algo) más el nombre "Michael Burr" en Alfa Centauri.

Todo tiene un no-cero posibilidades de fracaso. Me gustaría concentrarse en mucho más probable que se produzcan problemas (es decir, casi cualquier cosa que se pueda imaginar) que la colisión de los UUID

Un énfasis en "razonablemente" o, como usted dice, "efectivamente": es lo suficientemente bueno como funciona el mundo real. La cantidad de trabajo computacional involucrada en cubrir la brecha entre "prácticamente único" y "única" es enorme. Singularidad es una curva con rendimientos decrecientes. En algún punto de esa curva, hay una línea entre el lugar donde "lo suficientemente única" todavía es asequible, y luego curva muy pronunciada. El coste de la adición de más singularidad se hace muy grande. singularidad infinita tiene un costo infinito.

UUID / GUID es, relativamente hablando, una forma computacionalmente rápida y fácil de generar una identificación que puede ser razonablemente supone que es único universal. Esto es muy importante en muchos sistemas que necesitan integrar datos de los sistemas previamente inconexos. Por ejemplo: si usted tiene un gestor de contenidos que se ejecuta en dos plataformas diferentes, pero en algún momento hay que importar el contenido de un sistema al otro. Usted no quiere identificadores para cambiar, por lo que sus referencias entre los datos de sistema Un permanecen intactos, pero no quieren tener colisiones con los datos creados en el sistema B. Un UUID resuelve este.

Nunca es absolutamente necesario para crear un UUID. Es, sin embargo conveniente tener una norma donde línea usuarios cada uno puede generar una clave de algo con una muy baja probabilidad de colisión.

Esto puede ayudar en la resolución de la replicación de bases de datos, etc ...

Sería fácil para línea a los usuarios generar claves únicas para algo sin la sobrecarga o la posibilidad de colisión, pero eso no es lo que son para los UUID.

En cualquier caso, unas palabras sobre la probabilidad de colisión, tomada de Wikipedia:

Para poner estas cifras en perspectiva, uno de riesgo anual de ser golpeado por un meteorito se estima que es una posibilidad entre 17 mil millones, lo que equivale a las posibilidades de creación de unas pocas decenas de billones de UUID en un año y que tiene un duplicado. En otras palabras, sólo después de la generación de 1 mil millones UUID cada segundo durante los próximos 100 años, la probabilidad de crear sólo un duplicado sería de alrededor de 50%.

También hay una probabilidad no nula de que cada partícula de su cuerpo túnel simultáneamente a través de la silla en la que está sentado en y de repente se encontrará sentado en el suelo.

¿Le preocupa eso?

Un ejemplo clásico es cuando se va a replicar entre dos bases de datos.

DB (A) inserta un registro con int ID 10 y, al mismo tiempo DB (B) crea una un registro con en ID 10. Se trata de una colisión.

Con UUID esto no sucederá, ya que no coincidirán. (Casi seguro)

Tengo un esquema para evitar UUID. Configurar un servidor en algún lugar y tenerlo de manera que cada vez que un pedazo de software quiere un identificador único universal, que en contacto con el servidor y se da un out. Simple!

A excepción de que hay algunos problemas prácticos reales con esto, incluso si ignoramos la malicia pura y simple. En particular, ese servidor puede fallar o inalcanzable de la parte de internet. Se trata de un fallo del servidor requiere la replicación, y eso es muy difícil para tener derecho (véase la bibliografía sobre el algoritmo de Paxos de por qué la creación de consenso es torpe) y es bastante lento también. Por otra parte, si todos los servidores son inalcanzables de una parte determinada de la 'red, no de los clientes conectados a la subred será capaz de hacer cualquier cosa, porque todos ellos estarán a la espera de nuevos documentos de identidad.

Así que ... usar un simple algoritmo probabilístico para generarlos que es poco probable a fallar durante el tiempo de vida de la Tierra, o (fondos y) construir una infraestructura importante que va a ser un despliegue PITA y tienen frecuentes fracasos. Yo sé cuál me gustaría ir para.

Si sólo se observa en las alternativas, por ejemplo, para una aplicación de base de datos simple, tener que consultar la base de datos cada vez que antes de crear un nuevo objeto, pronto se dará cuenta que el uso de UUID puede reducir de manera efectiva a la complejidad del sistema. Por supuesto - si utiliza claves de 32 bits son el int, que almacenará en una cuarta parte de la UUID de 128 bits. Concedidos - algoritmos de generación de UUID ocupan más poder computacional que simplemente incrementando un número. ¿Pero a quién le importa? La sobrecarga de administración de una "autoridad" para asignar números únicos de lo contrario fácilmente pesa más que por órdenes de magnitud, dependiendo de su ID de espacio de exclusividad previsto.

En UUID == diseño perezoso

No estoy de acuerdo en cuanto a recoger su sus peleas. Si un UUID duplicado es estadísticamente imposible y las matemáticas se demuestra a continuación, ¿por qué preocuparse? Pasar tiempo en el diseño alrededor de su sistema de generación de UUID N pequeña es poco práctico, siempre hay una docena de otras maneras en que puede mejorar su sistema.

no consigo todo el debate sobre la probabilidad de colisión. No me importa acerca de la colisión. Me importa un rendimiento sin embargo.

https://dba.stackexchange.com/a/119129/33649

UUID son un desastre rendimiento para tablas muy grandes. (200K filas es   No "muy grande".)

Su # 3 es muy malo cuando el SET Charcter es utf8 - CHAR (36)   ocupa 108 bytes!

UUID (GUID) son muy "aleatoria". El uso de ellas, ya sea como único o una   Clave principal en tablas de gran tamaño es muy ineficiente. Esto es debido   tener que saltar alrededor de la mesa / índice cada vez que se inserta un nuevo UUID   o SELECT por UUID. Cuando la tabla / índice es demasiado grande para caber en la memoria caché   (Ver innodb_buffer_pool_size, que debe ser menor que la RAM,   típicamente 70%), el 'siguiente' UUID no puede ser almacenado en caché, por lo tanto, un disco lento   golpear. Cuando la tabla / índice es 20 veces más grande que la memoria caché, sólo 1/20   (5%) de los accesos se almacenan en caché - que son I / O-bound
.
Por lo tanto, no utilice UUID a menos que cualquiera

tiene "pequeñas" mesas, o que realmente los necesita, debido a la generación de   identificadores únicos de diferentes lugares (y no han descubierto otra forma   para hacerlo). Más sobre UUID: http://mysql.rjweb.org/doc.php/uuid (Se   incluye funciones para la conversión entre UUID estándar 36-char y   Binario (16).)

Tener tanto una AUTO_INCREMENT único y un UUID único en el mismo   tabla es un desperdicio.

Cuando se produce un INSERT, todas las claves únicas / primarias deben ser revisadas para   duplicados. De cualquier clave única es suficiente para los requerimientos de InnoDB   de tener una clave principal. Binarios (16) (16 bytes) es algo voluminoso (una   argumento en contra de lo que es el PK), pero no tan mal. la voluminosidad   que importa cuando se tiene claves secundarias. InnoDB tachuelas en silencio el PK   en el extremo de cada clave secundaria. La lección principal es   minimizar el número de claves secundarias, especialmente para los muy grandes   mesas. Para comparación: unsigned int es de 4 bytes con rango de 0..4   mil millones. BIGINT es de 8 bytes.

En mi último trabajo, nos iban a dar objetos de otros fabricantes que fueron identificados de forma única con UUID. Me pusieron en una UUID-> entero largo tabla de consulta y utilizado durante mucho tiempo entero como mis claves primarias, ya que era la manera más rápida de esa manera.

Usando el algoritmo versión 1 parece que se trata de colisión imposible bajo la restricción de que menos de 10 UUID por milisegundo se generan de la misma dirección MAC

Conceptualmente, el original (versión 1) esquema de generación de UUID era concatenar la versión con el UUID dirección MAC del ordenador que es generar el UUID, y con la número de intervalos de 100 nanosegundos desde la aprobación de la gregoriano calendario en Occidente. En la práctica, la algoritmo real es más complicada. Este esquema ha sido criticado en que no es suficientemente 'opaca'; que revela tanto la identidad de la equipo que generó el UUID y el momento en que lo hizo.

Alguien me corrija si me malinterpretado como funciona

Para los que dicen que son UUID mal diseño, ya que podría (en algún ridículamente pequeña probabilidad) chocan entre sí, mientras que su base de datos genera claves no se sabe ... la posibilidad de error humano causando una colisión en su base de datos genera claves debido a alguna necesidad no-previsto ningún dista mucho, mucho más alto que el riesgo de colisión uuid4. We saber que si el PP se recrea se iniciará en los identificadores de 1 de nuevo, y cuántos de nosotros hemos tenido que volver a crear una mesa cuando estábamos seguros de que no podríamos llegar a necesitar? Yo pondría mi dinero en seguridad UUID cuando las cosas comienza a ir mal con desconocidos-incógnitas cualquier día.

Además de los casos en los que hay que utilizar algún otro API que exige un UUID, por supuesto, siempre hay otra solución. Pero serán aquellas alternativas resolver todos los problemas que UUID? Va a terminar la adición de más capas de cortes, cada uno para resolver un problema diferente, cuando se podría haber resuelto todos ellos a la vez?

Sí, es teóricamente posible que los UUID colisionen. Como otros han señalado, es ridículamente poco probable que el punto de que simplemente no vale la pena considerar. Nunca ha sucedido hasta la fecha y muy probablemente nunca lo hará. Olvidarse de él.

La forma más "evidente" para evitar colisiones es dejar que un solo servidor generar identificadores únicos en cada inserto, lo que obviamente crea serios problemas de rendimiento y no resuelve el problema de la generación en línea en absoluto. Vaya.

La otra solución "obvia" es una autoridad central que reparte bloques de números únicos de antemano, que es esencialmente lo que UUID V1 hace utilizando la dirección MAC de la máquina generadora de (a través de la IEEE OUI). Pero duplican direcciones MAC ocurren porque cada autoridad central estropea con el tiempo, por lo que en la práctica es mucho más probable que una colisión UUID V4. Vaya.

El mejor argumento contra el uso de UUID es que son "demasiado grandes", pero un esquema (significativamente) más pequeña, inevitablemente, no es posible resolver los problemas más interesantes; tamaño UUID es un efecto secundario inherente de su utilidad en la resolución de esos mismos problemas.

Es posible que su problema no es lo suficientemente grande como para necesitar lo que ofrecen los UUID, y en ese caso, no dude en utilizar otra cosa. Pero si el problema crece de forma inesperada (y la mayoría lo hace), que va a terminar de cambiar más adelante - y patear para no usarlos en el primer lugar. ¿Por qué el diseño para el fracaso cuando es tan fácil de diseñar para el éxito en su lugar?

UUID encarnan todas las malas prácticas de codificación asociados a las variables globales, sólo que peor, ya que son las variables superglobales que se pueden distribuir a través de diferentes piezas de kit.

recientemente llegó a un problema de este tipo con la sustitución de una impresora con un modelo de reemplazo exacto, y encontraron que ninguno de los software de cliente funcionaría.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow