UUID-kollisionsrisiko ved hjælp af forskellige algoritmer

Risikoen for sammenstød er forhøjet lidt, men stadig forsvindende lille. Overvej at:

• Både Comb og NEWID /NEWSEQUENTIALID inkludere et tidsstempel med præcision ned til et par ms. Medmindre du genererer et stort antal ID'er på nøjagtig samme tidspunkt fra alle disse forskellige kilder er det bogstaveligt talt umuligt for at ID'er kan støde sammen.

• Den del af GUID'et, der ikke er baseret på tidsstemplet kan opfattes som tilfældigt; de fleste GUID-algoritmer baserer disse cifre på en PRNG. Således er sandsynligheden for en kollision mellem disse andre 10 bytes eller deromkring i samme rækkefølge, som hvis du brugte to separate tilfældige talgeneratorer og holdt øje med kollisioner.

  Tænk over dette et øjeblik - PRNG'er kan og gentage tal, så sandsynligheden for en kollision mellem to af dem er ikke væsentligt højere end en kollision med kun én af dem, selvom de bruger lidt forskellige algoritmer. Det er lidt som at spille de samme lotto-numre hver uge i modsætning til at vælge et tilfældigt sæt hver uge - oddsene for at vinde er nøjagtig de samme begge veje.

Nu skal du huske på, at når du bruger en algoritme som Guid.Comb, har du kun 10 bits unika, hvilket svarer til 1024 separate værdier. Så hvis du genererer et stort antal GUID'er inden for de samme få millisekunder, vil få kollisioner. Men hvis du genererer GUID'er med en forholdsvis lav frekvens, er det ikke lige meget, hvor mange forskellige algoritmer du bruger på samme tid, sandsynligheden for en kollision er stadig praktisk talt ikke-eksisterende.

Den bedste måde for dig at være helt sikker på er at køre en test; have alle 2 eller 3 (eller hvor mange du bruger) til at generere GUID'er, på samme tid, med jævne mellemrum, og skriv dem ud til en logfil, og se om du får kollisioner (og i givet fald hvor mange). Det burde give dig en god idé om, hvor sikkert dette er i praksis.

P.S. Hvis du bruger NHibernates kamgenerator til at generere GUID'er for en klynget primærnøgle, kan du overveje at bruge NEWSEQUENTIALID() i stedet for NEWID() - Hele pointen med Comb er at undgå sideopdelinger, og det opnår du ikke, hvis du har andre processer, der bruger ikke-sekventielle algoritmer. Du bør også ændre enhver kode ved hjælp af Guid.NewGuid at bruge den samme Comb-generator - den faktiske Comb-algoritme, der bruges i NHibernate, er ikke kompliceret og nem at duplikere i din egen domænelogik.

_{† ​​Bemærk, at der ser ud til at være uenighed om NEWID , og om den indeholder et tidsstempel eller ej. Under alle omstændigheder, da den er baseret på MAC-adressen, er rækken af ​​mulige værdier betydeligt mindre end en V4 GUID eller en Comb. Yderligere grund for mig til at anbefale at holde mig til Comb GUID'er uden for databasen og NEWSEQUENTIALID inde i databasen.}