ULID 👍 тот самый формат идентификатора который Вам необходим

В прошлой статье я описал атрибуты хорошего идентификатора, как он выглядит и написал реализацию на PHP. И вроде бы информации достаточно, да и код есть, так в чем проблема?! Не беспокойтесь, проблемы НЕТ! Код из прошлой статьи вполне безопасно использовать на боевом сервере. В этой статье я хочу продемонстрировать другой формат идентификатора и возможно он придется Вам по вкусу.

Представляю Вашему вниманию ULID 🎉

ULID — это аббревиатура и расшифровывается как Universally Unique Lexicographically Sortable Identifier(Универсальный уникальный лексикографически сортируемый идентификатор). Давайте посмотрим его отличия и чем ULID лучше UUID, спецификация это описывает:

• UUID не самый эффективный способ кодирования 128 бит случайных данных.
• UUID v1/v2 непрактичен во многих средах, так как требует доступа к уникальному, стабильному MAC-адресу.
• UUID v3/v5 требует уникального исходного значения и создает случайно распределенные идентификаторы, что может приводить к фрагментации во многих структурах данных.
• UUID v4 не предоставляет никакой другой информации, кроме случайных данных, что также может вызывать фрагментацию во многих структурах данных.

А что предлагает ULID, так же из спецификации

• Совместимость с 128-битными UUID.
• 1,21e+24 уникальных ULID в миллисекунду.
• Лексикографически сортируемый!
• Каноническое представление в виде строки из 26 символов, в отличие от 36 символов в UUID.
• Использует Base32 Douglas Crockford для лучшей эффективности и читаемости (5 битов на символ).
• Нечувствительный к регистру.
• Отсутствие специальных символов (безопасность URL).
• Монотонный порядок сортировки (правильно определяет и обрабатывает одну и ту же миллисекунду).

Спецификация 🎓

Возьмём к примеру данную строку 01HBNDH8EZNE6Y66H3XHZBBEH9, сгенерированную для временной метки 1696157180383. Первые десять символов это число временной метки закодированное Base32

01HBNDH8EZ
48bits

Остальные символы это случайный набор битов так же закодированное Base32

NE6Y66H3XHZBBEH9
80bits

Компоненты

Строка состоит из двух компонентов

Timestamp

• 48-битное целое число
• UNIX-время в миллисекундах
• Место не закончится до 10889 года нашей эры

Randomness

• 80 бит
• Криптографически защищенный источник случайности, если это возможно

Сортировка

Самый левый символ должен быть отсортирован первым, а самый правый символ — последним (в лексикографическом порядке). Должен использоваться стандартный набор символов ASCII. Порядок сортировки в пределах одной миллисекунды не гарантируется.

Кодирование

Base32 Douglas Crockford используется, как показано. В этом алфавите отсутствуют буквы I, L, O и U, чтобы избежать путаницы и злоупотребления.

Монотонность

При генерации ULID в пределах одной и той же миллисекунды, мы можем предоставить некоторые гарантии относительно порядка сортировки. А именно, если обнаруживается одна и та же миллисекунда, случайный компонент увеличивается на 1 бит в позиции наименьшего значащего разряда (с переносом).

Если, в крайне маловероятном случае, у вас удастся сгенерировать более 280 ULID в пределах одной и той же миллисекунды или вызвать переполнение случайного компонента с меньшим числом операций, то генерация завершится неудачей.

Ошибки переполнения при разборе строк Base32

Технически, строка, закодированная в формате Base32 с использованием 26 символов, может содержать 130 битов информации, в то время как ULID должен содержать всего лишь 128 битов. Поэтому самый большой допустимый ULID, закодированный в формате Base32, составляет 7ZZZZZZZZZZZZZZZZZZZZZZZZZ, что соответствует эпохе времени 281474976710655 или 2 ^ 48 — 1.

Любая попытка декодировать или закодировать ULID, превышающий этот размер, должна быть отклонена всеми реализациями, чтобы предотвратить ошибки переполнения.