sql >> Databasteknik >  >> RDS >> Sqlserver

UUID kollisionsrisk med hjälp av olika algoritmer

Risken för kollisioner är något förhöjd men fortfarande försvinnande liten. Tänk på att:

  • Både Comb och NEWID /NEWSEQUENTIALID inkludera en tidsstämpel med precision ner till några få ms. Såvida du inte genererar ett stort antal ID:n vid exakt samma tidpunkt från alla dessa olika källor är det bokstavligen omöjligt för att ID:n ska kollidera.

  • Den del av GUID som inte är baserat på tidsstämpeln kan ses som slumpmässigt; de flesta GUID-algoritmer baserar dessa siffror på en PRNG. Sannolikheten för en kollision mellan dessa andra 10 byte eller så är alltså i samma ordning som om du använde två separata slumptalsgeneratorer och tittade efter kollisioner.

    Tänk på det här ett ögonblick - PRNG:er kan och upprepar siffror, så sannolikheten för en kollision mellan två av dem är inte nämnvärt högre än en kollision med bara en av dem, även om de använder lite olika algoritmer. Det är ungefär som att spela samma lottonummer varje vecka jämfört med att välja ett slumpmässigt set varje vecka - oddsen för att vinna är exakt desamma oavsett.

Tänk nu på att när du använder en algoritm som Guid.Comb har du bara 10 bitar av unikare, vilket motsvarar 1024 separata värden. Så om du genererar ett stort antal GUID inom samma få millisekunder, kommer få kollisioner. Men om du genererar GUID med en ganska låg frekvens, spelar det ingen roll hur många olika algoritmer du använder samtidigt, sannolikheten för en kollision är fortfarande praktiskt taget obefintlig.

Det bästa sättet för dig att vara helt säker är att köra ett test; ha alla 2 eller 3 (eller hur många du än använder) genererande GUID, samtidigt, med jämna mellanrum, och skriv ut dem till en loggfil, och se om du får kollisioner (och i så fall hur många). Det borde ge dig en god uppfattning om hur säkert detta är i praktiken.

P.S. Om du använder NHibernates kamgenerator för att generera GUID för en klustrad primärnyckel, överväg att använda NEWSEQUENTIALID() istället för NEWID() - Hela poängen med Comb är att undvika siddelning, och det gör du inte om du har andra processer som använder icke-sekventiella algoritmer. Du bör också ändra vilken kod som helst med Guid.NewGuid att använda samma Comb-generator - den faktiska Comb-algoritmen som används i NHibernate är inte komplicerad och lätt att duplicera i din egen domänlogik.

† ​​Observera att det verkar finnas en viss dispyt om NEWID , och om den innehåller en tidsstämpel eller inte. I vilket fall som helst, eftersom det är baserat på MAC-adressen, är intervallet av möjliga värden betydligt mindre än en V4 GUID eller en Comb. Ytterligare anledning för mig att rekommendera att hålla mig till Comb GUID utanför databasen och NEWSEQUENTIALID inuti databasen.



  1. Exportera en PostgreSQL-databas med phpPgAdmin

  2. Hur får man tabelldefinition i Oracle?

  3. Oracle tar bort rader från flera tabeller

  4. Oracle SQL Developer - Hur man återställer tappad tabell