Sqlserver
 sql >> Base de données >  >> RDS >> Sqlserver

Risque de collision UUID en utilisant différents algorithmes

Le risque de collision est légèrement élevé, mais toujours extrêmement faible. Considérez que :

  • Comb et NEWID /NEWSEQUENTIALID inclure un horodatage avec une précision de quelques ms. Ainsi, à moins que vous ne génériez un grand nombre d'identifiants au exact même moment de toutes ces différentes sources, c'est littéralement impossible pour que les identifiants entrent en collision.

  • La partie du GUID qui n'est pas basé sur l'horodatage peut être considéré comme aléatoire ; la plupart des algorithmes GUID basent ces chiffres sur un PRNG. Ainsi, la probabilité d'une collision entre ces 10 autres octets environ est du même ordre que si vous utilisiez deux générateurs de nombres aléatoires distincts et que vous surveilliez les collisions.

    Pensez-y un instant - les PRNG peuvent répéter et répètent des nombres, de sorte que la probabilité d'une collision entre deux d'entre eux n'est pas significativement plus élevée qu'une collision en utilisant un seul d'entre eux, même s'ils utilisent des algorithmes légèrement différents. C'est un peu comme si vous jouiez les mêmes numéros de loterie chaque semaine au lieu de choisir un ensemble aléatoire chaque semaine - les chances de gagner sont exactement les mêmes dans les deux cas.

Maintenant, gardez à l'esprit que lorsque vous utilisez un algorithme comme Guid.Comb, vous n'avez que 10 bits d'unificateur, ce qui équivaut à 1024 valeurs distinctes. Donc, si vous générez un grand nombre de GUID dans les mêmes quelques millisecondes, vous allez obtenir des collisions. Mais si vous générez des GUID à une fréquence assez basse, peu importe le nombre d'algorithmes différents que vous utilisez en même temps, la probabilité d'une collision est toujours pratiquement inexistante.

La meilleure façon pour vous d'être absolument certain est d'effectuer un test; avoir tous les 2 ou 3 (ou le nombre que vous utilisez) générant des GUID, en même temps, à intervalles réguliers, et écrivez-les dans un fichier journal, et voyez si vous obtenez des collisions (et si oui, combien). Cela devrait vous donner une bonne idée de la sécurité dans la pratique.

PS Si vous utilisez le générateur de peignes de NHibernate pour générer des GUID pour une clé primaire en cluster, pensez à utiliser NEWSEQUENTIALID() au lieu de NEWID() - le but de Comb est d'éviter les fractionnements de page, et vous n'y parvenez pas si vous avez d'autres processus utilisant des algorithmes non séquentiels. Vous devez également modifier tout code en utilisant Guid.NewGuid utiliser le même générateur Comb - l'algorithme Comb utilisé dans NHibernate n'est pas compliqué et facile à dupliquer dans votre propre logique de domaine.

† ​​Notez qu'il semble y avoir un différend à propos de NEWID , et s'il contient ou non un horodatage. Dans tous les cas, puisqu'il est basé sur l'adresse MAC, la plage de valeurs possibles est considérablement plus petite qu'un GUID V4 ou un Comb. Raison supplémentaire pour moi de recommander de s'en tenir aux Comb GUID en dehors de la base de données et NEWSEQUENTIALID dans la base de données.