Риск от сблъсък на UUID, използвайки различни алгоритми

Рискът от сблъсък е леко повишен, но все още изчезващо малък. Помислете за това:

• И гребен, и NEWID /NEWSEQUENTIALID включва времева марка с точност до няколко ms. По този начин, освен ако не генерирате голям брой идентификационни номера в точно същия момент от всички тези различни източници е буквално невъзможно за да се сблъскат идентификатори.

• Частта от GUID, която не е въз основа на времевата марка може да се счита за произволна; повечето GUID алгоритми базират тези цифри на PRNG. По този начин вероятността от сблъсък между тези други около 10 байта е от същия ред, както ако сте използвали два отделни генератора на произволни числа и следите за сблъсъци.

  Помислете за това за момент - PRNG могат и повтарят числата, така че вероятността от сблъсък между две от тях не е значително по-висока от сблъсък, използващ само един от тях, дори ако използват малко по-различни алгоритми. Това е нещо като да играете едни и същи лотарийни числа всяка седмица срещу да избирате произволен набор всяка седмица - шансовете за печалба са абсолютно еднакви и в двата случая.

Сега, имайте предвид, че когато използвате алгоритъм като Guid.Comb, имате само 10 бита уникализатор, което се равнява на 1024 отделни стойности. Така че, ако генерирате огромен брой GUID в рамките на същите няколко милисекунди, вие ще получавайте сблъсъци. Но ако генерирате GUID на доста ниска честота, няма значение колко различни алгоритма използвате едновременно, вероятността от сблъсък все още практически не съществува.

Най-добрият начин да бъдете абсолютно сигурни е да проведете тест; имайте всичките 2 или 3 (или колкото и много да използвате) генериращи GUID едновременно, на редовни интервали, и ги запишете в регистрационен файл и вижте дали получавате сблъсъци (и ако да, колко). Това трябва да ви даде добра представа колко безопасно е това на практика.

P.S. Ако използвате генератора на гребен на NHibernate за генериране на GUID за клъстериран първичен ключ, помислете за използването на NEWSEQUENTIALID() вместо NEWID() - целта на Comb е да избягвате разделянето на страници, а вие не постигате това, ако имате други процеси, използващи непоследователни алгоритми. Трябва също да промените всеки код, като използвате Guid.NewGuid да използвате същия генератор на гребен – действителният алгоритъм на гребен, използван в NHibernate, не е сложен и лесен за дублиране във вашия собствен домейн логика.

_{† ​​Имайте предвид, че изглежда има някакъв спор относно NEWID , и дали съдържа или не времеви печат. Във всеки случай, тъй като се основава на MAC адреса, диапазонът от възможни стойности е значително по-малък от V4 GUID или Comb. Още една причина да препоръчам да се придържате към Comb GUID извън базата данни и NEWSEQUENTIALID вътре в базата данни.}