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, генерирани в различни моменти, следователно се сортират в реда на тяхното създаване, оставайки уникални и практически невъзможни за отгатване.

• Сортируем: лексикографският ред съответства на хронологичния ред
• Дружелюбен към индексите: вмъкванията се правят в края на индекса, като автоматично нарастване
• Компромис: разкрива момента на създаване, което може да е нежелателно за публичен идентификатор

Сравнителна таблица

Влияние върху базите данни

Това е същината на въпроса. Релационните бази съхраняват индексите си в B-дървета (B-tree). Вмъкването на случайни ключове (v4) разпръсква записите навсякъде в индекса, причинявайки фрагментация, разцепвания на страници и по-малко ефективен кеш. При големи обеми производителността на вмъкване се влошава осезаемо.

Подредените ключове (v7) се вмъкват винаги в края на индекса, като автоматично нарастващ идентификатор. Връщат се бързи вмъквания, по-добра локалност и по-компактен индекс. Това е особено осезаемо при първичен ключ в InnoDB (MySQL), където първичният ключ определя физическия ред на редовете.

Кога да изберете едното или другото

Изберете UUID v4, когато

• Идентификаторът е изложен публично и не трябва да разкрива нищо
• Генерирате токени, връзки за споделяне, тайни
• Редът и датата на създаване не трябва да са отгатваеми
• Искате максимална съвместимост със съществуващото

Изберете UUID v7, когато

• UUID служи като първичен ключ в база данни
• Обемът на вмъкванията е висок и производителността на индекса има значение
• Искате да сортирате по ред на създаване без специална колона
• Разкриването на момента на създаване не е проблем

Препоръка

За първичен ключ на база данни отсега предпочитайте UUID v7: запазвате разпределената уникалност на UUID, избягвайки наказанието върху индекса на v4. Запазете UUID v4 за публични идентификатори, токени и тайни, където пълната непредвидимост и липсата на времево изтичане са приоритет.

Все пак проверете поддръжката на v7 във вашия език и вашия ORM: RFC е скорошна, но възприемането напредва бързо.

Често задавани въпроси