UUID v4 проти v7: який унікальний ідентифікатор обрати?
UUID - це 128-бітний унікальний ідентифікатор без центральної координації. Версія 4, повністю випадкова, домінує вже роками. Версія 7, новіша (RFC 9562, 2024), включає мітку часу на початку, щоб створювати впорядковані в часі ідентифікатори. Ця різниця, на вигляд незначна, радикально змінює продуктивність у базі даних. Ось що обрати.
Що таке UUID?
UUID (Universally Unique Identifier) - це 128-бітне число, представлене 32 шістнадцятковими символами, згрупованими в п'ять блоків, наприклад 550e8400-e29b-41d4-a716-446655440000. Його призначення: створити унікальний ідентифікатор без звернення до центрального органу, що робить його ідеальним для розподілених систем. Ви можете згенерувати їх нашим генератором UUID.
Існує кілька версій; найрелевантніші сьогодні для ключів записів - це v4 (випадкова) та v7 (впорядкована в часі).
UUID v4 (випадковий)
UUID v4 складається зі 122 випадкових бітів (решта кодує версію та варіант). Імовірність колізії настільки мала, що на практиці незначна. Це версія за замовчуванням у більшості мов і бібліотек.
- Непередбачуваний: ідеальний для токенів чи публічних ідентифікаторів, які не мають бути вгадуваними
- Жодного витоку інформації: не розкриває ні дати, ні порядку створення
- Недолік: повністю невпорядкований, що псує індекси бази даних
UUID v7 (впорядкований у часі)
UUID v7 розміщує мітку часу Unix у мілісекундах на своїх перших 48 бітах, за якими йдуть випадкові біти. Два UUID v7, згенеровані в різні моменти, тому сортуються в порядку їхнього створення, водночас залишаючись унікальними та практично неможливими для вгадування.
- Сортовний: лексикографічний порядок відповідає хронологічному порядку
- Дружній до індексів: вставки відбуваються в кінці індексу, як автоінкремент
- Зворотний бік: він розкриває момент створення, що може бути небажаним для публічного ідентифікатора
Порівняльна таблиця
| Критерій | UUID v4 | UUID v7 |
|---|---|---|
| Склад | 122 випадкові біти | Мітка часу + випадкове |
| Впорядкований у часі | Ні | Так |
| Сортовний | Ні | Так (хронологічно) |
| Продуктивність індексу | Низька (фрагментація) | Висока (послідовні вставки) |
| Непередбачуваність | Повна | Висока, але розкриває момент |
| Витік інформації | Жодного | Дата створення |
| Зрілість / підтримка | Універсальна | Нова (RFC 9562, 2024) |
Вплив на бази даних
Це суть теми. Реляційні бази зберігають свої індекси у B-деревах (B-tree). Вставка випадкових ключів (v4) розкидає записи по всьому індексу, спричиняючи фрагментацію, розщеплення сторінок і менш ефективний кеш. На великих обсягах продуктивність вставки помітно погіршується.
Впорядковані ключі (v7) завжди вставляються в кінець індексу, як автоінкрементований ідентифікатор. Отримуємо швидкі вставки, кращу локальність і компактніший індекс. Це особливо помітно з первинним ключем у InnoDB (MySQL), де первинний ключ визначає фізичний порядок рядків.
Коли обирати одне чи інше
Оберіть UUID v4, коли
- Ідентифікатор публічно відкритий і не має нічого розкривати
- Ви генеруєте токени, посилання для обміну, секрети
- Порядок і дата створення не мають бути вгадуваними
- Ви хочете максимальну сумісність із наявним
Оберіть UUID v7, коли
- UUID слугує первинним ключем у базі даних
- Обсяг вставок високий і продуктивність індексу важлива
- Ви хочете сортувати за порядком створення без окремого стовпця
- Розкриття моменту створення не є проблемою
Рекомендація
Для первинного ключа бази даних віднині надавайте перевагу UUID v7: ви зберігаєте розподілену унікальність UUID, водночас уникаючи штрафу індексу від v4. Залиште UUID v4 для публічних ідентифікаторів, токенів і секретів, де першочергові повна непередбачуваність і відсутність часового витоку.
Усе ж перевірте підтримку v7 у вашій мові та ORM: RFC новий, але впровадження швидко прогресує.
Поширені запитання
Чи UUID v7 менш безпечний за v4?
Він залишається дуже важким для вгадування завдяки своїм випадковим бітам, але розкриває момент створення через свою мітку часу. Для публічного ідентифікатора, де дата не має витекти, чи для секрету надавайте перевагу v4.
Чому UUID v4 уповільнює бази даних?
Тому що його випадкові значення розкидають вставки по всьому індексу B-tree, що фрагментує сторінки та знижує ефективність кешу. Впорядкований v7 вставляє в кінець індексу й уникає цієї проблеми.
Чи можу я мігрувати з v4 на v7?
Так, для нових записів: обидва формати співіснують в одному стовпці UUID. Не потрібно переписувати історію; просто перемкніть генерацію нових ключів на v7.
А що щодо версій v1 та v6?
v1 кодує мітку часу та MAC-адресу, що створює проблеми з конфіденційністю. v6 переупорядковує v1, щоб зробити її сортовною. Для нового проєкту v7 - це впорядкована версія, рекомендована RFC 9562.