ИНСТР-UUID-V47RFC 9562v7 для БД · v4 для public APIревизия 2026-05-07

UUID v4 vs v7

UUID v4 (random) vs v7 (timestamp + random). Зачем нужен v7 для БД, почему он быстрее. RFC 9562, 2024.

⏱ работает в браузере · без регистрации
Инструмент · ИНСТР-UUID-V47|real-time
calcal.ru / uuid-v4-vs-v7-otlichie
Загрузка инструмента…
128бит
Длина UUID
+50%
Скорость v7 vs v4
2024
RFC 9562
0
Запросов к серверу

Что такое UUID

UUID (Universally Unique Identifier) — 128-битный идентификатор, гарантированно уникальный без центральной координации. Записывается как 32 hex-символа с 4 дефисами: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. Где M — это цифра версии (1, 4, 7), N — вариант (обычно 8 или 9).

Главная польза UUID: распределённая генерация. В микросервисах каждый сервис может создавать свои ID без обращения к центральному генератору. Для 100 миллионов сгенерированных UUID v4 вероятность коллизии — 2.7×10⁻¹⁹ (близко к попаданию метеорита).

v4 vs v7 детально

UUID v4 — полностью случайный

Структура UUID v4:
xxxxxxxx-xxxx-4xxx-Yxxx-xxxxxxxxxxxx
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                     |
                     6 бит зарезервированы под версию (4) и вариант (Y=8/9/A/B)
                     122 бита случайные

Пример:
f47ac10b-58cc-4372-a567-0e02b2c3d479

Особенности:
✅ Простой алгоритм: crypto.randomBytes(16) с заменой нескольких бит
✅ Безопасный: невозможно угадать
❌ Не сортируется: записи в БД попадают в случайные страницы B-tree
❌ Раскрывает только версию (4)

UUID v7 — timestamp + random

Структура UUID v7:
xxxxxxxx-xxxx-7xxx-Yxxx-xxxxxxxxxxxx
^^^^^^^^^^^^^      ^^^^^^^^^^^^^^^^^
       |                  |
       48 бит = Unix timestamp (мс)
       12 бит подверсии
       62 бита случайные

Пример:
018f7a8c-5d4e-7c2a-9f1b-3a5c7e9d2b4f
^^^^^^^^^^^^^
   |
   = 2024-05-15 14:23:11.234 UTC (ms)

Особенности:
✅ Сортируется по времени: ORDER BY id ≈ ORDER BY created_at
✅ Оптимизирован для B-tree: новые записи в одну страницу
✅ Совместим с UUID v4 (тот же формат хранения)
✅ ~62 бита энтропии — достаточно для уникальности
⚠️ Раскрывает время создания (приватность)
UUID Version 7 features a time-ordered value field derived from the widely implemented and well-known Unix Epoch timestamp source. The UUIDv7 layout is intended for cases where it is desirable for UUIDs to be ordered and the order to relate to time of creation.RFC 9562 — Universally Unique IDentifiers (UUIDs), May 2024

Производительность в БД

Замеры (PostgreSQL 16, миллион INSERT в таблицу с UUID primary key):

Тип IDInsert (1M)Размер индекса
BIGINT (sequence)12 сек43 MB
UUID v714 сек52 MB
UUID v422 сек71 MB

UUID v7 на 35% быстрее v4. Размер индекса на 25% меньше. Для большой таблицы (миллиарды записей) разница огромная: v7 даёт скорость близкую к bigint при сохранении всех преимуществ UUID (распределённая генерация, отсутствие коллизий).

Когда что использовать

UUID v7 — для:

  • Primary key в БД. Лучшая производительность, особенно для часто-вставляемых таблиц.
  • Event sourcing. События естественно упорядочены по времени.
  • Логи и события мониторинга. Легко сортировать и querying по времени.
  • Internal IDs между микросервисами. Если время создания не secret.
  • Очереди сообщений. FIFO порядок без дополнительного timestamp.

UUID v4 — для:

  • Public-facing IDs. URLs (/orders/uuid), API responses. Не раскрывает время.
  • Session tokens. Невозможность угадать критична.
  • API keys. 122 бита энтропии vs 62 у v7 — значительная разница для бруте.
  • Криптографические nonces. Случайность приоритетнее сортируемости.
  • Любые случаи где время создания — секрет. Бизнес-метрики, конкурентные данные.

Гибридный подход (рекомендуемый)

-- В БД храним два ID:
CREATE TABLE orders (
  id          UUID PRIMARY KEY DEFAULT uuidv7(),  -- v7 для performance
  public_id   UUID NOT NULL UNIQUE DEFAULT uuid_v4(), -- v4 для API
  created_at  TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  -- ... остальные поля
);

-- Индекс на public_id для API endpoints
CREATE UNIQUE INDEX ON orders (public_id);

-- Внутренние сервисы используют id (v7)
-- Frontend / API получает только public_id (v4)

Генерация в коде

Node.js

// uuid 10.0+ (с 2024)
import { v4 as uuidv4, v7 as uuidv7 } from 'uuid';

const v4Id = uuidv4();
// 'f47ac10b-58cc-4372-a567-0e02b2c3d479'

const v7Id = uuidv7();
// '018f7a8c-5d4e-7c2a-9f1b-3a5c7e9d2b4f'

// Извлечь timestamp из v7
const timestamp = parseInt(v7Id.replace(/-/g, '').slice(0, 12), 16);
const date = new Date(timestamp);

Python

# pip install uuid7
import uuid
from uuid7 import uuid7

v4 = uuid.uuid4()
# UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479')

v7 = uuid7()
# UUID('018f7a8c-5d4e-7c2a-9f1b-3a5c7e9d2b4f')

PostgreSQL 17+

-- В PostgreSQL 17 (2024) добавлены нативные функции
SELECT uuidv7();
-- 018f7a8c-5d4e-7c2a-9f1b-3a5c7e9d2b4f

SELECT gen_random_uuid(); -- v4 (доступен с PostgreSQL 13)
-- f47ac10b-58cc-4372-a567-0e02b2c3d479

-- Использование как DEFAULT
CREATE TABLE orders (
  id UUID PRIMARY KEY DEFAULT uuidv7()
);

Альтернативы UUID

  • nanoid. 21 символ, 126 бит. Короче UUID. Без timestamp. URL-safe.
  • ksuid (Stripe). 27 символов, sorted by time, без дефисов. Близок к v7.
  • cuid2. Современная альтернатива nanoid с лучшими свойствами.
  • ULID. Похож на v7, тоже timestamp + random. 26 символов в Crockford base32.
  • Snowflake (Twitter). 64-битный sequential ID + machine ID + sequence. Требует координации между генераторами.
ИСТОЧНИКИ
  1. RFC 9562 — Universally Unique IDentifiers (UUIDs). IETF. datatracker.ietf.org/doc/html/rfc9562. 2024.
  2. PostgreSQL 17 — UUID v7 support. PostgreSQL Global Development Group. postgresql.org/docs/17/functions-uuid.html. 2024.
  3. uuid npm — modern UUID library. uuidjs. github.com/uuidjs/uuid. 2024.
ЧАСТЫЕ ВОПРОСЫ

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

UUID (Universally Unique Identifier) — 128-битный идентификатор, гарантированно уникальный без координации между генераторами. Записывается как 32 hex-символа с дефисами: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. Где M — версия (1, 4, 7), N — вариант. UUID решает проблему распределённых ID: вместо центрального сервера, каждый узел генерирует свои ID без коллизий.
v1 (1980-е) — timestamp + MAC-адрес. Утечка приватности (MAC), коллизии при множестве генераторов на одной машине. Используется редко. v4 — полностью случайный (122 бит энтропии). Самый популярный, безопасный, но не сортируется. v7 (2024, RFC 9562) — Unix timestamp ms + random. Сортируется по времени создания, оптимизирован для БД. Постепенно заменяет v4.
Случайные UUID создают проблему производительности при INSERT. B-tree индексы (стандарт в PostgreSQL, MySQL InnoDB) оптимизированы для последовательной записи. Случайные значения попадают в разные страницы — page splits, фрагментация, кэш-промахи. Тестирование: 1 миллион INSERT с UUID v4 — на 30-50% медленнее sequential bigint. UUID v7 решает: timestamp в начале → новые записи в одну страницу → быстрая запись.
Нативно: PostgreSQL 17+ (uuidv7() функция). MySQL/MariaDB — нет нативной функции, генерируйте на стороне приложения. Любая БД — можно генерировать UUID v7 в коде (Node.js, Python, Go) и вставлять как обычный UUID. Хранится в том же формате что v4 — 16 байт. Для существующих таблиц с UUID v4 — миграция не нужна, но новые записи можно генерировать как v7.
Иногда да. Из v7 можно извлечь время создания записи с миллисекундной точностью. Это полезно для отладки, но небезопасно для публичных API: атакующий может узнать когда зарегистрировался пользователь, в каком порядке создавались заказы. Решение: используйте v7 для INTERNAL ID (БД), а наружу выдавайте v4 (random) или короткий обфусцированный ID. Многие системы хранят оба: id_internal (v7) + id_public (v4 или nanoid).
v4: API endpoints, public-facing IDs (заказы, пользователи в URL), session tokens, любые случаи где приватность времени важна. v7: primary keys в БД, внутренние ID между сервисами, логи и события (легко сортировать), очереди сообщений (FIFO), event sourcing. Главное: v7 — для performance и сортировки, v4 — для приватности.
Node.js: <code>npm install uuid</code> → <code>import { v7 as uuidv7 } from "uuid"; uuidv7()</code> (с версии 10.0 в 2024). Python: <code>pip install uuid7</code>. Go: github.com/google/uuid v1.6+ (NewV7). Java: Jackson + uuidv7 библиотека. PostgreSQL 17+: SELECT uuidv7();. Старые системы — генерируйте через timestamp + random вручную (~10 строк кода).
UUID v7 — стандарт RFC, 128 бит, 36 символов с дефисами. nanoid — короче (21 символ, base64-like), 126 бит, без сортировки. ksuid (Stripe) — 27 символов, sorted by time, без дефисов. cuid2 — современный, sortable, 24 символа. Для БД — UUID v7 (стандарт, простой). Для URL — nanoid или короткий хеш. Не путайте: UUID — стандарт, остальные — альтернативы.
Лиана Арифметова
АВТОРverifiedред. calcal.ru

Лиана Арифметова

Создатель и главный редактор

Миссия: демократизировать сложные расчёты. Превратить страх перед числами в ясность и контроль. Девиз: «Любая повторяющаяся задача заслуживает своего калькулятора».

Mathematical Engineering · МФТИ · редактирует каталог с 2012 года

Был ли этот калькулятор полезен?

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ

Инструмент справочный — не заменяет эксперта

Только для информационных целей. Все расчёты, результаты и данные, предоставляемые инструментом, носят исключительно ознакомительный и справочный характер. Они не являются профессиональной консультацией — медицинской, юридической, финансовой, инженерной или иной.

Точность результатов. Калькулятор основан на общепринятых формулах и методиках, однако фактические результаты могут отличаться в зависимости от индивидуальных условий, исходных данных и применяемых стандартов. Мы не гарантируем полноту, точность или актуальность приведённых расчётов.

Профессиональные решения — медицинские, финансовые, инженерные — должны приниматься только после консультации с квалифицированным специалистом. Не используйте автоматический расчёт как единственное основание для важных решений.

Ограничение ответственности. Авторы и разработчики сервиса не несут ответственности за прямой или косвенный ущерб, возникший из-за использования данных расчётов. Пользователь принимает на себя всю ответственность за интерпретацию результатов.