Каждая современная база данных, распределённая система и API используют уникальные идентификаторы — и в 2026 году стандарт, их регулирующий, фундаментально изменился. UUID (универсальный уникальный идентификатор, Universally Unique Identifier) — это 128-битная метка, способная идентифицировать информацию в компьютерных системах без какой-либо центральной координации. В рамках нового RFC 9562 (заменившего RFC 4122 в мае 2024 года) ландшафт сменился: UUID v4 остаётся стандартом для случайных ID, но UUID v7 теперь рекомендован как первичный ключ баз данных, поскольку его упорядоченная по времени структура предотвращает фрагментацию B-дерева.
Это руководство охватывает картину целиком: как работают UUID, какую версию когда применять и как правильно их реализовать.
Понимание RFC 9562: современный стандарт UUID
UUID — это 128-битное число, уникальность которого практически гарантирована — без какого-либо центрального органа. Согласно Википедии, вероятность коллизии двух UUID настолько близка к нулю, что для реальных приложений считается невозможной. Разные команды могут размечать данные независимо, уверенные, что их ID не столкнутся.
В мае 2024 года IETF опубликовал RFC 9562, выведя из оборота старый RFC 4122. Обновление отвечало запросам современных распределённых систем, которым нужны были ID, одновременно уникальные и сортируемые по времени. Были введены три новые версии: v6, v7 и v8.
Анатомия UUID: версии и варианты
Обычно UUID выглядит как 32 шестнадцатеричных символа, разделённых дефисами на пять групп (8-4-4-4-12):
550e8400-e29b-41d4-a716-446655440000
^
version
Два ключевых поля говорят о том, как был сгенерирован UUID:
| Поле | Расположение | Что сообщает |
|---|---|---|
| Биты версии | Первые 4 бита 7-го байта (первый символ 3-й группы) | Какой алгоритм использован (например, «4» = v4, «7» = v7) |
| Биты варианта | 9-й байт | Вариант UUID — RFC 9562 использует битовый шаблон 10 |
Как поясняет SnapUtils, биты варианта отделяют современные UUID стандарта RFC 9562 от устаревших форматов Apollo или Microsoft.
Почему UUID v7 — новый золотой стандарт для баз данных
Главный недостаток UUID v4 — он полностью случаен. При использовании в качестве первичного ключа в индексе B-дерева базе данных приходится вставлять новые строки в непредсказуемые позиции. По словам CreateUUID, это вызывает «разделение страниц» (page splits) — базе приходится постоянно реорганизовывать данные, освобождая место, что замедляет запись и расходует память впустую.
UUID v7 решает это, помещая 48-битную временную метку Unix Epoch (с точностью до миллисекунды) в начало ID. Это делает ID монотонно возрастающими — новые всегда больше предыдущих. База может просто дописывать их в конец индекса, обеспечивая производительность последовательного целого при глобальной уникальности UUID.
Как UUID v7 балансирует время и энтропию
UUID v7 заполняет оставшиеся 74 бита с помощью CSPRNG (криптостойкого генератора псевдослучайных чисел). Согласно Википедии, чтобы достичь 50%-й вероятности коллизии, нужно генерировать около 1 миллиарда UUID в секунду на протяжении 85 лет. Для любого реального приложения UUID v7 фактически защищён от коллизий.
Лучшие практики хранения: Binary(16) против String(36)
То, как вы храните UUID, не менее важно, чем выбор версии:
| Формат хранения | Место | Производительность индекса | Рекомендация |
|---|---|---|---|
| Binary(16) | 16 байт | Высокая (компактно) | Лучшая практика |
| Нативный тип UUID | 16 байт | Высокая (оптимизировано) | Лучше всего для PostgreSQL |
| Строка (Char 36) | 36–72 байта | Низкая (фрагментация) | Избегать |
SnapUtils рекомендует всегда использовать нативные типы вместо строк. В PostgreSQL нативный тип uuid хранит данные в компактном 16-байтовом бинарном формате, поддерживая при этом стандартные строковые запросы.
UUID против GUID: есть ли разница?
GUID (глобальный уникальный идентификатор, Globally Unique Identifier) — реализация стандарта UUID от Microsoft. Исторически была разница в порядке байтов (endianness) — ранние Microsoft GUID использовали обратный порядок байтов (little-endian) для первых трёх полей, тогда как стандартные UUID — прямой (сетевой порядок байтов) (SnapUtils).
К 2026 году это в основном соглашение об именовании. В рамках RFC 9562 они работают идентично. Guid.NewGuid() в .NET полностью совместим с uuid.uuid4() в Python. «GUID» вы услышите в кругах Windows/Azure, а «UUID» — в сообществах Linux и открытого ПО.
Реализация современных UUID: по языкам
| Язык | UUID v4 | UUID v7 |
|---|---|---|
| Python | Встроенный модуль uuid |
Пакет uuid6 или uuid7 |
| JavaScript | crypto.randomUUID() |
npm-пакет uuid (v10+) |
| PostgreSQL | gen_random_uuid() (PG 13+) |
Нативный uuidv7() (PG 17+) или расширения |
| .NET | Guid.NewGuid() |
Пакеты сообщества |
| Rust | крейт uuid (v1.7+) |
крейт uuid с фичей v7 |
Детерминированные ID: UUID v5
Если вам нужен один и тот же ID каждый раз для заданного ввода (например, URL или имени пользователя), используйте UUID v5. Он хэширует UUID пространства имён и строку имени по алгоритму SHA-1 — идеально для дедупликации, когда нельзя обратиться к центральной базе.
Урок конфиденциальности из UUID v1
UUID v1 использует временную метку и MAC-адрес компьютера. Он практически заброшен, поскольку раскрывает сведения об оборудовании. Известный пример: создатель вируса Melissa был пойман, поскольку UUID в заражённых документах Word содержали его конкретный MAC-адрес.
Продвинутый RFC 9562: v6, v8 и специальные UUID
RFC 9562 добавил специализированные версии под нишевые нужды распределённых систем:
| Версия | Назначение | Когда применять |
|---|---|---|
| v6 | Переупорядоченная временная метка v1 — сортируемая с сохранением точности v1 | Миграция унаследованных систем v1 |
| v8 | Пользовательская — 122 бита для данных, определяемых разработчиком | Экспериментальные или специфичные для вендора схемы |
| Nil UUID | 00000000-0000-0000-0000-000000000000 |
Пустой заполнитель |
| Max UUID | FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF |
Маркер конца диапазона |
Заключение
RFC 9562 обновил уникальные идентификаторы для современной облачной эры. Практические ориентиры:
- Первичные ключи БД → используйте UUID v7 для упорядоченных по времени вставок без фрагментации
- Общая случайность → UUID v4 по-прежнему вполне подходит
- Дедупликация → UUID v5 даёт детерминированные ID
- Хранение → всегда Binary(16) или нативные типы UUID, никогда строки
Шаг к действию: Проверьте схемы своей базы данных. Если вы используете UUID v4 как первичный ключ в таблицах с миллионами строк, переход на UUID v7 — несложное изменение, способное заметно снизить фрагментацию индекса и ускорить запросы.
Часто задаваемые вопросы
UUID — это то же самое, что GUID?
Функционально да. GUID — реализация стандарта UUID от Microsoft. В рамках RFC 9562 их поведение идентично — их можно взаимозаменяемо использовать в приложениях .NET, Java и Python.
Могут ли два UUID когда-либо столкнуться в реальном сценарии?
Математически возможно, практически невозможно. Для UUID v4 нужно сгенерировать примерно 2,71 квинтиллиона ID, чтобы достичь 50%-й вероятности коллизии. Согласно Generate-Random.org, генерация 1 миллиарда UUID в секунду на протяжении 85 лет даёт лишь 50% шанс одной коллизии.
Хранить UUID в базе как строки или как бинарные данные?
Всегда отдавайте предпочтение Binary(16) или нативному типу UUID (доступен в PostgreSQL). 36-символьная строка расходует более чем в два раза больше места и значительно замедляет поиск по индексу и соединения.SnapUtils отмечает, что преимущества RFC 9562 по производительности максимизируются, когда хранение остаётся компактным.
Когда стоит использовать UUID v5 вместо UUID v4?
Используйте v5, когда нужны детерминированные ID — одинаковый ввод всегда даёт один и тот же UUID без обращения к базе. Используйте v4, когда нужна полная случайность и вы хотите, чтобы идентификатор нельзя было реверс-инжинирить к его источнику.
Добавить комментарий