UUID риск столкновения с использованием разных алгоритмов - PullRequest
17 голосов
/ 14 июня 2010

У меня есть база данных, где 2 (или, может быть, 3 или 4) разные приложения вставляют информацию.Новая информация имеет идентификаторы типа GUID / UUID, но каждое приложение использует свой алгоритм для генерации идентификаторов.Например, один использует NHID-файл "guid.comb", другой - SQLIDerver NEWID (), другой может захотеть использовать реализацию .NET Guid.NewGuid ().

Существует ли выше нормальный рискУдостоверение личности или дубликаты?

Спасибо!

Ответы [ 2 ]

22 голосов
/ 14 июня 2010

Риск столкновений повышен незначительно, но все еще исчезающе мал.Учтите, что:

  • И Comb, и NEWID / NEWSEQUENTIALID включают временную метку с точностью до нескольких мс .Таким образом, если вы не генерируете большое количество идентификаторов в в одно и то же время из всех этих различных источников, буквально невозможно для идентификаторов сталкиваться.

  • Часть GUID, которую не , основанная на отметке времени, можно считать случайной;большинство алгоритмов GUID основывают эти цифры на PRNG.Таким образом, вероятность коллизии между этими другими 10 байтами или около того находится в том же порядке, как если бы вы использовали два отдельных генератора случайных чисел и наблюдали за коллизиями.

    Подумайте об этом на мгновение - PRNG могут и делаютповторяйте числа, поэтому вероятность столкновения между ними не будет значительно выше, чем при использовании только одного из них, даже если они используют несколько разные алгоритмы.Это все равно, что разыгрывать одни и те же номера лотереи каждую неделю, а не выбирать случайные партии каждую неделю - шансы на выигрыш одинаковы в любом случае.

Теперь имейте в виду, что когдаВы используете алгоритм, такой как Guid.Comb, у вас есть только 10 битов уникализатора, что соответствует 1024 отдельным значениям.Так что если вы генерируете огромное количество GUID в течение тех же нескольких миллисекунд, вы получите коллизии.Но если вы генерируете GUID с довольно низкой частотой, не имеет значения, сколько разных алгоритмов вы используете одновременно, вероятность коллизии практически не существует.

Лучший способ для васбыть абсолютно уверенным - это запустить тест;пусть все 2 или 3 (или сколько вы их используете) генерируют идентификаторы GUID одновременно с регулярными интервалами, записывают их в файл журнала и проверяют, нет ли у вас коллизий (и если да, то сколько).Это должно дать вам хорошее представление о том, насколько это безопасно на практике.

PS Если вы используете гребенчатый генератор NHibernate для генерации GUID для кластеризованного первичного ключа, рассмотрите возможность использования NEWSEQUENTIALID() вместо NEWID() -весь смысл Comb заключается в том, чтобы избежать разбиения страниц, и вы этого не добьетесь, если у вас есть другие процессы, использующие непоследовательные алгоритмы.Вы также должны изменить любой код, используя Guid.NewGuid, чтобы использовать тот же генератор гребня - фактический алгоритм гребня, используемый в NHibernate, не сложен и легко дублируется в вашей собственной доменной логике.

† Заметьте, что, похоже, есть спор о NEWID и о том, содержит ли он метку времени.В любом случае, поскольку он основан на MAC-адресе, диапазон возможных значений значительно меньше, чем GUID V4 или Comb.Еще одна причина, по которой я рекомендую придерживаться CombID GUID вне базы данных и NEWSEQUENTIALID внутри базы данных.

4 голосов
/ 14 июня 2010

Да, риск выше нормы, потому что все они используют разные определения «GUID». Guid.NewGuid () - это RFC-совместимый в основном случайный GUID, но NEWSEQUENTIALID - это переупорядоченный (и, следовательно, не RFC-совместимый) GUID, основанный на MAC-адресе и метке времени, а GUID гребенки NHibernate полностью отличается (на основе случайности и метки времени ).

Возможно, вы захотите просто стандартизировать одну реализацию GUID. Я использую свой собственный тип GUID для всех своих приложений. Мой блог содержит краткие описания всех этих типов GUID, а также дизайнерские решения для меня.

...