Коллизия UUID рискует использовать различные алгоритмы
У меня есть база данных, где 2 (или возможно 3 или 4) различные приложения вставляют информацию. Новая информация имеет идентификаторы типа GUID/UUID, но каждое приложение использует различный алгоритм для генерации идентификаторов. Например, каждый использует "guid.comb" NHIBERNATE, другой использует NEWID SQLSERVER (), другой мог бы хотеть использовать Гуид.NET. NewGuid () реализация.
Существует ли вышеупомянутый нормальный риск идентификационной коллизии или дубликатов?
Спасибо!
2 ответа
Риск столкновений немного повышается, но все еще исчезающе мал. Рассмотрим следующее:
И Comb, и
NEWID/NEWSEQUENTIALIDвключают метку времени с точностью до нескольких мс†. Таким образом, если вы не генерируете большое количество идентификаторов в точно такой же момент времени из всех этих различных источников, столкновение идентификаторов буквально невозможно.Ту часть GUID, которая не основана на метке времени, можно считать случайной; большинство алгоритмов GUID основывают эти цифры на ГПСЧ. Таким образом, вероятность столкновения между этими оставшимися 10 байтами или около того находится в том же порядке, как если бы вы использовали два отдельных генератора случайных чисел и наблюдали за столкновениями.
Задумайтесь об этом на минуту - ГПСЧ могут повторять и повторяют числа, поэтому вероятность столкновения между двумя из них не намного выше, чем при использовании только одного из них, даже если они используют немного разные алгоритмы. Это похоже на игру в лотерею с одними и теми же номерами каждую неделю по сравнению с выбором случайного набора каждую неделю - шансы на выигрыш в любом случае одинаковы.
Теперь имейте в виду, что при использовании такого алгоритма, как Guid.Comb, у вас есть только 10 бит уникализатора, что соответствует 1024 отдельным значениям. Поэтому, если вы генерируете огромное количество GUID за те же несколько миллисекунд, вы будете получать столкновения. Но если вы генерируете GUID с достаточно низкой частотой, то не имеет значения, сколько различных алгоритмов вы используете одновременно, вероятность столкновения все равно практически отсутствует.
Лучший способ быть абсолютно уверенным - провести тест; пусть все 2 или 3 (или сколько бы вы ни использовали) генерируют GUID одновременно, через регулярные промежутки времени, и записывают их в файл журнала, и посмотрите, получаете ли вы столкновения (и если да, то сколько). Это даст вам хорошее представление о том, насколько это безопасно на практике.
P.S. Если вы используете NHibernate's comb generator для генерации GUID для кластеризованного первичного ключа, подумайте об использовании NEWSEQUENTIALID() вместо NEWID() - весь смысл Comb в том, чтобы избежать разделения страниц, а вы этого не достигнете, если у вас есть другие процессы, использующие непоследовательные алгоритмы. Вы также должны изменить любой код, использующий Guid.NewGuid, чтобы использовать тот же генератор Comb - фактический алгоритм Comb, используемый в NHibernate, несложен и легко дублируется в вашей собственной доменной логике.
† Обратите внимание, что, похоже, есть некоторые разногласия по поводу NEWID, и содержит ли он метку времени или нет. В любом случае, поскольку он основан на MAC-адресе, диапазон возможных значений значительно меньше, чем у V4 GUID или Comb. Еще одна причина, по которой я рекомендую придерживаться GUID Comb вне базы данных и NEWSEQUENTIALID внутри базы данных.
Да, риск выше нормы, потому что все они используют разные определения GUID. Guid.NewGuid () - это RFC-совместимый в основном случайный GUID, но NEWSEQUENTIALID - это переупорядоченный (и, следовательно, несовместимый с RFC) GUID, основанный на MAC-адресе и метке времени, а GUID гребешка NHibernate совершенно другой (на основе случайности и метки времени). ).
Возможно, вы захотите просто стандартизировать одну реализацию GUID. Я использую свой собственный тип прочесанного GUID для всех своих приложений. В моем блоге есть краткие описания всех этих типов GUID вместе с дизайнерскими решениями для меня.