PostgreSQL 18 добавляет нативную поддержку UUID v7 через функцию uuidv7(), что позволяет использовать UUID в качестве первичных ключей без потери производительности благодаря их последовательной природе. Это устраняет необходимость в сторонних расширениях или реализации генерации на уровне приложения.

Также введены VIRTUAL generated columns — теперь вычисляемые столбцы по умолчанию генерируются при чтении, а не записи, что экономит место на диске и избегает перезаписи таблиц при их добавлении. Эти изменения упрощают разработку, делая работу с базой данных более гибкой и эффективной.

• Участники обсуждают преимущества вычисляемых столбцов в базах данных, отмечая их полезность для миграций схем и единообразия логики между разными клиентами.
• Поднимается вопрос о производительности: выполнение вычислений на стороне БД может быть эффективнее, чем в клиентских приложениях, особенно при использовании индексов.
• Высказываются опасения о возможном злоупотреблении этой функцией и усложнении схемы, но признаётся, что иногда это единственное решение.
• Упоминается конкретный пример использования для преобразования временных зон, чтобы упростить запросы.
• Обсуждение начинается с упоминания функции pg_get_acl() и сложности составления запросов для проверки привилегий.

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 не подходит; нужно учитывать «день рождения» и выбирать диапазон квадратично больше требуемого количества.