Встречайте UUID нового поколения для ключей высоконагруженных систем

31 марта 2022 года на сайте IETF ^[1] был официально размещен текст рабочего документа ^[2] (копия 1 ^[3], копия 2 ^[4]) New UUID Formats (далее – стандарт), который должен формально обновить, а фактически заменить давно устаревший и изначально ущербный RFC 4122 ^[5].

В стандарте представлены новые форматы универсальных уникальных идентификаторов (UUID ^[6]), имеющих следующие свойства:

• для использования в высоконагруженных приложениях и базах данных – как монолитных, так и распределенных,

• возрастающие по времени генерации (без дополнительных секунд ^[7]),

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

• объединенные с метаданными.

Стандарт рекомендует поставщикам СУБД обеспечить создание и хранение UUID новых форматов для использования в качестве идентификаторов или левых частей идентификаторов, таких как, помимо прочего:

• первичные ключи,

• суррогатные ключи для хронологических баз данных ^[8],

• внешние ключи, включая используемые в полиморфных отношениях ^[9],

• ключи для пар ключ-значение в столбцах JSON и базах данных типа «ключ-значение».

В долгих и жарких спорах ^[10] удалось выработать стандарт по существу безупречного качества. Хотя некоторые туманные формулировки и прежние неудачные варианты технических решений сохранились в тексте, однако найдены оригинальные и красивые решения всех проблем. Стоит особенно отметить творческий вклад жителя Японии с псевдонимом LiosK ^[11] и разумные решения инициаторов стандарта Brad Peabody ^[12] и Kyzer Davis ^[13] из США. Стандартом обеспечена максимально возможная скорость поиска записей по содержащемуся в них значению UUID. Стандарт содержит множество правильных рекомендаций с обоснованием. Единственный существенный изъян стандарта – это расточительное использование 6 из 128 битов UUID (сегменты ver и var) лишь для совместимости с отжившим RFC 4122. Стандарт превосходит ULID ^[14], KSUID ^[15], CUID ^[16] и остальные аналоги. Все они были исследованы ^[17] и указаны в стандарте.

Стандарт еще не утвержден, но поставщики СУБД уже могут начинать его реализовывать. Невозможно представить, что появится другой – более качественный и существенно отличающийся вариант стандарта. Приложенные к стандарту прототипы на языке C сильно упрощенные, и поэтому они не могут быть хорошей основой для разработки. Из трех предложенных форматов наибольшую практическую ценность представляет версия UUIDv7.

В текущую версию стандарта из-за нехватки времени не вошли альтернативные текстовые кодировки UUID. Инициаторы стандарта хотят включить их в следующую версию стандарта, причем кодировка Crockford’s Base32 ^[18] уже ими одобрена.

Хотя стандарт предоставляет разработчикам генераторов UUID значительную свободу в очерченных рамках, но эталонная структура UUID, которая обсуждалась при выработке стандарта, следующая:

Возможные элементы кастомного сегмента:

• дополнительное псевдослучайное значение

• тип сущности или код таблицы базы данных

• пространство имен

• shard (сегмент) или partition (секция)

• код источника данных

• код типа операции или типа сообщения

• контрольная сумма

• другие элементы, специфичные для приложения