Комментарии 3
Автор за деревьями не видит леса. Он, видимо, не догадывается, зачем десятки высококвалифицированных профессионалов потратили много лет на создание UUIDv7. Поэтому он делает далеко идущие глобальные неверные выводы, основываясь на незначительных деталях. При таком подходе мы бы до сих пор программировали на ассемблере, или даже в машинных кодах, так как компьютеры "оптимизированы для их использования". Такого рода "оптимизация" потом обернется огромными затратами, чтобы как-то обеспечить слияние данных с одинаковыми ключами из разных систем. Проблемы возникнут и при экспорте данных, и при параллельной генерации записей несколькими микросервисами (особенно при высокой нагрузке, когда возникает lock contention). Глобальный поиск по ключу будет невозможен, зато ошибки из-за коллизии ключей будут вполне возможны. Недоброжелатель легко догадается о количестве записей в таблице и легко подберет валидный ключ. Зато сэкономим один мегабайт индекса ))
Вы участовали в разработке стандарта стандарта uuidv7 и мне приятно, что прочли мою статью. Основное в статье про параметр cache. uuidv7 - огромное достижение по сравнению с предыдущими, генерируемыми случайным образом. Могу сказать, что размер таблицы в примере с bigint и uuidv7 тот же самый, благодаря выравниванию размера строки в PostgreSQL. Для большинства таблиц использование uuid вместо bigint не увеличит их размер. Увеличение размера индекса в 1,38 раз несущественно, если нужны преимущества uuid. Использование uuid для идентификации строк баз данных была бы революция в архитектуре, означающая, что уникальные идентификаторы строк можно делать глобальными. Например, чтобы идентификаторы "заказов" и "товаров" не пересекались. Увеличение размера индекса покрывается тем, что uuid можно использовать там где нельзя использовать bigint, например, как номер заказа. Если использовать bigint, то можно догадаться о числе заказов, а это может быть конфиденциально. Если первичный ключ bigint, то в таблицу придется добавлять столбец для номера заказа, размер таблицы и индекса сильно увеличатся. Но есть и недостатки. К примеру, номер этой статьи на хабре 889156 и я ее написал потому, что у моей первой статьи номер круглый 888854 и я хотел чтобы и у этой статьи номер тоже был круглый, но не успел. Если бы хабр использовал uuid, я бы не торопился писать статью. Шуточно, но доля правды в этом есть ))
Сравнение uuid vs bigint это холивар, где сторонники uuid более активны. Инерция велика - oid в системных каталогах PostgreSQL это int, а даже не bigint. Важно развитие отрасли и все минусы и плюсы использования типов данных должны честно перечисляться и быть известны, искусственно рекламировать или склонять в сторону uuid я считаю неправильным. Затыкать рот тем, кто упоминает недостатки uuid тоже. Использоваться должно оптимальное решение, тогда программные системы будут лучше работать. Например, недостаток uuid - по телефону сложно продиктовать и набрать руками. Ещё до uuid я написал по заказу генератор в формате booking reference (используется системами бронирования), которые 6 символов (5 символов быстро исчерпываются, а 7 не достигаются), скомбинировав последовательность со счетчиком времени для защиты дублирования при рестарта сервера приложений. Плюсы - краткость для печати и защита от подбора. Недавно поискал есть ли стандарт на формат bookref, но не нашел. Часто используется, а стандарта нет.
"Важно развитие отрасли и все минусы и плюсы использования типов данных должны честно перечисляться и быть известны, искусственно рекламировать или склонять в сторону uuid я считаю неправильным. Затыкать рот тем, кто упоминает недостатки uuid тоже. Использоваться должно оптимальное решение, тогда программные системы будут лучше работать"
Авторов и контрибьюторов UUIDv7 невозможно упрекнуть в том, что они не видят или скрывают недостатки, а тем более затыкают рот критикам. Наоборот, вся история UUIDv7 - это история выявления и преодоления недостатков UUID. Идея была в том, чтобы не выбирать локальное и поэтому несовместимое "оптимальное" решение из нескольких убогих вариантов, а сделать универсальный тип идентификатора, устраняя все возможные недостатки UUID, вплоть до влияния сверхвысокой частоты генерации или сбоев системных часов, раскрытия даты и времени создания записи и возникновения lock contention при записи.
И это преодоление недостатков UUID продолжается. Например, UUID занимает много места и плохо идентифицируется в человекочитаемом документе, а также его трудно копировать с помощью мыши. До недавнего времени эти недостатки пытались преодолеть использованием различных кодировок (наиболее популярная Crockford's Base32), но, видимо, лучше вообще скрыть UUID с глаз человека за интерактивный виджет с идентиконом. А диктовка по телефону приятным голосом вполне по силам виртуальному помощнику.
В UUID еще много нераскрытых достоинств. Например, это прекрасное средство преодоления границ между информационными системами и глобального поиска. Но конкретные разработки ждут своего часа.
Кэширование значений последовательностей в PostgreSQL, bigint и uuidv7