31 марта 2022 года на сайте IETF был официально размещен текст рабочего документа (копия 1, копия 2) New UUID Formats (далее – стандарт), который должен формально обновить, а фактически заменить давно устаревший и изначально ущербный RFC 4122.
В стандарте представлены новые форматы универсальных уникальных идентификаторов (UUID), имеющих следующие свойства:
для использования в высоконагруженных приложениях и базах данных – как монолитных, так и распределенных,
возрастающие по времени генерации (без дополнительных секунд),
содержащие таймстемп, счетчик с инициализацией его сегментов нулем и псевдослучайным значением, а также собственно псевдослучайное значение,
объединенные с метаданными.
Стандарт рекомендует поставщикам СУБД обеспечить создание и хранение UUID новых форматов для использования в качестве идентификаторов или левых частей идентификаторов, таких как, помимо прочего:
первичные ключи,
суррогатные ключи для хронологических баз данных,
внешние ключи, включая используемые в полиморфных отношениях,
ключи для пар ключ-значение в столбцах JSON и базах данных типа «ключ-значение».
В долгих и жарких спорах удалось выработать стандарт по существу безупречного качества. Хотя некоторые туманные формулировки и прежние неудачные варианты технических решений сохранились в тексте, однако найдены оригинальные и красивые решения всех проблем. Стоит особенно отметить творческий вклад жителя Японии с псевдонимом LiosK и разумные решения инициаторов стандарта Brad Peabody и Kyzer Davis из США. Стандартом обеспечена максимально возможная скорость поиска записей по содержащемуся в них значению UUID. Стандарт содержит множество правильных рекомендаций с обоснованием. Единственный существенный изъян стандарта – это расточительное использование 6 из 128 битов UUID (сегменты ver и var) лишь для совместимости с отжившим RFC 4122. Стандарт превосходит ULID, KSUID, CUID и остальные аналоги. Все они были исследованы и указаны в стандарте.
Стандарт еще не утвержден, но поставщики СУБД уже могут начинать его реализовывать. Невозможно представить, что появится другой – более качественный и существенно отличающийся вариант стандарта. Приложенные к стандарту прототипы на языке C сильно упрощенные, и поэтому они не могут быть хорошей основой для разработки. Из трех предложенных форматов наибольшую практическую ценность представляет версия UUIDv7.
В текущую версию стандарта из-за нехватки времени не вошли альтернативные текстовые кодировки UUID. Инициаторы стандарта хотят включить их в следующую версию стандарта, причем кодировка Crockford’s Base32 уже ими одобрена.
Хотя стандарт предоставляет разработчикам генераторов UUID значительную свободу в очерченных рамках, но эталонная структура UUID, которая обсуждалась при выработке стандарта, следующая:
Обозначение в стандарте | Позиция сегмента в UUID слева направо | Длина, битов | Двоичное значение или алгоритм расчета | Предназначение |
unix_ts_ms | 1 | 48 | Количество миллисекунд с полуночи (00:00:00) 1 января 1970 года по всемирному координированному времени (UTC) минус дополнительные секунды | Обеспечение монотонности записываемых UUID. Таймстемп с миллисекундной точностью, отстающий от UTC на десятки секунд. Миллисекунда - это максимально возможная точность для упорядочения по моменту времени генерации UUID, приходящих из разных источников |
ver | 2 | 4 | "0111" | Версия UUIDv7. Смысл этого сегмента лишь в совместимости с RFC 4122 |
rand_a | 3 | 1 | Сегмент счетчика, инициализируемый нулем каждую миллисекунду | Защита от переполнения счетчика при маловероятной неудачной инициализации счетчика большим псевдослучайным значением |
4 | 11 | Сегмент счетчика, инициализируемый псевдослучайным значением каждую миллисекунду | Счетчик обеспечивает монотонность UUID из одного источника, генерируемых в течение миллисекунды. Инициализация счетчика псевдослучайным значением уменьшает вероятность коллизий UUID | |
var | 5 | 2 | "10" | Вариант, детально описанный в стандарте или в RFC 4122, в отличие от других упомянутых в RFC 4122 вариантов. Смысл этого сегмента лишь в совместимости с RFC 4122 |
rand_b | 6 | 12 | Сегмент счетчика, инициализируемый псевдослучайным значением каждую миллисекунду | Счетчик должен быть достаточно длинным для защиты от переполнения, но не слишком длинным, чтобы ускорить желательный двоичный поиск UUID по старшим битам. В течение миллисекунды весь счетчик увеличивается на единицу для каждого следующего UUID |
7 | 50 | Псевдослучайное значение, сгенерированное отдельно для каждого UUID | В отличие от сегмента счетчика, инициализируемого псевдослучайным значением каждую миллисекунду, этот сегмент затрудняет угадывание близких по значению UUID с одинаковыми таймстемпами | |
обозначение отсутствует | справа от UUID в идентификаторе, используемом в качестве уникального или суррогатного ключа | любая | Кастомный сегмент, который может быть составным | См. под таблицей возможные элементы кастомного сегмента |
Возможные элементы кастомного сегмента:
дополнительное псевдослучайное значение
тип сущности или код таблицы базы данных
пространство имен
shard (сегмент) или partition (секция)
код источника данных
код типа операции или типа сообщения
контрольная сумма
другие элементы, специфичные для приложения
