Универсальный уникальный идентификатор

Универсальный уникальный идентификатор

UUID/GUID, используемый UEFI переменными
Акроним	UUID
Организация	Фонд открытого программного обеспечения (OSF), ISO / IEC , Рабочая группа по разработке Интернета (IETF)
Количество цифр	32
Пример	123e4567-e89b-12d3-a456-426614174000
Веб-сайт	RFC   9562 (устарел) RFC   4122 )

Универсальный уникальный идентификатор ( UUID ) — это 128-битная метка , используемая для информации в компьютерных системах. Термин «глобальный уникальный идентификатор» ( GUID ) также используется, в основном в системах Microsoft.

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

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

Принятие UUID широко распространено: многие вычислительные платформы поддерживают их создание и анализ их текстового представления.

История

В 1980-х годах компания Apollo Computer первоначально использовала UUID в сетевой вычислительной системе (NCS). Позже Фонд открытого программного обеспечения (OSF) использовал UUID для своей распределенной вычислительной среды (DCE). Дизайн UUID DCE был частично основан на UUID NCS. чей дизайн, в свою очередь, был вдохновлен ( 64-битными ) уникальными идентификаторами, определенными и повсеместно используемыми в Domain/OS , операционной системе, разработанной Apollo Computer. Позже, платформы Microsoft Windows приняли дизайн DCE как «глобальные уникальные идентификаторы» (GUID).

RFC   4122 зарегистрировал пространство имен URN для UUID и повторил предыдущие спецификации с тем же техническим содержанием. Когда в июле 2005 г. RFC   4122 был опубликован как предложенный стандарт IETF , ITU также стандартизировал UUID на основе предыдущих стандартов и ранних версий РФК   4122 . 7 мая 2024 г. RFC   9562 Был опубликован , в котором представлены 3 новые «версии» и прояснены некоторые неясности.

Стандарты

UUID стандартизированы Open Software Foundation (OSF) как часть распределенной вычислительной среды (DCE).

UUID задокументированы в стандарте ISO / IEC 11578:1996 « Информационные технологии – Взаимодействие открытых систем – Удаленный вызов процедур (RPC)», а в последнее время – в Рек. ITU-T Rec. Х.667 | ИСО / МЭК 9834-8:2014.

Рабочая группа по проектированию Интернета (IETF) опубликовала «Стандартный трек». RFC   9562 из «Рабочой группы по пересмотру определений универсально уникальных идентификаторов» как доработка для РФК   4122 . RFC   4122 технически эквивалентен Рекомендации ITU-T Rec. Х.667 | ISO/IEC 9834-8, но сейчас он устарел.

Двоичный формат провода

UUID — это 128-битная метка. Первоначально компания Apollo Computer разработала UUID со следующим форматом проводов:

Устаревший формат провода

Имя	Компенсировать	Длина	Описание
time_high	0x00	4 октета/32 бита	Первые 6 октетов представляют собой количество единиц времени в четыре микросекунды (мкс), прошедших с 01.01.1980 00:00 UTC . Время 2 48 × 4 мкс после начала 1980 года было 05.09.2015 05:58:26.84262 UTC. Таким образом, последний раз, когда UUID можно было генерировать в этом исходном формате, был в 2015 году.
time_low	0x04	2 октета/16 бит
сдержанный	0x06	2 октета/16 бит	Эти октеты зарезервированы для использования в будущем.
семья	0x08	1 октет/8 бит	Этот октет представляет собой семейство адресов.
узел	0x09	7 октетов/56 бит	Эти октеты представляют собой идентификатор хоста в форме, разрешенной указанным семейством адресов.

Позже UUID был расширен за счет объединения устаревшего поля семейства с новым полем варианта. Поскольку в прошлом в поле семейства использовались только значения от 0 до 13, было решено, что UUID, у которого старший бит установлен в 0, является устаревшим UUID. Это дает следующую таблицу для семейной группы:

Поле семейства/варианта

старший бит 0	старший бит 1	старший бит 2	Диапазон значений поля устаревшего семейства	В шестнадцатеричном формате	Описание
0	х	х	0–127 (используются только 0–13)	0x00–0x7f	Устаревший UUID Apollo NCS
1	0	х	128–191	0x80–0xbf	UUID OSF DCE
1	1	0	192–223	0xc0–0xdf	UUID Microsoft COM/DCOM
1	1	1	224–255	0xe0–0xff	Зарезервировано для будущего определения

Устаревший UUID Apollo NCS имеет формат, описанный в предыдущей таблице. Вариант OSF DCE UUID описан в RFC   9562 . Вариант UUID Microsoft COM/DCOM описан в документации Microsoft.

Чтобы облегчить человеческое чтение, группы обычно представляются в шестнадцатеричном формате, где группы разделяются символом тире ( - ).

Текстовое представление

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

В большинстве случаев UUID представлены в виде шестнадцатеричных значений. Наиболее часто используемый формат — 8-4-4-4-12. xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, где каждый x представляет собой 4 бита. Другими известными форматами являются формат 8-4-4-4-12 со скобками, {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}, как в системах Microsoft, например Windows, или xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, где все дефисы удалены. В некоторых случаях также возможно наличие xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx с префиксом «0x» или суффиксом «h» для обозначения шестнадцатеричных значений. Формат с дефисами был введен в новой системе вариантов. До этого в устаревшем формате Apollo использовался немного другой формат: 34dc23469000.0d.00.00.7c.5f.00.00.00. Первая часть — это время (time_high и time_low вместе взятые). Зарезервированное поле пропускается. Поле семейства идет сразу после первой точки, поэтому в данном случае 0d (13 в десятичном формате) для DDS (службы распространения данных) . Остальные части, разделенные точкой, представляют собой байты узла.

Обычно предпочтительным форматом является строчная форма шестнадцатеричных значений. В частности, в некоторых контекстах, например, определенных в Рекомендации МСЭ-Т. X.667, при создании текста требуются строчные буквы, но также должна быть принята версия в верхнем регистре.

UUID может быть представлен как 128-битное целое число. Например, UUID 550e8400-e29b-41d4-a716-446655440000 также может быть представлено как 113059749145936325402354257176981405696. Обратите внимание, что можно иметь как знаковые, так и беззнаковые значения, если первый бит UUID установлен в 1.

UUID может быть представлен как 128-битное двоичное число . Например, UUID 550e8400-e29b-41d4-a716-446655440000 также может быть представлено как 0101010100001110100001000000000011100010100110110100000111010100101001110001011001000100011001100101010101000100000 0000000000000.

RFC   9562 регистрирует пространство имен «uuid». Это позволяет создавать URN из UUID, например urn:uuid:550e8400-e29b-41d4-a716-446655440000. Для этого используется обычный формат 8-4-4-4-12. Также возможно создать OID URN из UUID, например urn:oid:2.25.113059749145936325402354257176981405696. В этом случае используется десятичный формат без знака. UUID «uuid» рекомендуется использовать вместо URN «oid».

Варианты

Поле варианта указывает формат UUID (а в случае устаревшего UUID также семейство адресов, используемое для поля узла). Определены следующие варианты:

• Вариант Apollo NCS (обозначенный однобитовым шаблоном 0xxx ₂ ) предназначен для обратной совместимости с ныне устаревшим форматом UUID Apollo Network Computing System 1.5, разработанным примерно в 1988 году. Хотя он и отличается в деталях, сходство с современным UUIDv1 очевидно. Биты вариантов в текущей спецификации UUID совпадают со старшими битами октета семейства адресов в UUID NCS. Хотя семейство адресов могло содержать значения в диапазоне 0–255, всегда были определены только значения 0–13. Соответственно, битовая комбинация 0xxx позволяет избежать конфликтов с историческими UUID NCS, если они все еще существуют в базах данных. Этот вариант определяет «семьи» как подтип.
• Вариант OSF DCE (10xx ₂ ) называется UUID RFC 4122/DCE 1.1 или UUID «Leach – Salz» в честь авторов исходного Интернет-проекта . Этот вариант определяет «версии» как подтип.
• Вариант Microsoft COM/DCOM (110x ₂ ) охарактеризован в RFC как «зарезервированная обратная совместимость Microsoft Corporation» и использовался для ранних GUID на платформе Microsoft Windows .
• Пространство зарезервированных вариантов в настоящее время не используется ни одной спецификацией.

Версии

Вариант OSF DCE определяет в стандарте восемь «версий», и каждая версия может быть более подходящей, чем другие, в конкретных случаях использования. Версия указывается значением старшего полубайта (старшие 4 бита или старшая шестнадцатеричная цифра) 7-го байта UUID. В шестнадцатеричном формате это символ после второго тире. Например, UUID 9c5b94b1-35ad-49bb-b118-8e8fc24abf80 это версия 4, так как цифра после второго тире равна 4 в ...-49bb-....

Версии 1 и 6 (дата-время и MAC-адрес)

Версия 1 объединяет 48-битный MAC-адрес «узла» (то есть компьютера, генерирующего UUID) с 60-битной меткой времени, представляющей собой количество 100- наносекундных интервалов с полуночи 15 октября 1582 года по всемирному координированному времени (UTC). ), дата, когда григорианский календарь был впервые принят большей частью Европы, в которой в то время доминировала римско-католическая Испания. В RFC 4122 указано, что значение времени переходит примерно в 3400 год нашей эры. в зависимости от используемого алгоритма, что подразумевает, что 60-битная временная метка является величиной со знаком. Однако некоторые программы, такие как библиотека libuuid, рассматривают временную метку как беззнаковую, помещая время перехода в 5623 год нашей эры. Время пролонгации, определенное в Рекомендации МСЭ-Т. X.667 — это 3603 год нашей эры.

13-битная или 14-битная «унифицирующая» тактовая последовательность расширяет временную метку для обработки случаев, когда тактовая частота процессора увеличивается недостаточно быстро или когда на каждом узле имеется несколько процессоров и генераторов UUID. Когда UUID генерируются быстрее, чем могут двигаться системные часы, младшие биты полей метки времени могут генерироваться путем их увеличения каждый раз, когда генерируется UUID, для имитации метки времени с высоким разрешением. Поскольку каждый UUID версии 1 соответствует одной точке пространства (узлу) и времени (интервалам и последовательности часов), вероятность того, что два правильно сгенерированных UUID версии 1 непреднамеренно окажутся одинаковыми, практически равна нулю. Поскольку общая длина последовательности времени и часов составляет 74 бита, 2 ⁷⁴ (1.8 × 10 ²² или 18 секстиллионов) UUID версии 1 могут быть сгенерированы для каждого идентификатора узла с максимальной средней скоростью 163 миллиарда в секунду на каждый идентификатор узла.

В отличие от других версий UUID, UUID версии 1 и -2, основанные на MAC-адресах сетевых карт, в своей уникальности частично полагаются на идентификатор, выданный центральным органом регистрации, а именно уникальный идентификатор организации на часть MAC-адреса, содержащую (OUI). , который выдается IEEE производителям сетевого оборудования. Уникальность UUID версий 1 и 2, основанных на MAC-адресах сетевых карт, также зависит от того, правильно ли производители сетевых карт назначают уникальные MAC-адреса своим картам, что, как и другие производственные процессы, подвержено ошибкам. Кроме того, некоторые операционные системы позволяют конечному пользователю настраивать MAC-адрес, особенно OpenWRT .

Использование MAC-адреса сетевой карты узла для идентификатора узла означает, что UUID версии 1 можно отследить до компьютера, который его создал. Иногда документы можно отследить до компьютеров, на которых они были созданы или отредактированы, с помощью UUID, встроенных в них с помощью программного обеспечения для обработки текста . Эта дыра в конфиденциальности была использована при поиске создателя вируса Melissa .

RFC   9562 позволяет заменять MAC-адрес в UUID версии 1 (или 2) случайным 48-битным идентификатором узла либо потому, что узел не имеет MAC-адреса, либо потому, что его нежелательно раскрывать. В этом случае RFC требует, чтобы младший бит первого октета идентификатора узла был установлен в 1. Это соответствует биту многоадресной рассылки в MAC-адресах, и его установка служит для различения UUID, где идентификатор узла генерируется случайным образом из UUID на основе MAC-адресов сетевых карт, которые обычно имеют одноадресные MAC-адреса.

Версия 6 аналогична версии 1, за исключением того, что все биты времени расположены в противоположном порядке. Это даст системам возможность сортировки в порядке создания по UUID, где это было невозможно в версии 1.

Версия 2 (дата, время и MAC-адрес, версия безопасности DCE)

RFC   9562 резервирует версию 2 для UUID «безопасности DCE»; но он не дает никаких подробностей. По этой причине во многих реализациях UUID версия 2 отсутствует. Однако спецификация UUID версии 2 предоставляется спецификацией служб аутентификации и безопасности DCE 1.1.

UUID версии 2 аналогичны версии 1, за исключением того, что младшие 8 бит тактовой последовательности заменяются номером «локального домена», а младшие 32 бита временной метки заменяются целочисленным идентификатором, имеющим смысл в пределах указанного локальный домен. В системах POSIX номера локального домена 0 и 1 предназначены для идентификаторов пользователей ( UID ) и идентификаторов групп ( GID ) соответственно, а другие номера локального домена определяются сайтом. В системах, отличных от POSIX, все номера локальных доменов определяются сайтом.

Возможность включения 40-битного домена/идентификатора в UUID требует компромисса. С одной стороны, 40 бит позволяют использовать около 1 триллиона значений домена/идентификатора на каждый идентификатор узла. С другой стороны, при усечении значения часов до 28 старших битов по сравнению с 60 битами в версии 1, часы в UUID версии 2 будут «тикать» только один раз каждые 429,49 секунды, что чуть больше 7 минут, поскольку в отличие от каждых 100 наносекунд в версии 1. И при тактовой последовательности всего 6 бит по сравнению с 14 битами в версии 1, за 7-минутный такт может быть сгенерировано только 64 уникальных UUID для каждого узла/домена/идентификатора по сравнению с 16 384 значения тактовой последовательности для версии 1. Таким образом, версия 2 может не подходить для случаев, когда требуются UUID для каждого узла/домена/идентификатора со скоростью, превышающей примерно один раз каждые семь минут.

Версии 3 и 5 (на основе имени пространства имен)

UUID версий 3 и 5 генерируются путем хеширования идентификатора и имени пространства имен . Версия 3 использует MD5 в качестве алгоритма хеширования, а версия 5 использует SHA-1 .

Идентификатор пространства имен сам по себе является UUID. Спецификация предоставляет UUID для представления пространств имен для URL-адресов , полных доменных имен , идентификаторов объектов и X.500 отличительных имен ; но любой желаемый UUID может использоваться в качестве указателя пространства имен.

Чтобы определить UUID версии 3, соответствующий данному пространству имен и имени, UUID пространства имен преобразуется в строку байтов, объединяется с входным именем, а затем хешируется с помощью MD5, что дает 128 бит. Затем 6 или 7 бит заменяются фиксированными значениями, 4-битной версией (например, 0011 ₂ для версии 3) и 2- или 3-битным «вариантом» UUID (например, 10 _2, обозначающим UUID RFC   9562 или 110 ₂ , указывающий устаревший GUID Microsoft). Поскольку таким образом заранее определены 6 или 7 бит, только 121 или 122 бита способствуют уникальности UUID.

UUID версии 5 аналогичны, но вместо MD5 используется SHA-1. Поскольку SHA-1 генерирует 160-битные дайджесты, перед заменой битов версии и варианта дайджест усекается до 128 бит.

UUID версии 3 и версии 5 обладают свойством, согласно которому одно и то же пространство имен и имя будут сопоставлены с одним и тем же UUID. Однако ни пространство имен, ни имя не могут быть определены по UUID, даже если один из них указан, кроме как методом перебора. RFC   4122 рекомендует версию 5 (SHA-1) вместо версии 3 (MD5) и предостерегает от использования UUID любой версии в качестве учетных данных безопасности.

Версия 4 (случайная)

UUID версии 4 генерируется случайным образом. Как и в других UUID, для обозначения версии 4 используются 4 бита, а для обозначения варианта — 2 или 3 бита (10 ₂ или 110 ₂ для вариантов 1 и 2 соответственно). Таким образом, для варианта 1 (то есть большинства UUID) случайный UUID версии 4 будет иметь 6 заранее определенных битов варианта и версии, оставляя 122 бита для случайно сгенерированной части, всего 2 ¹²² , или 5,3 × 10 ³⁶ (5,3 ундециллиона ) возможных UUID версии 4 варианта 1. Существует вдвое меньше возможных UUID версии 4 и варианта 2 (устаревшие GUID), поскольку доступно на один случайный бит меньше, а для варианта используется 3 бита.

Пер RFC   9562 , 4 старших бита седьмого октета указывают, какой версии соответствует UUID. Это означает, что первая шестнадцатеричная цифра в третьей группе всегда начинается с цифры. 4 в UUIDv4s. Визуально это выглядит так xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, где M поле версии UUID. Верхние два или три бита цифры N закодируйте вариант. Например, случайный UUID версии 4, вариант 2 может быть 8D8AC610-566D-4EF0-9C22-186B2A5ED793.

Версия 7 (метка времени и случайная)

UUID версии 7 (UUIDv7) предназначены для ключей в высоконагруженных базах данных и распределенных системах.

UUIDv7 начинается с 48-битной временной метки эпохи Unix с обратным порядком байтов и точностью до миллисекунды. Временная метка может быть сдвинута на любое значение временного сдвига. Сразу после временной метки следует полубайт версии, который должен иметь значение 7. Биты варианта должны быть 10x. Остальные 74 бита представляют собой счетчик случайного заполнения (необязательно, не менее 12 бит, но не длиннее 42 бит) и случайны.

Два метода обработки опрокидывания счетчика могут использоваться вместе:

• Самый значимый, крайний левый защитный бит счетчика с нулевым заполнением.
• Увеличьте временную метку раньше фактического времени и повторно инициализируйте счетчик при его переполнении.

В СУБД генератор UUIDv7 может быть общим между потоками (привязанным к таблице или экземпляру СУБД) или может быть локальным для потока (с худшей монотонностью, локальностью и производительностью).

Версия 8 (индивидуальная)

Версия 8 имеет только два требования:

• Биты вариантов должны быть 10x.
• Полубайт версии должен иметь значение 8.

Эти требования сообщают системе, что это UUID версии 8. Остальные 122 бита могут быть настроены поставщиком. Разница с версией 4 заключается в том, что эти 122 бита являются случайными, а 122 бита в UUID версии 8 — нет, поскольку они следуют правилам, специфичным для поставщика.

Специальные UUID

«Нулевой» UUID — это UUID. 00000000-0000-0000-0000-000000000000; то есть все биты установлены в ноль.

«Максимальный» UUID, иногда также называемый «омни» UUID, — это UUID. FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF; то есть все биты установлены в единицу.

Кодирование

Двоичное кодирование UUID варьируется в зависимости от системы. UUID варианта 1, в настоящее время наиболее распространенный вариант, закодированы в формате с прямым порядком байтов . Например, 00112233-4455-6677-8899-aabbccddeeff кодируется как байты 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff.

UUID варианта 2, исторически использовавшиеся в библиотеках Microsoft COM/OLE , используют формат с прямым порядком байтов , но выглядят со смешанным порядком байтов: первые три компонента UUID имеют прямой порядок байтов , а последние два — с прямым порядком байтов из-за отсутствия байтовых тире. при форматировании как строка. Например, 00112233-4455-6677-8899-aabbccddeeff кодируется как байты 33 22 11 00 55 44 77 66 88 99 aa bb cc dd ee ff.

Столкновения

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

В отличие от UUID версии 1 и версии 2, сгенерированных с использованием MAC-адресов, с UUID версии 1 и -2, которые используют случайно сгенерированные идентификаторы узлов, UUID версий 3 и 5 на основе хэша, а также случайные UUID версии 4, коллизии могут возникать даже без проблем с реализацией, хотя и с вероятностью настолько малой, что ее обычно можно игнорировать. Эту вероятность можно точно вычислить на основе анализа проблемы дня рождения .

Например, количество случайных UUID версии 4, которые необходимо сгенерировать, чтобы иметь 50% вероятность хотя бы одного столкновения, составляет 2,71 квинтиллиона и рассчитывается следующим образом:

$n\approx {\frac {1}{2}}+{\sqrt {{\frac {1}{4}}+2\times \ln(2)\times 2^{122}}}\approx 2.71\times 10^{18}.$

Это число эквивалентно генерации 1 миллиарда UUID в секунду в течение примерно 86 лет. Файл, содержащий такое количество UUID (по 16 байт на UUID), будет иметь размер около 45 эксабайт .

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

${\sqrt {2\times 2^{122}\times \ln {\frac {1}{1-p}}}}.$

Таким образом, вероятность найти дубликат среди 103 триллионов UUID версии 4 составляет один на миллиард.

Конфликты происходили, когда производители присваивали продукту UUID по умолчанию, например материнской плате, а затем не могли перезаписать UUID по умолчанию на более позднем этапе производственного процесса. Например, UUID 03000200-0400-0500-0006-000700080009 встречается на многих различных материнских платах Gigabyte.

Использование

Значительное использование включает в себя ext2 / ext3 / ext4 инструменты пользовательского пространства файловой системы ( e2fsprogs использует libuuid, предоставляемый util-linux ), LVM , LUKS зашифрованные разделы , GNOME , KDE и macOS . большинство из которых взято из оригинальной реализации Теодора Цо . Одним из применений UUID в Solaris (с использованием реализации Open Software Foundation) является идентификация работающего экземпляра операционной системы с целью сопоставления данных аварийного дампа с событием управления сбоями в случае паники ядра. «Метка раздела» и «UUID раздела» хранятся в суперблоке . Они оба являются частью файловой системы, а не раздела. Например, ext2–4 содержат UUID, а NTFS или FAT32 — нет. Суперблок является частью файловой системы и поэтому полностью содержится в разделе. dd if=/dev/sda1 of=/dev/sdb1 оставляет как sda1, так и sdb1 с одной и той же меткой и UUID.

Microsoft (COM) используется несколько разновидностей GUID В объектной модели компонентов :

• IID – идентификатор интерфейса; (Те, которые зарегистрированы в системе, хранятся в реестре Windows по адресу [HKEY_CLASSES_ROOT\Interface] )
• CLSID – идентификатор класса; (Хранится по адресу [HKEY_CLASSES_ROOT\CLSID])
• LIBID – идентификатор библиотеки типов; (Хранится по адресу [HKEY_CLASSES_ROOT\TypeLib])
• CATID – идентификатор категории; (его присутствие в классе идентифицирует его как принадлежность к определенным категориям классов, перечисленным в [HKEY_CLASSES_ROOT\Component Categories])

UUID обычно используются в качестве уникального ключа в таблицах базы данных . Функция NEWID в Microsoft SQL Server версии 4 Transact-SQL возвращает стандартные случайные UUID версии 4, а функция NEWID в Microsoft SQL Server версии 4. Transact-SQL возвращает стандартные случайные UUID версии 4. Функция NEWSEQUENTIALID возвращает 128-битные идентификаторы, аналогичные UUID, которые будут последовательно возрастать до следующей перезагрузки системы. База данных Oracle Функция SYS_GUID не возвращает стандартный GUID, несмотря на имя. Вместо этого он возвращает 16-байтовое 128-битное значение RAW на основе идентификатора хоста и идентификатора процесса или потока, что чем-то похоже на GUID. PostgreSQL содержит UUID Тип данных и может генерировать большинство версий UUID с помощью функций модулей. MySQL предоставляет Функция UUID , которая генерирует стандартные UUID версии 1. Случайный характер стандартных UUID версий 3, 4 и 5, а также порядок полей в стандартных версиях 1 и 2 могут создать проблемы с локальностью базы данных или производительностью, когда UUID используются в качестве первичных ключей . Например, в 2002 году Джимми Нильссон сообщил о значительном улучшении производительности Microsoft SQL Server, когда UUID версии 4, используемые в качестве ключей, были изменены и включали неслучайный суффикс, основанный на системном времени. Этот так называемый подход «COMB» (комбинированный временной GUID) сделал UUID нестандартными и значительно увеличил вероятность дублирования, как признал Нильссон, но Нильссон требовал только уникальности внутри приложения. Путем изменения порядка и кодирования UUID версий 1 и 2 так, чтобы метка времени была первой, можно предотвратить потерю производительности при вставке.

Некоторые веб-фреймворки, такие как Laravel , поддерживают UUID «сначала отметка времени», которые можно эффективно хранить в индексированном столбце базы данных. Это создает UUID COMB с использованием формата версии 4, но первые 48 бит составляют метку времени, расположенную, как в UUIDv1. Более конкретные форматы, основанные на идее COMB UUID, включают:

• «ULID», в котором отсутствуют 4 бита, используемые для обозначения версии 4, и по умолчанию используется кодировка base32.
• UUID версий с 6 по 8, официальное предложение трех форматов COMB UUID.

См. также

• Атака на день рождения
• Идентификатор объекта (OID)
• Единый идентификатор ресурса (URI)
• Идентификатор снежинки

Внешние ссылки

• Рекомендация МСЭ-Т X.667 (Свободный доступ)
• ISO/IEC 9834-8:2014 (Платный)
• Техническое примечание TN2166 — Секреты GPT — разработчик Apple
• Документация по UUID — идентификатор Apache Commons
• Ключ CLSID - Microsoft Docs
• Универсальный уникальный идентификатор — Библиотека открытой группы
• Инструмент декодера UUID
• Краткая история UUID
• Понимание того, как генерируются UUID