Когда Вы действительно вынуждены использовать UUID в качестве части дизайна?

Используя алгоритм версии 1 кажется, что это - невозможная коллизия при ограничении, что меньше чем 10 UUID на миллисекунду сгенерированы от того же MAC-адреса

Концептуально, оригинал (версия 1), схема поколения UUID состояла в том, чтобы связать версию UUID с MAC-адресом компьютера, который генерирует UUID, и с количеством интервалов с 100 наносекундами начиная с принятия Григорианского календаря на Западе. На практике фактический алгоритм более сложен. Эта схема была подвергнута критике, в котором это не достаточно 'непрозрачно'; это показывает и идентификационные данные компьютера, который генерировал UUID и время, в которое это сделало так.

Кто-то исправляет меня, если я неправильно истолковал, как это работает

В моем последнем задании мы получали объекты от третьих лиц, которые были однозначно определены с UUID. Я вставил UUID-> справочная таблица длинного целого и использовал длинное целое в качестве моих первичных ключей, потому что это был путь быстрее тот путь.

На UUID == ленивый дизайн

Я не соглашаюсь о выборе Ваших поединков. Если дублирующийся UUID статистически невозможен, и математика доказана затем почему беспокойство? Пребывание в течение времени, разрабатывая на основе Вашей маленькой генерирующейся системы UUID N непрактично, всегда существует дюжина других способов, которыми можно улучшить систему.

Классический пример - когда Вы копируете между двумя базами данных.

DB (A) вставляет запись с международным идентификатором 10 и в то же время, DB (B) создает запись с в идентификаторе 10. Это - коллизия.

С UUID этого не произойдет, поскольку они не будут соответствовать. (почти наверняка)

Существует также ненулевая вероятность, что каждая частица в Вашем теле одновременно туннелирует через стул, на котором Вы сидите, и Вы будете внезапно сидеть на полу.

Вы волнуетесь об этом?

Никогда не абсолютно необходимо создать UUID. Однако удобно иметь стандарт, где офлайновые пользователи могут каждый генерировать ключ к чему-то с очень низкой вероятностью коллизии.

Это может помочь в разрешении репликации баз данных и т.д...

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

Так или иначе, слово на вероятности коллизии, взятой из Википедии:

Для рассматривания этих чисел в истинном свете ежегодный риск того, чтобы быть пораженным метеоритом, как оценивается, является одним шансом в 17 миллиардах, эквивалентных разногласиям создания нескольких десятков из триллионов UUID через год и наличия одного дубликата. Другими словами, только после генерации 1 миллиарда UUID каждую секунду в течение следующих 100 лет, вероятности создания всего один дубликат составил бы приблизительно 50%.

Акцент на "обоснованно" или, как Вы выразились, "эффективно": достаточно хороший то, как реальный мир работает. Объем вычислительной работы, вовлеченной в покрытие того разрыва между "практически уникальным" и "действительно уникальным", огромен. Уникальность является кривой с убывающей доходностью. В какой-то момент на той кривой, существует строка между тем, где "достаточно уникальный" все еще доступно, и затем мы изгибаемся ОЧЕНЬ круто. Стоимость добавления большей уникальности становится довольно большой. Уникальность Бога имеет бесконечную стоимость.

UUID/GUID является, собственно говоря, в вычислительном отношении быстрым и простым способом генерировать идентификатор, который, как может обоснованно предполагаться, универсально уникален. Это очень важно во многих системах, которые должны интегрировать данные из ранее не связанных систем. Например: если у Вас есть Система управления контентом, которая работает на двух различных платформах, но в какой-то момент должна импортировать содержание из одной системы в другой. Вы не хотите, чтобы идентификаторы изменились, таким образом, Ваши ссылки между данными из системы A остаются неповрежденными, но Вы не хотите коллизий с данными, созданными в системе B. UUID решает это.

Вещь, что UUID покупают Вас, который очень трудно сделать иначе, состоит в том, чтобы получить уникальный идентификатор, не имея необходимость консультироваться или координировать с центральной властью. Общей проблемой способности получить такую вещь без своего рода управляемой инфраструктуры является проблема, которую решают UUID.

Я считал, что согласно парадоксу дня рождения шанс появления коллизии UUID составляет 50% однажды 2^64, UUID были сгенерированы. Теперь 2^64 довольно большое количество, но 50%-й шанс коллизии кажется слишком опасным (например, сколько должны существовать UUID, прежде чем будет 5%-й шанс коллизии - даже, который походит слишком большой из вероятности).

Проблема с тем анализом является двукратной:

1. UUID не совсем случайны - существуют главные компоненты UUID, которые время и/или основаны на местоположении. Таким образом, чтобы иметь любой реальный шанс в коллизии, сталкивающимся UUID нужен tobe, сгенерированный в то же самое время от различных генераторов UUID. Я сказал бы, что, в то время как существует разумный шанс, что несколько UUID могли бы быть сгенерированы одновременно, существует достаточно другого месива (включая информацию о местоположении или случайные биты) для создания likeyhood коллизии между этим очень маленьким набором UUID почти невозможным.

2. строго говоря UUID только должны быть уникальными среди набора других UUID, с которыми они могли бы быть сравнены. При генерации UUID для использования в качестве ключа базы данных, не имеет значения, если где-то в другом месте в злой альтернативной вселенной, что тот же UUID используется для идентификации COM-интерфейса. Точно так же, как это не вызовет беспорядка, если будет кто-то (или что-то) еще назван "Michael Burr" на Альфе-Centauri.

Все имеет ненулевой шанс отказа. Я сконцентрировался бы на намного более вероятно для появления проблем (т.е. почти что-либо, о чем можно думать), чем коллизия UUID

Если вы просто посмотрите на альтернативы E.g. Для простого приложения базы данных необходимо запрашивать базу данных каждый раз, прежде чем создать новый объект, вы скоро найдете, что использование UUID может эффективно уменьшить к сложности вашей системы. Предоставлено - если вы используете int Keys, - это 32бит, который будет хранить в четверть 128бит UUID. Удаленные алгоритмы генерации UUID принимают больше вычислительной мощности, чем просто увеличивая число. Но кого это волнует? Накладные расходы на управление «властью» присвоить иначе уникальные числа легко перевешивают, что по порядкам величины, в зависимости от предполагаемой идентификатора уникальности.

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

За исключением того, что с этим связаны некоторые реальные практические проблемы, даже если мы проигнорируем откровенную злобу. В частности, этот сервер может выйти из строя или стать недоступным из части Интернета. Работа с отказом сервера требует репликации, и это очень сложно разобраться (см. Литературу по алгоритму Paxos, чтобы узнать, почему достижение консенсуса неудобно), и это тоже довольно медленно. Более того, если все серверы недоступны из определенной части сети, ни один из клиентов, подключенных к этой подсети, не сможет что-либо сделать, потому что все они будут ждать новых идентификаторов.

Итак ... используйте простой вероятностный алгоритм для их генерации, который вряд ли выйдет из строя в течение всего жизненного цикла Земли, или (профинансируйте и) создайте основную инфраструктуру, которая будет представлять собой PITA развертывания и будет иметь частые сбои. Я знаю, какой я бы выбрал.