PostgreSQL 18 представляет поддержку UUIDv7, нового типа универсально уникальных идентификаторов, решающего проблемы производительности традиционных UUIDv4. В отличие от полностью случайного UUIDv4, UUIDv7 включает временную метку как наиболее значимую часть своей 128-битной структуры, обеспечивая естественную сортировку по времени создания. Это открывает возможности для более эффективного использования UUID в качестве первичных ключей в базах данных.

В статье демонстрируется сравнительный анализ производительности между UUIDv4 и UUIDv7 через создание двух таблиц для "магазина крабов" с использованием Aiven for PostgreSQL. Авторы предоставляют практические примеры кода для создания сервиса и таблиц, а также функцию для вставки случайных данных. Тесты показывают, что UUIDv7 может значительно улучшить производительность операций вставки по сравнению с UUIDv4, особенно при работе с большими объемами данных.

• UUIDv7 раскрывает время создания записи, что может быть критично для приватности и безопасности, особенно если первичный ключ публично доступен.
• Эксперты рекомендуют использовать UUIDv7 только для внутренних ключей и выставлять отдельный UUIDv4 как публичный идентификатор.
• Но в большинстве случаев, когда выбор между UUIDv7 и v4, важно учитывать, что v7 предоставляет лучшую производительность при вставке и сортировке, но требует дополнительных усилий для защиты приватности.

UUIDv7, новая версия универсального уникального идентификатора на основе временных меток, появится в PostgreSQL 18. Она решает ключевые проблемы традиционных UUID: отсутствие сортируемости и низкую локальность индексов. В отличие от UUIDv4 со случайной структурой, UUIDv7 содержит временной компонент, что обеспечивает последовательную вставку в B-деревья и снижает фрагментацию. Это особенно полезно для распределенных систем, где клиенты генерируют ID без координации с сервером.

Хотя размер UUID остаётся 128-битным (больше, чем INT или BIGINT), современные CPU эффективно обрабатывают такие значения через SIMD-инструкции. Важно использовать бинарное представление UUID, а не строковое, для оптимизации производительности. UUIDv7 также подходит для публичных идентификаторов, так как их сложно угадать, в отличие от автоинкрементных чисел. Это делает его идеальным выбором для шардированных баз данных и сред с минимальной серверной координацией.

• Обсуждаются проблемы безопасности UUIDv7 из-за экспозиции времени создания в публичных идентификаторах, что может упростить угадывание соседних записей.
• Предлагаются решения для сокрытия времени создания на границе API, например, преобразование UUIDv7 в UUIDv4 или шифрование временной метки.
• Отмечается, что 62 бита случайности в UUIDv7 при наличии лимита запросов обеспечивают достаточную безопасность для большинства веб-приложений.
• Поднимается вопрос о негативном влиянии UUID (по сравнению с последовательными целыми числами) на производительность БД из-за отсутствия оптимизаций для последовательных ключей.
• Утверждается, что безопасность не должна зависеть от формата первичного ключа, а проблемы угадывания ID указывают на ошибки в проектировании системы.

UUIDv47: приватность v4 + производительность v7

Навигационное меню

Платформа:

• GitHub Copilot
• GitHub Spark
• GitHub Models
• GitHub Advanced Security
• Actions
• Codespaces
• Issues
• Code Review
• Discussions
• Code Search

Ресурсы:

• AI
• DevOps
• Security
• Software Development

Open Source:

• GitHub Sponsors
• The ReadME Project
• Topics
• Trending
• Collections

Enterprise:

• Enterprise platform
• GitHub Advanced Security
• Copilot for business
• Premium Support

Поиск кода, репозиториев, пользователей, проблем, pull requests...

Включите мой email для связи

Отмена Отправить отзыв

Сохраненные поиски для быстрой фильтрации результатов

Имя Запрос

Отмена Создать сохраненный поиск

Войти Зарегистрироваться

• Предложены методы маскирования UUIDv7 для скрытия временных меток при внешнем использовании, сохраняя их внутренние преимущества (сортировка, индексация).
• Обсуждается использование шифрования (Speck, AES) или хеширования (SipHash) для обратимой конвертации между внутренним UUIDv7 и внешним UUIDv4-видным идентификатором.
• Рассмотрены альтернативные подходы: разделение на внутренний и внешний ключ, использование ULID, Sqids (ранее Hashids) или кастомного кодирования.
• Подняты вопросы о практической необходимости скрытия временных меток и рисках (безопасность, корреляция данных для деанонимизации).
• Отмечены проблемы совместимости, сложности реализации и потери некоторых преимуществ UUIDv7 для потребителей API.
• Затронуты технические аспекты: генерация на клиенте, визуальное сравнение UUID, необходимость отдельного поля с временем для клиента.
• Упомянуты связанные проекты и алгоритмы: uuidv47, ULID, Speck, метод из blog.notdot.net.

Вероятность совпадения двух GUID — 1 к 2¹²², то есть примерно 1 к 5×10³⁶.
Guid Smash показывает, насколько близко каждый новый GUID подходит к целевому.

• Целевой GUID: 6e197264-d14b-44df-af98-39aac5681791
• Старт: 20 июля 2025
• Проверено: 1,14 трлн GUID
• Скорость: ~468 тыс./с
• Ожидаемое совпадение: через 4,21×10²³ лет при 400 тыс./с

Префикс	Совпадений
6	66,7 млрд
6e	4,17 млрд
6e1	261 млн
6e19	16,3 млн
6e197	1,02 млн
6e1972	63,7 тыс
6e19726	4,0 тыс
6e197264	244
6e197264d	11
6e197264d1…1791	0

Ошибка. Перезагрузить

• Вероятность совпадения двух случайных UUIDv4 действительно 1 : 2¹²², но из-за парадокса дней рождения при генерации ≈ 2⁶¹ идентификаторов шанс хотя бы одного дубля возрастает до ~50 %.
• Эксперимент лучше вести не «в лоб» (ищем конкретный UUID), а проверяя все уже сгенерированные значения на дубликаты.
• UUIDv7 снабжены 48-битным префиксом времени: при генерации миллионов ID в одну миллисекунду коллизии становятся реальнее.
• На практике коллизии встречаются: участники сообщили два случая — один из-за одинакового «магического» GUID, другой при слиянии данных разных систем.
• Для коротких уникальных кодов подстрока UUID не подходит; нужно учитывать «день рождения» и выбирать диапазон квадратично больше требуемого количества.