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

Я не вижу смысла в UUID . Я знаю, что вероятность столкновения фактически равна нулю , но фактически ноль даже близко не к невозможному.

Может кто-нибудь привести пример, когда у вас нет другого выбора, кроме как использовать UUID? Из всех применений, которые я видел, я вижу альтернативный дизайн без UUID. Конечно, конструкция может быть немного сложнее, но, по крайней мере, у нее нет ненулевой вероятности отказа.

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

Я написал генератор / парсер UUID для Ruby, поэтому считаю себя достаточно хорошо осведомленным по этому поводу. Существует четыре основных версии UUID:

UUID версии 4 - это, по сути, всего лишь 16 байтов случайности, извлеченные из криптографически безопасного генератора случайных чисел, с некоторым изменением битов для идентификации версии и варианта UUID. Они крайне маловероятны, чтобы столкнуться, но это может произойти, если используется ГПСЧ или если вам просто действительно, очень, очень, очень, очень не повезло.

UUID версии 5 и версии 3 используют хэш-функции SHA1 и MD5 соответственно, чтобы объединить пространство имен с частью уже уникальных данных для генерации UUID. Это, например, позволит вам создать UUID из URL-адреса. Коллизии здесь возможны только в том случае, если основная хеш-функция также имеет коллизию.

UUID версии 1 являются наиболее распространенными. Они используют MAC-адрес сетевой карты (который, если он не подделан, должен быть уникальным), плюс временная метка, а также обычная перестановка битов для генерации UUID. В случае машины, у которой нет MAC-адреса, 6 байтов узла генерируются криптографически безопасным генератором случайных чисел. Если два UUID генерируются последовательно достаточно быстро, чтобы метка времени совпадала с предыдущим UUID, метка времени увеличивается на 1. Коллизии не должны происходить, если не произойдет одно из следующих событий: MAC-адрес подделан; Одна машина, на которой запущены два разных приложения, генерирующих UUID, генерирует UUID в один и тот же момент; Две машины без сетевой карты или без доступа уровня пользователя к MAC-адресу получают одинаковую случайную последовательность узлов и генерируют UUID в один и тот же момент;

На самом деле ни одно из этих событий не происходит случайно в пространстве идентификаторов одного приложения. Если вы не принимаете идентификаторы, скажем, в масштабе всего Интернета или в ненадежной среде, где злоумышленники могут сделать что-то плохое в случае конфликта идентификаторов, вам не о чем беспокоиться. Очень важно понимать, что если вам случится сгенерировать тот же UUID версии 4, что и я, в большинстве случаев это не имеет значения. Я сгенерировал идентификатор в совершенно другом месте, отличном от вашего. Мое приложение никогда не узнает о столкновении, поэтому столкновение не имеет значения. Откровенно говоря, в едином пространстве приложений без злонамеренных субъектов исчезновение всего живого на Земле произойдет задолго до того, как вы столкнетесь, даже с UUID версии 4, даже если вы

Кроме того, 2 ^ 64 * 16 составляет 256 эксабайт. Например, вам нужно будет хранить идентификаторы на 256 экзабайт, прежде чем у вас будет 50% вероятность конфликта идентификаторов в одном пространстве приложения.

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

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

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

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

2. строго говоря, UUID должны быть уникальными только среди набора других UUID, с которыми они могут сравниваться. Если вы генерируете UUID для использования в качестве ключа базы данных, не имеет значения, используется ли где-то еще в злой альтернативной вселенной, что тот же UUID используется для идентификации COM-интерфейса. Точно так же не вызовет путаницы, если на Альфа-Центавре есть кто-то (или что-то еще) по имени Майкл Бёрр.

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

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

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

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

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

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

В любом случае, слово о вероятности столкновения взято из Википедии:

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

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

DB (A) вставляет запись с int ID 10 и в то же время DB (B) создает запись с идентификатором in 10. Это коллизия.

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

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

Вы беспокоитесь об этом?

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

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

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

я не понимаю всех разговоров о вероятности столкновения. Меня не волнуют столкновения. Хотя я забочусь о производительности.

https://dba.stackexchange.com/a/119129/33649

UUID - это катастрофа для производительности очень больших таблиц. (200 КБ строк не очень большие.)

Ваш № 3 действительно плох, когда CHARCTER SET - utf8 - CHAR (36) занимает 108 байтов!

UUID (GUID) очень "случайны". Использование их в качестве УНИКАЛЬНЫХ или ПЕРВИЧНЫХ ключей для больших таблиц очень неэффективно. Это связано с тем, что вам нужно перемещаться по таблице / индексу каждый раз, когда вы ВСТАВЛЯЕТЕ новый UUID или ВЫБИРАЕТЕ по UUID. Когда таблица / индекс слишком велики, чтобы поместиться в кеш (см. Innodb_buffer_pool_size, который должен быть меньше ОЗУ, обычно 70%), «следующий» UUID может не кэшироваться, следовательно, медленное обращение к диску. Когда таблица / индекс в 20 раз больше кеша, кэшируется только 1/20 (5%) попаданий - вы ограничены вводом-выводом.

Итак, не используйте UUID, если только

у вас есть «маленькие» таблицы или они вам действительно нужны из-за генерации уникальных идентификаторов из разных мест (и вы не придумали другого способа сделать это). Подробнее о UUID: http://mysql.rjweb.org/doc.php/uuid (он включает функции для преобразования между стандартными 36-символьными UUID и BINARY (16).)

Иметь как UNIQUE AUTO_INCREMENT, так и UNIQUE UUID в одной и той же таблице - пустая трата.

Когда происходит INSERT, все уникальные / первичные ключи должны быть проверены на наличие дубликатов. Любого уникального ключа достаточно для требования InnoDB иметь ПЕРВИЧНЫЙ КЛЮЧ. BINARY (16) (16 байтов) несколько громоздко (аргумент против того, чтобы сделать его PK), но не так уж плохо. Громоздкость имеет значение, когда у вас есть вторичные ключи. InnoDB незаметно прикрепляет ПК к концу каждого вторичного ключа. Главный урок здесь - минимизировать количество вторичных ключей, особенно для очень больших таблиц. Для сравнения: INT UNSIGNED - это 4 байта с диапазоном 0..4 миллиарда. BIGINT составляет 8 байтов.

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

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

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

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

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

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

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

Тем, кто говорит, что UUID - это плохой дизайн, потому что они могут (с некоторой смехотворно малой вероятностью) столкнуться, в то время как ключи, сгенерированные вашей БД, не ... -предвиденная необходимость ДАЛЕКО ДАЛЕКО выше, чем вероятность столкновения UUID4. Мы знаем, что если база данных будет воссоздана, ее идентификаторы снова будут начинаться с 1, и скольким из нас приходилось воссоздавать таблицу, когда мы были уверены, что нам это никогда не понадобится? Я бы вложил свои деньги в безопасность UUID, когда в любой день что-то пойдет не так с неизвестным-неизвестным.

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

Да, теоретически возможно столкновение UUID. Как отмечали другие, это до смешного маловероятно, что об этом просто не стоит думать. Этого никогда не было и, скорее всего, никогда не будет. Забудь об этом.

Самый «очевидный» способ избежать коллизий - позволить одному серверу генерировать уникальные идентификаторы для каждой вставки, что, очевидно, создает серьезные проблемы с производительностью и вообще не решает проблему автономной генерации. К сожалению.

Другое «очевидное» решение - это центральный орган, который заранее раздает блоки уникальных номеров, что, по сути, и делает UUID V1, используя MAC-адрес генерирующей машины (через IEEE OUI). Но дублирование MAC-адресов действительно происходит, потому что каждый центральный орган в конечном итоге облажается, поэтому на практике это гораздо более вероятно, чем конфликт UUID V4. К сожалению.

Лучший аргумент против использования UUID - то, что они «слишком велики», но (значительно) меньшая схема неизбежно не сможет решить самые интересные проблемы; Размер UUID является неотъемлемым побочным эффектом их полезности для решения этих самых проблем.

Возможно, ваша проблема недостаточно велика, чтобы требовать того, что предлагают UUID, и в этом случае не стесняйтесь использовать что-то еще. Но если ваша проблема неожиданно нарастает (а это происходит в большинстве случаев), вы в конечном итоге переключитесь на нее позже - и начнете ругать себя за то, что не использовали их вообще. Зачем проектировать на неудачу, если вместо этого просто проектировать на успех?

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

Недавно столкнулся с такой проблемой при замене принтера на точную заменяющую модель и обнаружил, что ни одно клиентское программное обеспечение не работает.