Генератор UUID

Версии, и какие две из них важны

Их восемь, и для новой работы выбор на деле идёт между двумя. Остальные стоит уметь опознавать, встретив их в старой системе.

Проблема индекса — настоящая причина, по которой появилась v7

Это практический довод, и его стоит понять, а не принять на веру.

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

Вставляйте UUID v4 — и каждая строка ложится в случайное место. Задеваются страницы по всему дереву, каждую надо сначала прочитать, чтобы записать, а заполняясь, страницы расщепляются. На таблице любого размера пропускная способность вставки заметно падает, а индекс фрагментируется; эффект хорошо задокументирован, и именно он создал ключам-UUID их репутацию.

v7 чинит это, ставя метку времени первой. Сгенерируйте выше несколько значений с выбранной v7 и посмотрите на общий префикс: созданные близко по времени идут рядом, поэтому вставки дописываются в конец индекса, как у целого числа, оставаясь при этом глобально уникальными. Вы сохраняете то свойство, ради которого UUID и брали — сгенерировать идентификатор где угодно, без всякой координации, — не расплачиваясь за него на каждой записи.

Строго говоря: порядок гарантирован между миллисекундами, а не внутри одной. Два UUID v7, созданные в одну и ту же миллисекунду, упорядочены своими случайными хвостами, что RFC 9562 разрешает, попутно позволяя реализациям ужесточить это счётчиком. На довод о локальности индекса это никак не влияет: он зависит только от ведущей метки времени.

Цена, остающаяся у обеих версий: 16 байт против 4 или 8, и они тиражируются в каждый индекс, который ссылается на ключ. На большой таблице с несколькими внешними ключами это вполне ощутимые гигабайты.

Что раскрывает v7

Метку времени прочтёт любой, у кого есть идентификатор. Вставьте UUID v7 в инспектор выше, и он назовёт миллисекунду, в которую тот был создан.

Обычно безобидно. Иногда нет: идентификатор v7 в публичном URL выдаёт, когда была создана запись, а этого может хватить, чтобы вывести темпы регистраций, объёмы заказов или то, что документ был датирован задним числом. Если это важно, простое разделение таково: v4 для всего, что видит пользователь, и v7 для внутренних ключей.

Где случайность обязана быть настоящей

Арифметика коллизий, которую все цитируют — 2,7 квинтиллиона до того, как вероятность одной коллизии сравняется с подбрасыванием монеты, — исходит из 122 по-настоящему случайных битов. Это утверждение о формате, а не о вашей реализации.

У UUID, построенного на Math.random(), нет ни той энтропии, ни той непредсказуемости, которые подразумевает это число, и коллизии в реальной жизни по сути всегда были следствием именно этого, а не невезения. Два процесса, запущенные в одну секунду с одинаковым зерном, дают одинаковую последовательность.

Эта страница использует crypto.randomUUID() там, где он есть, и crypto.getRandomValues в остальных случаях. Стоит проверить, чем пользуется ваш собственный код, особенно если UUID подменяют собой токены: предсказуемый идентификатор сброса пароля — это полный захват учётной записи.

Как хранить их экономно

Текстовая форма из 36 символов удобна и расточительна. Альтернативы — все те же 128 бит:

• Родной тип UUID — в Postgres он есть и занимает 16 байт. Пользуйтесь им.
• `BINARY(16)` — эквивалент в MySQL, примерно вдвое компактнее CHAR(36).
• Base64 — 22 символа, когда это обязано быть текстом и длина важна.
• Base32 — 26 символов, без учёта регистра; именно то, что нужно, если когда-нибудь человеку придётся прочитать такое вслух.

Смежное

Для секретов, которые человеку приходится набирать, а не машине хранить, генератор паролей берёт тот же источник случайности. Чтобы прочитать метку времени из UUID v7 в другом формате, дальше подхватит конвертер меток времени.