Un GUID est-il unique à 100% du temps?

Un GUID est-il unique à 100% du temps?

Restera-t-il unique sur plusieurs threads?

Bien que chaque GUID généré ne soit pas garanti d'être unique, le nombre total de clés uniques (2 ¹²⁸ ou 3,4 × 10 ³⁸ ) est si grand que la probabilité qu'un même nombre soit généré deux fois est très faible. Par exemple, considérons l'univers observable, qui contient environ 5 × 10 ²² étoiles; chaque étoile pourrait alors avoir 6,8 × 10 ¹⁵ GUID universellement uniques.

De Wikipédia .

Voici quelques bons articles sur la façon dont un GUID est créé (pour .NET) et comment vous pouvez obtenir le même GUID dans la bonne situation.

https://ericlippert.com/2012/04/24/guid-guide-part-one/

https://ericlippert.com/2012/04/30/guid-guide-part-two/

https://ericlippert.com/2012/05/07/guid-guide-part-three/

La

Si vous avez peur des mêmes valeurs GUID, placez-en deux l'une à côté de l'autre.

Guid.NewGuid().ToString() + Guid.NewGuid().ToString();

Si vous êtes trop paranoïaque, mettez-en trois.

La réponse simple est oui.

Raymond Chen a écrit un excellent article sur les GUID et pourquoi les sous-chaînes de GUID ne sont pas garanties uniques. L'article explique en détail la façon dont les GUID sont générés et les données qu'ils utilisent pour garantir l'unicité, ce qui devrait expliquer en détail pourquoi ils sont :-)

En remarque, je jouais avec les GUID de volume dans Windows XP. Il s'agit d'une disposition de partition très obscure avec trois disques et quatorze volumes.

\\?\Volume{23005604-eb1b-11de-85ba-806d6172696f}\ (F:)
\\?\Volume{23005605-eb1b-11de-85ba-806d6172696f}\ (G:)
\\?\Volume{23005606-eb1b-11de-85ba-806d6172696f}\ (H:)
\\?\Volume{23005607-eb1b-11de-85ba-806d6172696f}\ (J:)
\\?\Volume{23005608-eb1b-11de-85ba-806d6172696f}\ (D:)
\\?\Volume{23005609-eb1b-11de-85ba-806d6172696f}\ (P:)
\\?\Volume{2300560b-eb1b-11de-85ba-806d6172696f}\ (K:)
\\?\Volume{2300560c-eb1b-11de-85ba-806d6172696f}\ (L:)
\\?\Volume{2300560d-eb1b-11de-85ba-806d6172696f}\ (M:)
\\?\Volume{2300560e-eb1b-11de-85ba-806d6172696f}\ (N:)
\\?\Volume{2300560f-eb1b-11de-85ba-806d6172696f}\ (O:)
\\?\Volume{23005610-eb1b-11de-85ba-806d6172696f}\ (E:)
\\?\Volume{23005611-eb1b-11de-85ba-806d6172696f}\ (R:)
                                     | | | | |
                                     | | | | +-- 6f = o
                                     | | | +---- 69 = i
                                     | | +------ 72 = r
                                     | +-------- 61 = a
                                     +---------- 6d = m

Ce n'est pas que les GUID sont très similaires, mais le fait que tous les GUID contiennent la chaîne "mario". Est-ce une coïncidence ou y a-t-il une explication derrière cela?

Maintenant, lors de la recherche sur Google pour la partie 4 du GUID, j'ai trouvé environ 125 000 hits avec des GUID de volume.

Conclusion: en ce qui concerne les GUID de volume, ils ne sont pas aussi uniques que les autres GUID.

Cela ne devrait pas arriver. Cependant, lorsque .NET est soumis à une lourde charge, il est possible d'obtenir des GUID en double. J'ai deux serveurs Web différents utilisant deux serveurs SQL différents. Je suis allé fusionner les données et j'ai découvert que j'avais 15 millions de guides et 7 doublons.

Oui, un GUID doit toujours être unique. Il est basé sur le matériel et le temps, plus quelques bits supplémentaires pour vous assurer qu'il est unique. Je suis sûr qu'il est théoriquement possible de se retrouver avec deux identiques, mais extrêmement peu probable dans un scénario réel.

Voici un excellent article de Raymond Chen sur Guids:

https://blogs.msdn.com/oldnewthing/archive/2008/06/27/8659071.aspx

Les guides sont statistiquement uniques. Les chances que deux clients différents génèrent le même Guid sont infiniment petites (en supposant qu'aucun bogue dans le code de génération de Guid). Vous pouvez aussi vous inquiéter des problèmes de votre processeur dus à un rayon cosmique et décider que 2 + 2 = 5 aujourd'hui.

Plusieurs threads allouant de nouveaux guides obtiendront des valeurs uniques, mais vous devriez obtenir que la fonction que vous appelez soit thread-safe. Dans quel environnement est-ce?

Eric Lippert a écrit une série très intéressante d'articles sur les GUID.

Il y a de l'ordre de 2 ³⁰ ordinateurs personnels dans le monde (et bien sûr de nombreux appareils portables ou non-PC qui ont plus ou moins les mêmes niveaux de puissance de calcul, mais laissons de côté ces derniers). Supposons que nous mettons tous ces PC du monde à la tâche de générer des GUID; si chacun peut générer, disons, 2 ²⁰ GUID par seconde, puis après seulement environ 2 ⁷² secondes - cent cinquante mille milliards d'années - vous aurez une très forte chance de générer une collision avec votre GUID spécifique. Et les chances de collision deviennent plutôt bonnes après seulement trente mille milliards d'années.

• Guide GUID, première partie
• Guide GUID, deuxième partie
• Guide GUID, troisième partie

Théoriquement, non, ils ne sont pas uniques. Il est possible de générer un guid identique à plusieurs reprises. Cependant, les chances que cela se produise sont si faibles que vous pouvez supposer qu'elles sont uniques.

J'ai lu auparavant que les chances sont si faibles que vous devriez vraiment insister sur autre chose - comme votre serveur qui brûle spontanément ou d'autres bogues dans votre code. C'est-à-dire, supposez qu'il est unique et ne construisez pas de code pour "attraper" les doublons - passez votre temps sur quelque chose de plus susceptible de se produire (c'est-à-dire autre chose).

J'ai tenté de décrire l'utilité des GUID pour mon audience de blog (membres de la famille non techniques). De là (via Wikipedia), les chances de générer un GUID en double:

• 1 sur 2 ^ 128
• 1 undecillion sur 340 (ne vous inquiétez pas, undecillion n'est pas sur le quiz)
• 1 sur 3,4 × 10 ^ 38
• 1 sur 340 000 000 000 000 000 000 000 000 000 000 000 000 000

Aucun ne semble mentionner le calcul réel de la probabilité qu'il se produise.

Tout d'abord, supposons que nous pouvons utiliser tout l'espace de 128 bits (Guid v4 n'utilise que 122 bits).

Nous savons que la probabilité générale de NE PAS obtenir de doublon dans les nsélections est:

(1-1 / 2 ¹²⁸ ) (1-2 / 2 ¹²⁸ ) ... (1- (n-1) / 2 ¹²⁸ )

Parce que 2 ¹²⁸ est beaucoup plus grand que n, nous pouvons l'approcher:

(1-1 / 2 ¹²⁸ ) ^{n (n-1) / 2}

Et parce que nous pouvons supposer qu'il nest beaucoup plus grand que 0, nous pouvons l'approcher pour:

(1-1 / 2 ¹²⁸ ) ^{n ^ 2/2}

Maintenant, nous pouvons assimiler cela à la probabilité "acceptable", disons 1%:

(1-1 / 2 ¹²⁸ ) ^{n ^} 2/2 = 0,01

Que nous résolvons net obtenons:

n = sqrt (2 * log 0,01 / log (1-1 / 2 ¹²⁸ ))

Quel Wolfram Alpha arrive à être 5.598318 × 10 ¹⁹

Pour mettre ce nombre en perspective, prenons 10000 machines, chacune ayant un processeur à 4 cœurs, faisant 4 GHz et dépensant 10000 cycles pour générer un Guid et ne rien faire d'autre. Il faudrait alors ~ 111 ans avant de générer un doublon.

Depuis http://www.guidgenerator.com/online-guid-generator.aspx

Qu'est-ce qu'un GUID?

GUID (ou UUID) est un acronyme pour «Globally Unique Identifier» (ou «Universally Unique Identifier»). Il s'agit d'un nombre entier de 128 bits utilisé pour identifier les ressources. Le terme GUID est généralement utilisé par les développeurs travaillant avec les technologies Microsoft, tandis que l'UUID est utilisé partout ailleurs.

À quel point un GUID est-il unique?

128 bits est suffisamment grand et l'algorithme de génération est suffisamment unique pour que si 1 000 000 000 de GUID par seconde soient générés pendant 1 an, la probabilité d'un doublon ne serait que de 50%. Ou si chaque humain sur Terre générait 600 000 000 de GUID, il n'y aurait qu'une probabilité de 50% de doublon.

J'ai rencontré un GUID en double.

J'utilise le scanner de bureau Neat Receipts et il est livré avec un logiciel de base de données propriétaire. Le logiciel a une fonction de synchronisation avec le cloud, et j'ai continué à recevoir une erreur lors de la synchronisation. Un coup d'œil aux journaux a révélé la ligne impressionnante:

"erreurs": [{"code": 1, "message": "creator_guid: est déjà pris", "guid": "C83E5734-D77A-4B09-B8C1-9623CAC7B167"}]}

J'étais un peu incrédule, mais sûrement assez, quand j'ai trouvé un chemin dans ma base de données Neatworks locale et supprimé l'enregistrement contenant ce GUID, l'erreur s'est arrêtée.

Donc, pour répondre à votre question avec des preuves anecdotiques, non. Un doublon est possible. Mais il est probable que la raison pour laquelle cela s'est produit n'était pas due au hasard, mais à la pratique non respectée d'une manière ou d'une autre. (Je n'ai tout simplement pas cette chance) Cependant, je ne peux pas dire avec certitude. Ce n'est pas mon logiciel.

Leur service client était EXTRÊMEMENT courtois et serviable, mais ils n'ont jamais rencontré ce problème auparavant car après plus de 3 heures au téléphone avec eux, ils n'ont pas trouvé la solution. (FWIW, je suis très impressionné par Neat, et ce problème, bien que frustrant, n'a pas changé mon opinion sur leur produit.)

MSDN :

Il y a une très faible probabilité que la valeur du nouveau Guid soit entièrement nulle ou égale à tout autre Guid.

Si votre horloge système est correctement configurée et n'a pas été bouclée, et si votre NIC a son propre MAC (c'est-à-dire que vous n'avez pas défini de MAC personnalisé) et que votre fournisseur de NIC n'a pas recyclé les MAC (ce qu'ils ne sont pas censés faire mais qui est connu pour se produire), et si la fonction de génération de GUID de votre système est correctement implémentée, votre système ne générera jamais de GUID en double.

Si tout le monde sur terre qui génère des GUID suit ces règles, alors vos GUID seront globalement uniques.

Dans la pratique, le nombre de personnes qui enfreignent les règles est faible et il est peu probable que leurs GUID "s'échappent". Les conflits sont statistiquement improbables.

Un GUID est-il unique à 100% du temps?

Non garanti, car il existe plusieurs façons d'en générer un. Cependant, vous pouvez essayer de calculer la possibilité de créer deux GUIDs qui sont identiques et vous obtenez l'idée: un GUID a 128 bits, par conséquent, il y a 2 ¹²⁸ GUIDs distincts - beaucoup plus d' étoiles dans l'univers connu. Lisez l' article wikipedia pour plus de détails.

Dans un sens plus général, ceci est connu comme le "problème d'anniversaire" ou "paradoxe d'anniversaire". Wikipedia a une assez bonne vue d'ensemble sur: Wikipedia - Problème d'anniversaire

En termes très approximatifs, la racine carrée de la taille du pool est une approximation approximative du moment où vous pouvez vous attendre à 50% de chances d'un doublon. L'article comprend une table de probabilité de la taille du pool et diverses probabilités, dont une ligne pour 2 ^ 128. Donc, pour une probabilité de collision de 1%, vous vous attendez à choisir au hasard des nombres de 2,6 * 10 ^ 18 128 bits. Une chance de 50% nécessite 2,2 * 10 ^ 19 choix, tandis que SQRT (2 ^ 128) est de 1,8 * 10 ^ 19.

Bien sûr, ce n'est que le cas idéal d'un processus vraiment aléatoire. Comme d'autres l'ont mentionné, beaucoup dépend de cet aspect aléatoire - à quel point le générateur et la graine sont-ils bons? Ce serait bien s'il y avait un support matériel pour aider à ce processus qui serait plus à l'épreuve des balles, sauf que tout peut être usurpé ou virtualisé. Je soupçonne que cela pourrait être la raison pour laquelle les adresses MAC / horodatages ne sont plus incorporés.

Pour un meilleur résultat, la meilleure façon est d'ajouter le GUID avec l'horodatage (juste pour s'assurer qu'il reste unique)

Guid.NewGuid().ToString() + DateTime.Now.ToString();

Les algorithmes GUID sont généralement implémentés conformément à la spécification GUID v4, qui est essentiellement une chaîne pseudo-aléatoire. Malheureusement, ceux-ci entrent dans la catégorie des "probablement non uniques" de Wikipédia (je ne sais pas pourquoi tant de gens ignorent ce bit): "... d'autres versions GUID ont des propriétés et des probabilités d'unicité différentes, allant de l'unicité garantie à la non-unicité probable. "

Les propriétés pseudo-aléatoires du JavaScript de V8 Math.random()sont TERRIBLES à l'unicité, avec des collisions venant souvent après seulement quelques milliers d'itérations, mais V8 n'est pas le seul coupable. J'ai vu des collisions GUID réelles utilisant à la fois les implémentations PHP et Ruby des GUID v4.

Parce qu'il devient de plus en plus courant de faire évoluer la génération d'ID sur plusieurs clients et clusters de serveurs, l'entropie prend un grand coup - les chances que la même graine aléatoire soit utilisée pour générer une ID augmentent (le temps est souvent utilisé comme graine aléatoire dans les générateurs pseudo-aléatoires), et les collisions GUID passent de "probablement non unique" à "très susceptible de causer beaucoup de problèmes".

Pour résoudre ce problème, j'ai décidé de créer un algorithme d'identification pouvant évoluer en toute sécurité et offrir de meilleures garanties contre les collisions. Il le fait en utilisant l'horodatage, un compteur client en mémoire, l'empreinte digitale du client et des caractères aléatoires. La combinaison de facteurs crée une complexité additive qui est particulièrement résistante à la collision, même si vous la mettez à l'échelle sur un certain nombre d'hôtes:

http://usecuid.org/

J'ai constaté que les GUID n'étaient pas uniques lors des tests unitaires multi-threads / multi-processus (aussi?). Je suppose que cela a à voir avec, toutes les autres choses étant égales, l'ensemencement identique (ou le manque d'ensemencement) des générateurs pseudo-aléatoires. Je l'utilisais pour générer des noms de fichiers uniques. J'ai trouvé que le système d'exploitation est bien meilleur pour le faire :)

Alerte de pêche à la traîne

Vous demandez si les GUID sont 100% uniques. Cela dépend du nombre de GUID dont il doit être unique. Comme le nombre de GUID approche de l'infini, la probabilité de doublons de GUID approche 100%.

La réponse "Un GUID est-il 100% unique?" est tout simplement "Non" .

• Si vous souhaitez un caractère 100% unique du GUID, procédez comme suit.

  1. générer un GUID
  2. vérifier si ce GUID existe dans la colonne de votre tableau où vous recherchez l'unicité
  3. s'il existe, passez à l'étape 1 sinon à l'étape 4
  4. utilisez ce GUID comme unique.

La partie la plus difficile n'est pas de générer un Guid dupliqué.

La partie la plus difficile est une base de données conçue pour stocker toutes celles générées pour vérifier si elle est réellement dupliquée.

De WIKI:

Par exemple, le nombre d'UUID aléatoires de la version 4 qui doivent être générés pour avoir une probabilité de 50% d'au moins une collision est de 2,71 quintillions, calculé comme suit:

entrez la description de l'image ici

Ce nombre équivaut à générer 1 milliard d'UUID par seconde pendant environ 85 ans, et un fichier contenant ce nombre d'UUID, à 16 octets par UUID, serait d'environ 45 exaoctets, plusieurs fois plus grand que les plus grandes bases de données actuellement en existence, qui sont sur l'ordre de centaines de pétaoctets

GUID signifie Global Unique Identifier

En bref: (l'indice est dans le nom)

En détail: les GUID sont conçus pour être uniques; ils sont calculés à l'aide d'une méthode aléatoire basée sur l'horloge de l'ordinateur et l'ordinateur lui-même, si vous créez de nombreux GUID à la même milliseconde sur la même machine, il est possible qu'ils correspondent, mais pour presque toutes les opérations normales, ils doivent être considérés comme uniques.