sql >> Base de Datos >  >> RDS >> Sqlserver

Riesgo de colisión de UUID usando diferentes algoritmos

El riesgo de colisiones es ligeramente elevado, pero sigue siendo muy pequeño. Considere que:

  • Tanto Comb como NEWID /NEWSEQUENTIALID incluir una marca de tiempo con una precisión de unos pocos ms. Por lo tanto, a menos que esté generando una gran cantidad de ID en el exactamente el mismo momento de todas estas fuentes diferentes, es literalmente imposible para que las identificaciones colisionen.

  • La parte del GUID que no es basado en la marca de tiempo puede considerarse aleatorio; 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 es del mismo orden que si usara dos generadores de números aleatorios separados y observara las colisiones.

    Piense en esto por un momento:los PRNG pueden repetir números y lo hacen, por lo que la probabilidad de una colisión entre dos de ellos no es significativamente mayor que una colisión usando solo uno de ellos, incluso si usan algoritmos ligeramente diferentes. Es algo así como jugar los mismos números de lotería todas las semanas en lugar de elegir un conjunto aleatorio todas las semanas:las probabilidades de ganar son exactamente las mismas en ambos sentidos.

Ahora, tenga en cuenta que cuando usa un algoritmo como Guid.Comb, solo tiene 10 bits de unificador, lo que equivale a 1024 valores separados. Entonces, si está generando una gran cantidad de GUID en los mismos milisegundos, podrá obtener colisiones. Pero si genera GUID a una frecuencia bastante baja, realmente no importa cuántos algoritmos diferentes use 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; tenga los 2 o 3 (o la cantidad que use) generando GUID, al mismo tiempo, a intervalos regulares, y escríbalos en un archivo de registro, y vea si obtiene colisiones (y si es así, cuántas). Eso debería darle una buena idea de qué tan seguro es esto en la práctica.

PD Si está utilizando el generador de peine de NHibernate para generar GUID para una clave principal agrupada, considere usar NEWSEQUENTIALID() en lugar de NEWID() - el objetivo de Comb es evitar divisiones de página, y no lo está logrando si tiene otros procesos que usan algoritmos no secuenciales. También debe cambiar cualquier código usando Guid.NewGuid para usar el mismo generador Comb:el algoritmo Comb real que se usa en NHibernate no es complicado y es fácil de duplicar en su propia lógica de dominio.

† ​​Tenga en cuenta que parece haber cierta disputa sobre NEWID y si contiene o no una marca de tiempo. En cualquier caso, al estar basado en la dirección MAC, el rango de valores posibles es considerablemente menor que un GUID V4 o un Comb. Razón adicional para recomendar apegarse a Comb GUID fuera de la base de datos y NEWSEQUENTIALID dentro de la base de datos.