Является ли GUID уникальным в 100% случаев?
Является ли GUID уникальным в 100% случаев?
Останется ли он уникальным в нескольких потоках?
Прежде всего, GUID не бесконечен, что означает, что буквальное значение «100% времени» означает, что независимо от того, как долго вы продолжаете генерировать GUID, они всегда будут уникальными. Это не тот случай. Кроме того, поскольку исходная реализация, в которой уникальный серийный номер / идентификатор / MAC-адрес сетевой карты использовалась для создания части ключа, больше не используется, по разным причинам GUID больше не является уникальным глобально. Однако это локально уникально. Другими словами, если вы продолжите генерировать идентификаторы GUID на одном компьютере, вы не получите дубликатов.
@ojrac Я просто округляю вниз ...: P
В дополнение к отличному комментарию Лассе: межмашинная уникальность GUID связана с используемой реализацией / алгоритмом. См .: википедия на GUIDS - большинство реализаций GUID на большинстве платформ (включая SQLCE 3.5) используют GUID типа 4, основанные на генераторах случайных чисел, поэтому они должны нормально переходить границы машины (ищите «4» после второго дефиса).
Что такое «гид, не зависящий от языка»?
Каждый раз, когда я генерирую GUID, я чувствую, что краду его у Вселенной. Иногда я думаю о злых людях, которые генерируют гораздо больше GUID, чем им нужно, и эти потраченные впустую GUID настолько одиноки, что их не используют и не генерируют снова ...
GUID (глобально уникальный идентификатор) теоретически бесполезен, если он уникален только локально, а не глобально, потому что он теряет гарантии, обеспечиваемые действительно глобально уникальным идентификатором. Помимо его более непредсказуемого характера, у него не будет преимуществ перед увеличиваемым целым числом, обслуживаемым единственной системной службой. Основное преимущество действительно глобального идентификатора заключается в том, что вы можете генерировать их в разных системах и при этом гарантировать их уникальность при периодическом объединении в центральную базу данных.
128-битное значение достаточно велико, а алгоритм генерации достаточно уникален, так что если бы 1 000 000 000 GUID в секунду генерировались в течение 1 года, вероятность дублирования была бы только 50%. Или, если бы каждый человек на Земле сгенерировал 600000000 GUID, вероятность дублирования была бы только 50%. По данным: guidgenerator.com/online-guid-generator.aspx
@asavartsov Думаю тебе понравится Wasteaguid.info ^ _ ^
Я не думаю, что это вообще что-то особенное.
Я до сих пор не понимаю этого желания играть.
Я построил небольшую игру на основе этого: гид привязка Готов поспорить, ты не выиграешь!
У меня было однажды, что один и тот же guid сгенерировал 9 раз одинаковый идентификатор,>. <Yikes !!
Последний GUID, созданный моим приложением - клянусь, я видел его раньше.
Произошла интересная вещь - недавно я создал GUID для своего расширения Firefox, и он оказался таким же, как GUID идентификатора приложения Firefox. Безумно то, что это не было ошибкой. Он был создан с помощью модуля uuid Python. Странные вещи. Почему-то мне плохо ..
@asavartsov У меня было то же чувство, пока я не понял, что идентификаторы GUID обычно включают в себя какую-то форму отметки времени, что означает, что в каждый момент времени любой GUID не генерируется является потраченным впустую GUID. Другими словами, вы не можете «тратить впустую» GUID.
Просто чтобы добавить к логике глобальных и локальных уникальных идентификаторов, которые всегда могут относиться к вашей вселенной. GUID можно использовать для глобальной идентификации сущностей в вашей локальной вселенной, где использование инкрементных идентификаторов требует двух свойств для достижения одной и той же цели (ID + Type).
для записи, я однажды столкнулся с ошибкой, когда один клиент вылетел из-за того, что новый GUID, который программа пыталась вставить в базу данных, уже был там, но для другой записи. Это происходило только один раз за годы использования программного обеспечения для сотен баз данных на наших серверах.
Ответы 22
While each generated GUID is not guaranteed to be unique, the total number of unique keys (2128 or 3.4×1038) is so large that the probability of the same number being generated twice is very small. For example, consider the observable universe, which contains about 5×1022 stars; every star could then have 6.8×1015 universally unique GUIDs.
От Википедия.
Это несколько хороших статей о том, как создается GUID (для .NET) и как вы можете получить такой же идентификатор в нужной ситуации.
https://ericlippert.com/2012/04/24/guid-guide-part-one/
https://ericlippert.com/2012/04/30/guid-guide-part-two/
https://ericlippert.com/2012/05/07/guid-guide-part-three/
Взаимодействие с другими людьми
Разве тогда они не были бы названы UUID? ;)
GUID - это специфическая реализация стандарта UUID, разработанная корпорацией Майкрософт. Итак, и то, и другое. Глобальный уникальный идентификатор против универсального уникального идентификатора.
Технически это не 2 ^ 128, потому что в GUID v4 у вас есть одна шестнадцатеричная цифра, которая всегда будет 4 (эффективно удаляет 4 бита), а еще два бита также зарезервированы. Тем не менее, 2 ^ 122 действительных GUID V4 по-прежнему оставляет около 5x10 ^ 36, что для меня подойдет. и для тебя тоже. Каждая звезда должна будет принять около 1,1x10 ^ 14 идентификаторов GUID.
Если вы похожи на меня, то вы захотите знать, что написано 2^128 примерно: 34,028,236,692,093,846,346,337,460,743,177,000,000. По статистике, если вы рассчитываете 1000 GUID каждую секунду, на получение дубликата все равно уйдут триллионы лет.
Это не «очень маленький», он «очень ... очень маленький». Получите правильную английскую математику! :-П
Мне просто показалось забавным читать это, так что повеселитесь, ребята :) Тридцать четыре ундециллиона двадцать восемь дециллионов двести тридцать шесть нониллионов шестьсот девяносто два октиллиона девяносто три септиллиона восемьсот сорок шесть секстиллионов триста сорок шесть квинтиллионов триста тридцать семь квадриллионов четыреста шестьдесят триллионов семьсот сорок три миллиарда сто семьдесят семь миллионов
Ух! ты легко сказать!
@TheAdamGaskins, и если вы похожи на меня, вы заметите, что это почти полная точность, и захотите знать, что это именно: 340,282,366,920,938,463,463,374,607,431,768,211,456 (и вы заметите, что вы были выключены на степень 10 в вашем номере - это ~ 340 ундециллионов, а не ~ 34 ундециллионов)
Я думаю, что просто сказать, что существует много возможных GUID, - это только часть ответа. Вам также необходимо знать, как рассчитывается GUID. Например, если вам нужно только 100 уникальных целых чисел (вместо GUID), и ваш метод будет выглядеть примерно так: if (IsItASunnyDay) then return 1 else return 2 ', у вас будет практически только два уникальных целых числа ...
Как комментирует @GeertImmerzeel, вопрос о как, сгенерированном guid, является важным моментом. Прямо как в xkcd.com/221
Риск создания одних и тех же GUID может быть очень мал, но мы разработчики программного обеспечения, поэтому мы должны знать, что все, что может пойти не так, БУДЕТ ошибкой. Так что сохраняйте блоки try / catch;)
@adam davis, вы сказали: the total number of unique keys (2^128 or 3.4×10^38) is so large that the probability of the same number being generated twice is very small не означает, что он не может дублировать. например: Действительное число бесконечно, но 1 функция, которая генерирует действительное число, не означает, что она не может генерировать дубликаты реального числа.
Из той же статьи: «мы могли бы с большой вероятностью сгенерировать коллизию GUID всего за час, при условии, что у нас есть каждый компьютер на планете, чтобы выделить на это час времени». По мере увеличения количества устройств и увеличения их скорости конфликт GUID станет только более вероятным. Люди должны перестать смеяться над этим.
@ChrisMoschini Затем нам нужно будет сохранить все созданные GUID, а затем сравнить их друг с другом, чтобы найти коллизию. Это займет очень, очень, очень много времени, даже с учетом всех новых устройств и более высоких скоростей. Вся эта проблема состоит в том, чтобы просто создать столкновение - но тогда становится гораздо более маловероятным, что они действительно столкнутся! Другими словами, прямо сейчас в мире может быть несколько идентичных GUID, но они, по всей вероятности, никогда не соприкоснутся друг с другом и, следовательно, никогда не столкнутся.
@ChrisMoschini Итак, этот вопрос касается того, можно ли создать два одинаковых GUID, но он не касается даже гораздо более маловероятного сценария, когда они когда-либо вступят в контакт друг с другом. И дополнительные устройства и скорость не увеличивают эту вероятность существенно, не говоря уже о том факте, что дополнительные устройства даже не создают столько GUID. Я подозреваю, что среднее устройство создает не более нескольких миллионов за все время своего существования.
@AdamDavis Там много предположений. Все, что требуется для столкновения этих GUID, - это, скажем, объекты в процедурно сгенерированной игре-вселенной, где игроки иногда натыкаются друг на друга. Помните, что хранилище может быть распределено так же, как и поколение. Ваше предположение, что устройства могут генерировать несколько миллионов когда-либо, навсегда, звучит так, как будто 640 КБ хватит для всех. В любом случае, люди легкомысленно отвергают коллизию GUID, и ее нужно прекратить. Известные границы, когда это может произойти, а когда это вероятно, более объективны и полезны. И ближе, чем часто изображается.
@ChrisMoschini: Возможно, вам стоит провести статистический анализ самостоятельно, учитывая сегодняшнее использование, и опубликовать ответ. Мне будет очень интересно прочитать ваше мнение об этом.
В сегодняшних новостях: spacetelescope.org/news/heic1620 «Наблюдаемая Вселенная содержит в десять раз больше галактик, чем считалось ранее» - так что уменьшите количество GUID на одну звезду еще на один порядок. Вы начинаете волноваться?
@MikeNakis хм, это беспокоит. Я предлагаю немедленно колонизировать каждую солнечную систему и начать работу по разделению оставшихся гидов.
Поэтому не существует ли риска, что если каждый из нас сгенерирует более 895 000 GUID, то мы получим недовольные письма о прекращении и воздержании от других звездных систем 5 × 10 ^ 22 в наблюдаемой Вселенной? Это могло серьезно засорить почтовую систему.
Да, GUID всегда должен быть уникальным. Он основан как на оборудовании, так и на времени, плюс несколько дополнительных битов, чтобы убедиться, что он уникален. Я уверен, что теоретически возможно получить два одинаковых, но крайне маловероятно в реальном сценарии.
Вот отличная статья Раймонда Чена о руководствах:
https://blogs.msdn.com/oldnewthing/archive/2008/06/27/8659071.aspx Взаимодействие с другими людьми Взаимодействие с другими людьми Взаимодействие с другими людьми
Эта статья довольно старая и относится к версии 1 для GUID. v4 не использует аппаратное обеспечение / время, а вместо этого использует алгоритм случайных чисел. en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm
Эта ссылка не работает
Вот ссылка: devblogs.microsoft.com/oldnewthing/20080627-00/?p=21823
Простой ответ - да.
Раймонд Чен написал отличная статья для GUID и почему подстроки GUID гарантированно уникальны. В статье подробно рассказывается о том, как генерируются идентификаторы GUID и какие данные они используют для обеспечения уникальности, что должно быть довольно подробно объяснено Почему, которыми они являются :-)
Я думаю, что статья Чена относится к V1 алгоритма генерации GUID, который использует MAC-адрес и временную метку - в текущем V4 вместо этого используется псевдослучайное число: en.wikipedia.org/wiki/Globally_Unique_Identifier#Algorithm
MSDN:
There is a very low probability that the value of the new Guid is all zeroes or equal to any other Guid.
Is a GUID unique 100% of the time?
Не гарантируется, так как существует несколько способов его создания. Однако вы можете попытаться вычислить вероятность создания двух идентичных GUID, и вы поймете идею: GUID имеет 128 бит, следовательно, существует 2128 различных GUID - много больше, чем звезд в известной вселенной. Подробнее читайте в статья в Википедии.
Гиды статистически уникальны. Вероятность того, что два разных клиента сгенерируют один и тот же Guid, бесконечно мала (при условии отсутствия ошибок в коде, генерирующем Guid). Вы можете также беспокоиться о сбоях вашего процессора из-за космического луча и решить, что сегодня 2 + 2 = 5.
Несколько потоков, выделяющих новые направляющие, получат уникальные значения, но вы должны понять, что вызываемая функция является потокобезопасной. В какой среде это находится?
Теоретически нет, они не уникальны. Можно создавать один и тот же гид снова и снова. Однако шансы на то, что это произойдет, настолько низки, что можно предположить, что они уникальны.
Я читал раньше, что шансы настолько низки, что вам действительно стоит беспокоиться о чем-то другом - например, о самопроизвольном сгорании вашего сервера или о других ошибках в вашем коде. То есть, предположите, что он уникален, и не встраивайте какой-либо код для «отлова» дубликатов - потратьте свое время на что-то более вероятное (например, что-либо else).
Я сделал попытку, чтобы описать полезность GUID для аудитории моего блога (нетехнических членов семьи). Оттуда (через Википедию) шансы на создание повторяющегося GUID:
- 1 из 2 ^ 128
- 1 из 340 ундециллионов (не волнуйтесь, ундециллион не входит в контрольный опрос)
- 1 из 3,4 × 10 ^ 38
- 1 из 340 000 000 000 000 000 000 000 000 000 000 000 000
На самом деле, я не согласен с тем, чтобы «не беспокоиться об этом», хотя и с другой точки зрения: если вы обнаруживаете коллизию GUID, значит, с вашим приложением что-то пошло не так. Например, я использовал идентификаторы GUID для идемпотентности и столкнулся с конфликтом, когда команда была отправлена дважды (с тем же идентификатором GUID).
Если ваши системные часы установлены правильно и не обернуты, и если ваша сетевая карта имеет свой собственный MAC (то есть вы не установили собственный MAC), и ваш поставщик сетевой карты не перерабатывал MAC-адреса (что они не должны делать но что, как известно, происходит), и если в вашей системе функция генерации GUID правильно реализована, то ваша система никогда не будет генерировать повторяющиеся GUID.
Если все на Земле, кто генерирует GUID, будут следовать этим правилам, тогда ваши GUID будут глобально уникальными.
На практике количество людей, нарушающих правила, невелико, и их GUID вряд ли «сбегут». Конфликты статистически маловероятны.
Это будет верно только для руководств v1. Версия v4, которая де-факто является STD, больше не использует Mac-адреса, а использует псевдослучайное число.
«тогда ваша система никогда не будет генерировать повторяющиеся идентификаторы GUID». Даже если бы все правила были соблюдены для guid v1, как вы говорите, ваша система все равно могла бы создавать дубликаты. Вы более правы, когда говорите: «Конфликты статистически маловероятны».
В качестве примечания, я играл с GUID тома в Windows XP. Это очень непонятная схема разделов с тремя дисками и четырнадцатью томами.
\?\Volume{23005604-eb1b-11de-85ba-806d6172696f}\ (F:)
\?\Volume{23005605-eb1b-11de-85ba-806d6172696f}\ (G:)
\?\Volume{23005606-eb1b-11de-85ba-806d6172696f}\ (H:)
\?\Volume{23005607-eb1b-11de-85ba-806d6172696f}\ (J:)
\?\Volume{23005608-eb1b-11de-85ba-806d6172696f}\ (D:)
\?\Volume{23005609-eb1b-11de-85ba-806d6172696f}\ (P:)
\?\Volume{2300560b-eb1b-11de-85ba-806d6172696f}\ (K:)
\?\Volume{2300560c-eb1b-11de-85ba-806d6172696f}\ (L:)
\?\Volume{2300560d-eb1b-11de-85ba-806d6172696f}\ (M:)
\?\Volume{2300560e-eb1b-11de-85ba-806d6172696f}\ (N:)
\?\Volume{2300560f-eb1b-11de-85ba-806d6172696f}\ (O:)
\?\Volume{23005610-eb1b-11de-85ba-806d6172696f}\ (E:)
\?\Volume{23005611-eb1b-11de-85ba-806d6172696f}\ (R:)
| | | | |
| | | | +-- 6f = o
| | | +---- 69 = i
| | +------ 72 = r
| +-------- 61 = a
+---------- 6d = m
Дело не в том, что идентификаторы GUID очень похожи, а в том, что все идентификаторы GUID содержат строку «марио». Это совпадение или за этим есть какое-то объяснение?
Теперь, когда поиск в Google, часть 4 в GUID, я обнаружил около 125 000 обращений с GUID тома.
Вывод: Когда дело доходит до GUID тома, они не так уникальны, как другие GUID.
Помните ту рекламу Super Mario Bros 3 из 80-х? Все эти люди кричат: «Марио! Марио! Марио!» во всем мире немного расстроила случайность Вселенной.
Если вы вручную удалите Office 2010 с msiexec, в нем будут перечислены все идентификаторы GUID MSI офисной программы. Все они пишут 0FF1CE. Похоже, у Microsoft довольно ... вольная ... интерпретация того, как генерировать GUID;)
Все GUID этих разделов были созданы вместе 17 декабря 2009 г. в 14:47:45 по всемирному координированному времени. Они уникальны для вашей машины, но указывать «mario» в качестве идентификатора узла неверно - это означает, что они не соответствуют RFC-4122. Точно так же идентификаторы GUID 0FF1CE подпадают под раздел «Обратная совместимость NCS» RFC-4122, но маловероятно, что Microsoft следует правилам NCS для этих значений.
Я знал, что администрация безопасности Nintendo взломала генераторы случайных чисел.
возможно, это тот же парк мячей, что и название компании, производящей минеральную воду (слышал, они лидируют на рынке) Evian. Обратное написание дает Наивность :-)
Они также играют с отправкой сообщений с использованием обратной орфографии. Т.е. компания, производящая воду в бутылках Evian = Naive.
@StephenCleary Как вы узнали, когда были созданы GUID?
@BhushanFirake: Раньше у меня был онлайн-декодер GUID. Код все еще где-то есть, но сайт больше не работает.
Это Type 1 UUIDs - это видно по 1 в 11de. Исправленные 6 байтов UUID - это узел (то есть MAC-адрес) машины, генерирующей UUID. В этом случае MAC-адрес - 80-6d-61-72-69-6f. Вы заметите, что установлен высокий бит; это означает, что это не настоящий MAC-адрес; но вместо этого - псевдослучайно сгенерированный MAC-адрес
Тот факт, что старший бит был установлен для обозначения «локально администрируемого» MAC-адреса, на самом деле является неправильным битом для установки. Это привело к тому, что десятилетия спустя в UuidCreateSequential была обнаружена ошибка. Люди в Microsoft ошибочно думали, что установленный высокий бит делает его «локализованным». Это хорошее и разумное предположение, но это неверно. На самом деле это 2-й младший бит старшего байта (?! Да, спасибо IEEE). Если бы Windows NT писалась сегодня, этот MAC-адрес, вероятно, читался бы как 02-6d-61-72-69-6f.
Этого не должно быть. Однако, когда .NET находится под большой нагрузкой, возможно получение дублирующих руководств. У меня есть два разных веб-сервера, использующих два разных сервера sql. Я пошел объединить данные и обнаружил, что у меня есть 15 миллионов руководств и 7 дубликатов.
Как это возможно на двух разных машинах? Я думал, что часть GUID - это имя машины? (не спорю ... просто спрашиваю)
Это будет справедливо только для руководств v1, которые используют MAC-адреса (не имя компьютера) как часть генерации GUID. Версия v4, которая де-факто является STD, больше не использует Mac-адреса, а использует псевдослучайное число.
Guid.NewGuid всегда генерирует GUID v4 (и всегда генерирует). У Тима, должно быть, были очень плохие источники энтропии.
Это когда-нибудь копировалось? это огромная проблема, если это так.
То же самое здесь при импорте очень больших наборов данных. Примерно из 10-100 миллионов вы получаете дубликаты от Guid.NewGuid
Эрик Липперт написал очень интересную серию статей о GUID.
There are on the order 230 personal computers in the world (and of course lots of hand-held devices or non-PC computing devices that have more or less the same levels of computing power, but lets ignore those). Let's assume that we put all those PCs in the world to the task of generating GUIDs; if each one can generate, say, 220 GUIDs per second then after only about 272 seconds -- one hundred and fifty trillion years -- you'll have a very high chance of generating a collision with your specific GUID. And the odds of collision get pretty good after only thirty trillion years.
... и он продолжает в следующем абзаце: «Но это ищет коллизию с конкретным GUID. [...] Так что, если мы заставим этот миллиард компьютеров работать, генерируя идентификаторы GUID со 122-битной случайностью, вероятность того, что два из них где-то там столкнутся, станет очень высокой. после того, как будет сгенерировано примерно 2 ^ 61 GUID. Поскольку мы предполагаем, что примерно 2 ^ 30 компьютеров выполняют 2 ^ 20 GUID в секунду, мы ожидаем столкновение примерно через 2 ^ 11 секунд, что составляет около часа. " (И, наконец, он объясняет, что, конечно, создается не так много GUID.)
У меня повторяющийся GUID.
Я использую настольный сканер Neat Receipts, и он поставляется с проприетарной программой для работы с базами данных. В программном обеспечении есть функция синхронизации с облаком, и при синхронизации я все время получал ошибку. При взгляде на журналы обнаружилась потрясающая строка:
"errors":[{"code":1,"message":"creator_guid: is already taken","guid":"C83E5734-D77A-4B09-B8C1-9623CAC7B167"}]}
Я немного не поверил, но, конечно же, когда я нашел путь в свою локальную базу данных neatworks и удалил запись, содержащую этот GUID, ошибка перестала возникать.
Итак, чтобы ответить на ваш вопрос анекдотическими доказательствами, нет. Возможен дубликат. Но вполне вероятно, что это произошло не случайно, а из-за несоблюдения стандартной практики. (Мне просто не повезло) Однако я не могу сказать наверняка. Это не мое программное обеспечение.
Их служба поддержки была ЧРЕЗВЫЧАЙНО вежливой и полезной, но они, должно быть, никогда раньше не сталкивались с этой проблемой, потому что после 3+ часов разговора по телефону с ними они не нашли решения. (FWIW, я очень впечатлен Neat, и этот глюк, каким бы неприятным он ни был, не изменил моего мнения об их продукте.)
Не верьте, что у вас есть дубликат. Вероятно, было что-то еще, например, номер не был действительно случайным или проблема в процессе синхронизации, или система пыталась записать дважды и т. д. Проблема с программным обеспечением гораздо более вероятна, чем получение дубликата GUID.
Алгоритмы GUID обычно реализуются в соответствии со спецификацией GUID v4, которая по сути является псевдослучайной строкой. К сожалению, они попадают в категорию "вероятно неуникальный" из Википедии (я не знаю, почему так много людей игнорируют этот бит): «... другие версии GUID имеют разные свойства и вероятности уникальности, от гарантированной уникальности до вероятной неуникальности. . "
Псевдослучайные свойства JavaScript Math.random() V8 УЖАСНЫ из-за уникальности, коллизии часто происходят после нескольких тысяч итераций, но V8 не единственный виновник. Я видел реальные конфликты GUID с использованием как PHP, так и Ruby реализаций GUID v4.
Поскольку масштабирование генерации идентификаторов между несколькими клиентами и кластерами серверов становится все более распространенным явлением, энтропия сильно страдает - шансы того, что одно и то же случайное начальное число используется для генерации идентификатора, возрастают (время часто используется как случайное начальное число в псевдослучайных генераторах), а коллизии GUID возрастают от «вероятно, неуникальный» до «очень вероятно, вызовут много проблем».
Чтобы решить эту проблему, я решил создать алгоритм идентификации, который мог бы безопасно масштабироваться и обеспечивать более надежные гарантии от столкновений. Для этого используются метка времени, счетчик клиента в памяти, отпечаток клиента и случайные символы. Комбинация факторов создает дополнительную сложность, которая особенно устойчива к конфликтам, даже если вы масштабируете ее для нескольких хостов:
От http://www.guidgenerator.com/online-guid-generator.aspx
What is a GUID?
GUID (or UUID) is an acronym for 'Globally Unique Identifier' (or 'Universally Unique Identifier'). It is a 128-bit integer number used to identify resources. The term GUID is generally used by developers working with Microsoft technologies, while UUID is used everywhere else.
How unique is a GUID?
128-bits is big enough and the generation algorithm is unique enough that if 1,000,000,000 GUIDs per second were generated for 1 year the probability of a duplicate would be only 50%. Or if every human on Earth generated 600,000,000 GUIDs there would only be a 50% probability of a duplicate.
Разве 50% -ный шанс дублирования достаточно высок, чтобы вызвать страх?
@disklosr да, этого достаточно, чтобы вызвать страх, если ваши системы генерируют 1 миллиард GUID в секунду. В крайне маловероятном случае, если вы создадите эту сумму, просто соедините два идентификатора GUID вместе ...
Если вас пугают одинаковые значения GUID, поместите два из них рядом друг с другом.
Guid.NewGuid().ToString() + Guid.NewGuid().ToString();
Если вы слишком параноик, поставьте три.
Чтобы добавить 3 GUID, нужно быть очень, очень, очень, очень параноиком.
@harsimranb Нет ... очень-очень-очень-очень параноик - это 6 GUID. Параноик - это одно, очень параноик - два, и т. д.
@Suamere Я создал сайт для расчета вашего параноидального уровня jogge.github.io/HowParanoidAmI
@Jogge xD Это потрясающе, лол. После 9 9 999999999 в вашей форме, я думаю, что Paranoia разрушит мой браузер.
Кажется, никто не упоминает фактическую математическую вероятность того, что это произойдет.
Во-первых, предположим, что мы можем использовать все 128-битное пространство (Guid v4 использует только 122 бита).
Мы знаем, что общая вероятность НЕ получить дубликат в пиках n:
(1-1/2128)(1-2/2128)...(1-(n-1)/2128)
Поскольку 2128 намного больше, чем n, мы можем приблизить это к:
(1-1/2128)n(n-1)/2
И поскольку мы можем предположить, что n намного больше 0, мы можем приблизить это к:
(1-1/2128)n^2/2
Теперь мы можем приравнять это к «приемлемой» вероятности, скажем, 1%:
(1-1/2128)n^2/2 = 0.01
Что мы решаем для n и получаем:
n = sqrt(2* log 0.01 / log (1-1/2128))
Какой Wolfram Alpha будет 5,598318 × 1019
Чтобы представить это число в перспективе, давайте возьмем 10000 машин, каждая из которых имеет четырехъядерный процессор, работает с частотой 4 ГГц и тратит 10000 циклов на создание Guid и больше ничего не делает. Тогда потребуется ~ 111 лет, прежде чем они сгенерируют дубликат.
Я отредактировал ваш пост после эта почта - пожалуйста, отредактируйте, если я допустил ошибку;).
Привет, @Cine, у меня есть возможность отредактировать ваш ответ, но я решил не делать этого, потому что я хочу дать вам возможность сначала опровергнуть его, я, вероятно, через месяц приду, чтобы официально изменить его, если я этого не сделаю. не слышу от вас. Хотя я почти уверен, что ваша математика неверна. реальное уравнение для определения вероятности 1% таково: ((2 ^ 128-1) / 2 ^ 128) ^ ((n (n-1)) / 2) = 0,01. Ваш показатель ошибочен. это не просто n. Вам понадобится C (n, 2) (aka (n * (n-1)) / 2), чтобы вычислить все комбинации, когда вы генерируете «n» направляющих. Смотрите здесь для получения дополнительной информации
Спасибо Cine, я тоже приблизился к n ^ 2/2, так как он такой огромный :)
Потребовалось бы 10000 машин 111 лет, чтобы сгенерировать каждый возможный GUID, а затем сгенерировать дубликат. Однако дубликат может возникнуть задолго до того, как будут созданы все возможные идентификаторы GUID. Я думаю, что приблизительные временные рамки будут зависеть от того, насколько «случайным» является процесс генерации GUID.
@GeorgeK Я думаю, вы неправильно поняли ... Потребовалось бы 10000 машин 111 лет, чтобы иметь 1% шанс встретить дубликат. Но да, эта математика, конечно, предполагает, что генератор случайных чисел полностью случайный.
У меня были случаи, когда GUID не были уникальными во время многопоточного / многопроцессного модульного тестирования (тоже?). Я предполагаю, что это связано, при прочих равных, с идентичным заполнением (или отсутствием заполнения) псевдослучайных генераторов. Я использовал его для создания уникальных имен файлов. Я обнаружил, что ОС справляется с этим намного лучше :)
Предупреждение о троллинге
Вы спрашиваете, уникальны ли GUID на 100%. Это зависит от количества GUID, среди которых он должен быть уникальным. Поскольку количество GUID приближается к бесконечности, вероятность дублирования GUID приближается к 100%.
В более общем смысле это известно как «проблема дня рождения» или «парадокс дня рождения». В Википедии есть неплохой обзор: Википедия - Проблема дня рождения
Грубо говоря, квадратный корень из размера пула - это грубое приближение того, когда вы можете рассчитывать на 50% вероятность дублирования. В статье представлена таблица вероятностей размера пула и различных вероятностей, включая строку для 2 ^ 128. Таким образом, для вероятности столкновения 1% вы ожидаете случайного выбора 2,6 * 10 ^ 18 128-битных чисел. Шанс 50% требует 2,2 * 10 ^ 19 пиков, а SQRT (2 ^ 128) составляет 1,8 * 10 ^ 19.
Конечно, это как раз идеальный случай действительно случайного процесса. Как уже упоминалось, многое зависит от аспекта случайный - насколько хорош генератор и сид? Было бы неплохо, если бы была некоторая аппаратная поддержка для помощи в этом процессе, которая была бы более пуленепробиваемой, за исключением того, что все может быть подделано или виртуализировано. Я подозреваю, что это может быть причиной того, что MAC-адреса / временные метки больше не включаются.
Я думаю, проблема MAC заключалась в анонимности. Я считаю, что использование идентификатора, такого как MAC-адрес, с возможностью отмены, было проблемой конфиденциальности. Я считаю, что настоящий случайный выбор в оборудовании очень сложен? Cloudflare использует камеру и ряд лавовых ламп, но я думаю, что с точным пониманием физики даже это не случайно? Лавовая лампа Cloudflares RNG: Popularmechanics.com/technology/security/news/a28921/…
Ответ "Является ли GUID 100% уникальным?" - просто "Нет".
Если вы хотите 100% уникальность GUID, сделайте следующее.
- генерировать GUID
- проверьте, существует ли этот GUID в столбце вашей таблицы, где вы ищете uniquensess
- если существует, то перейдите к шагу 1, иначе шагу 4
- используйте этот GUID как уникальный.
Это не делает его уникальным. Ваш алгоритм не сохраняет вновь созданный GUID в таблице. В следующий раз, когда вы создадите GUID, он может столкнуться с предыдущим. Если бы вы вставили GUID в таблицу, GUID уже мог быть вставлен другим одноранговым узлом между вами, проверив уникальность и вставив GUID в таблицу. GUID уникален только в ВАШЕЙ системе, поэтому, если вы импортируете или объедините две базы данных, они все равно могут столкнуться. Также GUID часто используются, когда у вас нет доступа к централизованной базе данных. Если бы у вас было, почему бы просто не вытащить идентификатор из базы данных?
Самая сложная часть не в создании дублированного Guid.
Самая сложная часть - это разработка базы данных для хранения всех сгенерированных данных, чтобы проверить, действительно ли они дублируются.
Из WIKI:
Например, количество случайных UUID версии 4, которые необходимо сгенерировать, чтобы иметь 50% -ную вероятность хотя бы одного столкновения, составляет 2,71 квинтиллион, вычисляемый следующим образом:
введите описание изображения здесь
Это число эквивалентно генерации 1 миллиарда UUID в секунду в течение примерно 85 лет, и файл, содержащий такое количество UUID, по 16 байтов на UUID, будет примерно 45 экзабайт, что во много раз больше, чем самые большие базы данных, существующие в настоящее время, которые находятся на порядка сотен петабайт
GUID - это глобальный уникальный идентификатор.
Вкратце: (разгадка в названии)
В деталях: GUID созданы, чтобы быть уникальными; они вычисляются с использованием случайного метода, основанного на часах компьютера и самом компьютере. Если вы создаете много GUID за одну миллисекунду на одном компьютере, возможно, они могут совпадать, но почти для всех обычных операций они должны считаться уникальными.
Для более лучшего результата лучше всего добавить GUID с меткой времени (просто чтобы убедиться, что он остается уникальным)
Guid.NewGuid().ToString() + DateTime.Now.ToString();
Что, если вы получите два столкновения за одну секунду?
Это наихудший случай, но все же у нас не может быть двух одинаковых Guid'ов, сгенерированных одновременно.
Где-то утверждают, что нужно копировать из ответа на SO, а не из вопроса, но сейчас я не так уверен ....
Как насчет Guid.NewGuid (). ToString (). Replace ("-", "") + DateTime.Now.Ticks .... Не вызывает сомнений в уникальности и может использоваться в качестве первичного ключа
Нет, не 100% ... Просто 99,99999999999999999999999999999999999999999999999999999999999999999999999999%;)