Генератор UUID v4

Структура UUID v4: 122 бита случайности в стандартной оболочке

UUID v4 (четвёртая версия универсального уникального идентификатора по стандарту RFC 4122) представляет собой 128-битное значение. Из этих 128 бит ровно 122 бита отведены под чистую случайность. Оставшиеся 6 бит жёстко зафиксированы:

• 4 бита указывают версию (в данном случае версия 4, двоичное значение 0100);
• 2 бита определяют вариант (для RFC 4122 это 10, то есть биты 64–65 равны 10).

Каноническая строковая форма UUID v4 — xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, где:

• x — любой случайный шестнадцатеричный символ (0–9, a–f);
• 4 — фиксированный символ версии;
• y — случайный символ, у которого старшие два бита принудительно установлены в 10 (то есть допустимые значения: 8, 9, a, b).

На странице генератора вы видите именно такое представление: 8‑4‑4‑4‑12 — четыре группы, разделённые дефисами, всего 36 символов (32 шестнадцатеричных цифер и 4 дефиса). Если выключить опцию «Include hyphens», дефисы удаляются, и строка сжимается до 32 символов. Опция «Uppercase» заменяет буквы a–f на A–F, что может требоваться для совместимости с некоторыми старыми системами или человекочитаемости в логах.

Генератор использует 122 случайных бита, а не 128. Это означает, что каждый сгенерированный UUID гарантированно соответствует спецификации версии 4 — ни один бит версии или варианта не может быть случайно изменён. Любой другой инструмент, выдающий «UUID v4» с нарушением этих битов, формально генерирует не UUID v4, а просто случайную 128-битную строку.

Чистая случайность и ничтожная вероятность коллизий

Поскольку каждый UUID v4 содержит 122 случайных бита, пространство возможных значений составляет 2¹²² ≈ 5.3×10³⁶ комбинаций. Для сравнения: это примерно в 10²⁶ раз больше, чем количество песчинок на Земле. Популярная метафора «вы можете генерировать миллиард UUID в секунду на протяжении миллиарда лет, прежде чем получите хотя бы одну коллизию» основана именно на этой энтропии.

Расчёт вероятности коллизии для n случайных UUID подчиняется парадоксу дней рождения. Формула приближения:

p ≈ 1 - e^(-n² / (2 · 2¹²²))

Для n = 10⁹ (миллиард) вероятность коллизии составляет около 10⁻²⁰ — практически ноль. Для n = 10¹² (триллион) вероятность всё ещё менее 10⁻¹⁰. Только при n, превышающем 2⁶¹ (≈ 2.3×10¹⁸), коллизии становятся вероятными. На практике даже крупнейшие распределённые системы (например, базы данных с миллиардами записей) никогда не достигают такого количества одновременно активных ключей.

Именно поэтому UUID v4 — стандартный выбор для распределённых сред, где централизованная координация невозможна: два независимых узла могут генерировать идентификаторы, не обмениваясь информацией, и риск их совпадения ниже, чем риск аппаратного сбоя или ошибки программного обеспечения.

Влияние на индексы баз данных: почему фрагментируются B-деревья

На странице отдельно подчёркнуто: «UUID v4 values sort arbitrarily — they carry no time or ordering information, so using them as a primary key fragments B‑tree indexes». Это критическое предупреждение для архитекторов баз данных.

Большинство СУБД (PostgreSQL, MySQL, SQL Server, Oracle) хранят первичные ключи в кластеризованных индексах на основе B-деревьев. Кластеризованный индекс определяет физический порядок записей на диске. Когда первичный ключ является последовательным (например, автоинкремент BIGSERIAL с шагом +1), новые записи дописываются в конец таблицы, что минимизирует перемещение страниц и перебалансировку дерева.

UUID v4, напротив, распределён случайно по всему пространству значений. Каждая новая вставка с равной вероятностью попадает в любую часть индекса. Это вызывает:

• Фрагментацию страниц — данные разбросаны по диску, производительность последовательного сканирования падает.
• Чрезмерное количество сплитов (split) — B-дерево постоянно делит переполненные страницы, увеличивая объём операций ввода-вывода.
• Кэш-промахи — из-за случайного доступа записи редко находятся рядом в кэше, что замедляет чтение.

Для таблиц с интенсивными вставками и вторичными индексами потеря производительности может достигать 30–50% по сравнению с последовательными ключами. Поэтому многие современные СУБД предлагают альтернативы: uuid_generate_v7 (встроенный в PostgreSQL через модуль pg_uuidv7) или собственные реализации ULID (Universally Unique Lexicographically Sortable Identifier). UUID v7 генерирует идентификаторы, отсортированные по времени, сохраняя случайность в младших битах.

Однако для некластеризованных индексов или таблиц без кластеризованного ключа (heap-организованные) влияние UUID v4 менее значительно. Также в распределённых системах, где центральный счётчик невозможен, фрагментация индекса — приемлемая плата за уникальность без координации.

Настройки формата: когда включать заглавные и убирать дефисы

Генератор предоставляет две переключаемые опции:

• Uppercase (заглавные): переводит шестнадцатеричные символы a–f в A–F. Стандарт RFC 4122 предписывает нижний регистр, но многие системы (например, старые версии Windows Registry, некоторые API Веб-токенов) ожидают заглавные. Смена регистра не влияет на уникальность — abcdef и ABCDEF интерпретируются как одна и та же последовательность битов.

• Include hyphens (дефисы): если отключить, строка превращается в 32 шестнадцатеричных символа без разделителей, например 550e8400e29b41d4a716446655440000. Такой формат удобен в URL (не нужно кодировать дефисы), в именах файлов или при работе со строгими текстовыми протоколами. Однако он теряет человекочитаемость: визуально сложнее выделить группы байт.

Важно: обе опции — чисто представленческие. Базовое 128-битное значение остаётся одним и тем же независимо от выбора. При копировании идентификатора (одиночным кликом или кнопкой «Copy all») в буфер обмена попадает строка в точном соответствии с текущими настройками.

Генерация в браузере: локально, мгновенно, безопасно

Все идентификаторы создаются в вашем браузере с использованием встроенных криптографических функций (Crypto.getRandomValues или crypto.randomUUID). Никакие данные не отправляются на сервер. Это означает:

• Нулевая задержка: изменения любого параметра (формат, количество, регистр, дефисы) вызывают мгновенную регенерацию без перезагрузки страницы.
• Приватность: UUID формируются изоляционно — третьим лицам недоступна ни статистика генерации, ни сами ключи.
• Достоверная случайность: браузерные методы используют системный источник энтропии ОС (например, /dev/urandom на Linux, CryptGenRandom на Windows), что приемлемо для большинства применений, включая токены доступа и идентификаторы сессий. Для криптографически высоконадёжных требований (например, генерация ключей шифрования) следует использовать специализированные библиотеки с дополнительной дистилляцией энтропии, но для API-ключей и идентификаторов UUID этой случайности более чем достаточно.

При изменении счётчика (от 1 до 100) все ранее показанные UUID заменяются новыми. Это исключает возможность случайного дублирования на странице и гарантирует, что каждый сгенерированный набор независим.

Кто использует UUID v4 и зачем

• Разработчики приложений: для идентификаторов объектов в распределённых базах данных (например, MongoDB генерирует ObjectId, похожий на UUID, но часто заменяется на UUID v4 в логике приложения). Удобно, когда каждый микросервис создаёт события или сущности, не полагаясь на общий генератор.
• Архитекторы данных: при проектировании схем с шардированием, где разные узлы независимо генерируют ключи без риска конфликтов. UUID v4 — самый простой способ обеспечить глобальную уникальность без координации.
• Инженеры безопасности: для неотслеживаемых идентификаторов (API-токены, request ID, nonce). В отличие от последовательных ID, UUID v4 не раскрывают количество записей в базе, не позволяют угадать следующий идентификатор и не поддаются временно́й корреляции (если не используется v7).
• Тестировщики и генераторы данных: для заполнения тестовых таблиц реалистичными, уникальными ключами. Инструменты нагрузки (например, pgbench) часто требуют случайные первичные ключи — набор из нескольких тысяч UUID v4 можно получить мгновенно.

Часто задаваемые вопросы

Вопрос: Можно ли использовать UUID v4 в качестве первичного ключа реляционной базы данных?
Ответ: Да, но нужно учитывать фрагментацию кластеризованного индекса из-за случайного порядка вставки. Для таблиц с редкими вставками или с некластеризованными индексами это приемлемо. Если производительность вставок критична, рассмотрите UUID v7 или составной ключ (префикс времени + случайность).

Вопрос: Какова вероятность, что два сгенерированных UUID v4 совпадут?
Ответ: Для 1 триллиона сгенерированных UUID вероятность коллизии ниже 10⁻¹⁰. Практически при любых разумных масштабах коллизии можно игнорировать. Если вы генерируете более 10¹⁸ идентификаторов — риск становится ощутимым, но этот объём вне досягаемости даже крупнейших систем.

Вопрос: Почему в некоторых UUID я вижу символы '4' и '8', '9', 'a', 'b' на фиксированных позициях?
Ответ: Символ '4' стоит на 13-й позиции (в группе после второго дефиса) — это бит версии (0100). Символ '8', '9', 'a' или 'b' стоит на 17-й позиции (первый символ третьей группы) — это биты варианта (10xx). Остальные символы случайны. Это обязательное требование RFC 4122.

Вопрос: Как качество случайности генератора на странице?
Ответ: Используется crypto.randomUUID (где доступен) или Crypto.getRandomValues. Эти методы соответствуют требованиям NIST SP 800-90A для криптографически стойких генераторов псевдослучайных чисел. Для всех распространённых задач (идентификаторы, токены, записи БД) этого достаточно.

Вопрос: Влияет ли выбор регистра на уникальность?
Ответ: Нет. Строка 550e8400-e29b-41d4-a716-446655440000 и 550E8400-E29B-41D4-A716-446655440000 представляют одно и то же 128-битное значение. Регистр — только вопрос совместимости с системами, которые требуют определённого форматирования.

Вопрос: Можно ли генерировать более 100 UUID за раз?
Ответ: Страница ограничивает количество от 1 до 100. Если нужно больше, просто нажмите «Generate» несколько раз — каждый клик создаёт новый независимый набор. Для массовой генерации (миллионы ключей) лучше использовать скрипт на языке программирования с библиотекой, реализующей RFC 4122.