Инструменты разработчика · Генератор UUID
UUID Версии от 1 до 8. Объяснение: какую из них следует создать?
· Фон
uuid криптография API-интерфейс браузера
Восемь версий имеют один формат, но решают разные проблемы: упорядочение по времени, воспроизводимость, случайность или пользовательские макеты. В этом посте объясняется каждый из них и дается путь решения.
Один формат, восемь рецептов — почему размер версии имеет значение при выборе библиотечной функции
Стандарт UUID определяет 128-битный формат как тридцать шесть шестнадцатеричных символов с дефисами. RFC 9562 определяет восемь различных рецептов (версии с первой по восьмую) для заполнения этих битов различными шаблонами и значениями. Полубайт версии (первый символ третьей группы) определяет, какой метод создал значение, и служит меткой. Выбор неправильной версии означает сохранение ненужной временной информации, отсутствие гарантий порядка производительности базы данных или неправильное понимание ролей безопасности идентификаторов. В этом посте рассматривается каждая версия, какие конкретные проблемы она решает, когда разработчики сталкиваются с ней на практике, а также представлена структура принятия решений для выбора правильной версии для ваших конкретных системных требований.
v1 и v6: время плюс узел — исходный макет, основанный на времени, и переупорядоченная версия, которая сортируется правильно.
Версия 1 сочетает в себе 60-битную метку времени с идентификатором узла (первоначально это был адрес MAC, хотя современные реализации используют случайные значения, чтобы избежать утечки информации об оборудовании). Временная метка записывает интервалы 100 наносекунд с октября 15, 1582. Поле узла может показать, когда идентификатор был сгенерирован и откуда он произошел географически, поэтому современные реализации избегают адресов MAC. Версия 6 переупорядочивает одну и ту же временную метку и информацию об узле для улучшения сортировки путем перемещения старших битов времени вперед, благодаря чему UUID версии 6 правильно сортируются в лексикографическом порядке. Если вашему приложению нужны UUID, которые естественным образом сортируются по времени создания с превосходной локальностью индекса, v6 — современный выбор.
v2: DCE Security — редко используемый вариант, включающий идентификаторы POSIX.
Версия 2 редко используется в новых системах. Он встраивает идентификаторы пользователей или групп POSIX в макет UUID, что делает его полезным только в устаревших средах, где эти идентификаторы имеют организационное значение. Конструкция версии 2 предполагает конкретную вычислительную модель (DCE Security), которая редко встречается в современных распределенных системах. Большинство организаций связывают UUID с пользователями или группами на уровне приложений посредством объединений баз данных или таблиц поиска, а не путем кодирования идентификатора пользователя в сам идентификатор. Такое разделение задач упрощает изменение моделей авторизации, перенос пользовательских данных и ведение журналов аудита. Кодирование учетных данных непосредственно в UUID создает тесную связь и затрудняет развитие систем.
v3 и v5: на основе имени — детерминированные идентификаторы, хешированные из пространства имен и имени с помощью MD5 или SHA-1.
UUID версий 3 и 5 являются детерминированными: одно и то же пространство имен и имя всегда создают один и тот же идентификатор, что идеально подходит для представления стабильных сопоставлений внешних данных. Версия 3 использует MD5, а версия 5 использует SHA-1 в качестве алгоритмов хеширования, что отражает их возраст и распространение. Когда запись о клиенте поступает на импорт, запись UUID версии 5, полученная из фиксированного пространства имен, будет идентична при нескольких запусках импорта, что предотвращает дублирование записей. Этот детерминизм означает, что UUID воспроизводим и предсказуем для любого, кто знает пространство имен и входные данные. Практическая ценность проявляется в сценариях интеграции данных: согласование записей о клиентах из нескольких систем, предотвращение дублирования при повторяющемся импорте и присвоение стабильных идентификаторов товарам.
v4: случайный — 122 bits из CSPRNG и выбор по умолчанию при заказе не имеет значения
Версия 4 является выбором по умолчанию, когда заказ не требуется и вы хотите независимое создание без централизованной координации. UUID версии 4 состоит из 122 bits из криптографически безопасного случайного источника с шестью битами, установленными в фиксированные значения (полубайт версии 4 и RFC 9562 вариантные биты 10). Вся суть в случайности: каждый вызов дает разное значение, коллизии остаются маловероятными, и не требуется никакого внешнего состояния или координации. Это версия, которую ToolAcre генерирует с помощью crypto.randomUUID() или crypto.getRandomValues(). Эта версия подходит для ссылок на объекты, неструктурированных данных и большинства ролей за пределами первичных ключей или контекстов сортировки.
v7 и v8: время Unix и пользовательские — современная упорядоченная по времени версия для ключей базы данных и аварийный люк для индивидуальных макетов.
Версия 7, стандартизированная в RFC 9562, переносит современные упорядоченные по времени свойства в формат UUID. Он использует 48-битную миллисекундную метку времени Unix, 12 bits с точностью до миллисекунды и 62 случайные биты вместе взятые. Миллисекундная временная метка Unix действительна до года 10889, что делает ее подходящей для систем. Результат правильно сортируется в лексикографическом порядке и помещается в стандартный 128-битный столбец UUID без специальной обработки или преобразования кодировки. Если вашему приложению нужны идентификаторы, которые сортируются по времени создания в стандартном формате UUID, лучшим вариантом на данный момент является версия 7. Версия 8 — это стандартизированный универсальный набор для форматов, определяемых реализацией, полезный только в том случае, если вам нужны определенные раскладки битов, не предусмотренные версиями v1–v7.
Рабочий пример — путь принятия решения, примененный к трем сценариям: общедоступная ссылка API, первичный ключ и стабильный идентификатор для импортированных записей.
Три реальных сценария иллюстрируют выбор версии: во-первых, общедоступная ссылка API должна быть стабильной во всех экземплярах API, не должна терять время создания и должна быть одинаковой при перезапуске сервера, чтобы разные экземпляры генерировали одну и ту же ссылку для одного и того же документа. Используйте версию 5 со стабильным пространством имен и именем документа. Во-вторых, первичный ключ для постоянно растущей таблицы должен быть уникальным, не вызывать фрагментации индекса и должен создаваться любым экземпляром приложения без центральной координации. Используйте версию 7 для сортируемых идентификаторов со стандартной поддержкой экосистемы UUID. В-третьих, архивным записям, требующим стабильного поиска, нужны неизменяемые идентификаторы.
Вывод: выбирайте по свойству, а не по привычке — генератор ToolAcre создает случайные UUID из CSPRNG браузера для случаев, требующих версии 4.
Выбор версии следует из конструкции вашей схемы и системных требований, а не из соглашений или привычек. Случайные UUID (v4) используются по умолчанию, поскольку они не требуют состояния или координации и создают независимые идентификаторы, подходящие для большинства ролей. Версии с упорядочением по времени (v6, v7) решают проблемы локальности индекса за счет утечки временной информации или требований синхронизации часов. Детерминированные версии (v3, v5) предотвращают дублирование импорта и обеспечивают стабильные внешние сопоставления за счет предсказуемости — любой, кто знает ваше пространство имен, может пересчитать их. ToolAcre генерирует случайные UUID версии 4 из криптографически безопасного генератора браузера. Если вам нужна другая версия, правильно сформированная проверка подтверждает правильность анализа идентификаторов.