.net - error - Riesgo de colisión UUID utilizando diferentes algoritmos.
sql uuid (2)
Tengo una base de datos donde 2 (o quizás 3 o 4) aplicaciones diferentes están insertando información. La nueva información tiene ID del tipo GUID / UUID, pero cada aplicación está utilizando un algoritmo diferente para generar los ID. Por ejemplo, uno está usando el "guid.comb" de NHibernate, otro está usando el NEWID () del SQLServer, otro puede querer usar la implementación Guid.NewGuid () de .NET.
¿Existe un riesgo por encima de lo normal de colisión de identificación o duplicados?
¡Gracias!
El riesgo de colisiones se eleva ligeramente, pero sigue siendo muy pequeño. Considere eso:
Tanto Comb como
NEWID/NEWSEQUENTIALIDincluyen una marca de tiempo con una precisión de hasta unos pocos ms † . Por lo tanto, a menos que esté generando una gran cantidad de ID en el mismo momento exacto de todas estas fuentes diferentes, es literalmente imposible que las ID colisionen.La parte del GUID que no se basa en la marca de tiempo puede considerarse aleatoria; la mayoría de los algoritmos GUID basan estos dígitos en un PRNG. Por lo tanto, la probabilidad de una colisión entre estos otros 10 bytes más o menos está en el mismo orden que si utilizara dos generadores de números aleatorios separados y observara las colisiones.
Piense en esto por un momento: los PRNG pueden repetir números y así lo hacen, por lo que la probabilidad de una colisión entre dos de ellos no es significativamente mayor que la de uno solo, incluso si usan algoritmos ligeramente diferentes. Es como jugar los mismos números de lotería todas las semanas en lugar de elegir un grupo al azar cada semana. Las probabilidades de ganar son exactamente las mismas.
Ahora, tenga en cuenta que cuando utiliza un algoritmo como Guid.Comb, solo tiene 10 bits de uniqueifier, lo que equivale a 1024 valores separados. Por lo tanto, si genera una gran cantidad de GUID en los mismos milisegundos, obtendrá colisiones. Pero si genera GUID con una frecuencia bastante baja, realmente no importa cuántos algoritmos diferentes utilice al mismo tiempo, la probabilidad de una colisión sigue siendo prácticamente inexistente.
La mejor manera de estar absolutamente seguro es realizar una prueba; haga que todos los 2 o 3 (o los muchos que use) generen GUID, al mismo tiempo, a intervalos regulares, y escríbalos en un archivo de registro, y vea si tiene colisiones (y si es así, cuántos). Eso debería darle una buena idea de qué tan seguro es esto en la práctica.
PD: si está utilizando el generador de peines de NHibernate para generar GUID para una clave primaria agrupada, considere usar NEWSEQUENTIALID() lugar de NEWID() : todo el punto de Comb es evitar las divisiones de páginas, y no lo logrará si tiene Otros procesos que utilizan algoritmos no secuenciales. También debe cambiar cualquier código usando Guid.NewGuid para usar el mismo generador de Comb. El algoritmo de Comb real utilizado en NHibernate no es complicado y fácil de duplicar en su propia lógica de dominio.
† Tenga en cuenta que parece haber alguna disputa sobre NEWID y si contiene o no una marca de tiempo. En cualquier caso, dado que se basa en la dirección MAC, el rango de valores posibles es considerablemente más pequeño que el de un GUID V4 o un Comb. Otra razón para recomendar que se pegue a los GUID de Comb fuera de la base de datos y a NEWSEQUENTIALID dentro de la base de datos.
Sí, el riesgo está por encima de lo normal, porque todos estos utilizan diferentes definiciones de "GUID". Guid.NewGuid () es un GUID mayormente aleatorio compatible con RFC, pero NEWSEQUENTIALID es un GUID reordenado (y por lo tanto no compatible con RFC) basado en la dirección MAC y la marca de tiempo, y el GUID de peine de NHibernate es completamente diferente (basado en la aleatoriedad y la marca de tiempo ).
Es posible que desee considerar solo la estandarización en una implementación GUID. Utilizo mi propio tipo de GUID combinado para todas mis aplicaciones. Mi blog tiene descripciones breves de todos estos tipos de GUID, junto con decisiones de diseño para mí.