UUIDv7 — ключ к глобальному поиску с помощью LLM в произвольных внешних системах
Представим себе такой сценарий. Пользователь устно и/или в чате поручает ИИ-агенту найти и приобрести нужный товар с заданными параметрами. ИИ-агент в разговоре уточняет у пользователя задание, составляет описание товара и на его основе формирует запрос к поисковой системе... а затем ищет товар в базах данных поставщиков. Как это реализовать
Show HN: Generate Version 7 UUID's for a Timestamp
https://uuidv7.org/
#ycombinator #uuidv7 #uuid #generator #date_based_uuid #time_based_uuid #version7 #online_tools
В PostgreSQL необходим официальный бенчмарк для функции uuidv7()
В 18 версии PostgreSQL появится функция uuidv7() . Она разработана для замены последовательных автоинкрементных идентификаторов SERIAL, BIGSERIAL и IDENTITY, которые могут привести к катастрофическому дублированию ключей при слиянии данных, и для замены более медленных UUIDv4. Использование функции uuidv7() позволит упростить архитектуру информационных систем, упростить SQL-запросы, избежать некоторых ошибок, облегчить внесение изменений и благодаря этому повысить надежность и снизить стоимость разработки и сопровождения информационных систем. Однако для объективной и корректной оценки использования функции uuidv7() необходим официальный бенчмарк в PostgreSQL. Без такого бенчмарка может быть сделан необоснованный выбор в пользу автоинкремента.
RT Nik Samokhvalov from birdsite
UUIDv7 is finally committed to Postgres — after approval of corresponding RFC.
This was coded by Andry Borodin https://www.youtube.com/live/YPq_hiOE-N8
As a reminder, you can start using UUIDv7 and benefit (performance-wise) from it right now, there is no need to wait until PG18: migration from UUIDv4 to UUIDv7 is among popular topics the Postgres.AI team often discusses with consulting customers:
https://github.com/postgres-ai/postgres-howtos/blob/main/0064_how_to_use_uuid.md
Идентификаторы в БД: INT vs UUID
Привет! Меня зовут Женя, я бэкенд-разработчик, и в этом посте хотела бы кратко обсудить плюсы и минусы разных вариантов идентификаторов в базе данных.
Смещение значения таймстемпа UUIDv7
UUIDv7 – это удобный и безопасный 128-битный уникальный идентификатор, который призван заменить целочисленные суррогатные ключи формата bigint в качестве первичного ключа в высоконагруженных базах данных и распределенных системах.
there seems to be a lot of excitement for #uuidV7 these days (timestamp-based). it's very cool, and a good choice if you're using the #uuid or #guid as a database key (to avoid fragmentation)
https://ntietz.com/blog/til-uses-for-the-different-uuid-versions/
i also really like #ulid for this, and they can be converted to uuids/guids easily and quickly.
one thing i don't see many people talk about when they move to monotonically incrementing ids (like v7/ulid) is this: if you have a distributed database you will end up with poor balancing with these ids. not what most people do, i guess, but it's something to think about.
Спецификация уникальных идентификаторов UUIDv7 для ключей баз данных и распределенных систем по новому стандарту RFC9562
Долгожданный стандарт RFC9562 "Universally Unique IDentifiers (UUID)" с тремя новыми версиями идентификаторов UUID (6, 7 и 8) вместо малопригодного RFC4122 наконец-то вступил в силу. Я участвовал в разработке нового стандарта. Обзор стандарта можно посмотреть в статье . Введенные новым стандартом идентификаторы седьмой версии UUIDv7 — это лучшее, что теперь есть для ключей баз данных и распределенных систем. Они обеспечивают такую же производительность, как и bigint . UUIDv7 уже реализованы в том или ином виде в основных языках программирования и в некоторых СУБД. Сгенерированные UUIDv7 имеют все преимущества UUID и при этом упорядочены по дате и времени создания. Это ускоряет поиск индексов и записей в БД по ключу в формате UUID, значительно упрощает и ускоряет базы данных и распределенные системы. Неупорядоченность значений UUID прежде сдерживала использование UUID в качестве ключей и вынуждала разработчиков выдумывать собственные форматы идентификаторов или довольствоваться последовательными целыми числами в качестве ключей. Черновик стандарта активно обсуждался на Хабре в апреле 2022 года в комментариях к статье "Встречайте UUID нового поколения для ключей высоконагруженных систем" . Разные участники разработки нового стандарта придерживались различных взглядов, и практически все обсуждавшиеся альтернативные варианты структуры UUIDv7 вошли в стандарт. Поэтому теперь перед разработчиками возникает вопрос, какую из множества возможных спецификаций UUIDv7 реализовывать и применять. Также для массового перехода на UUIDv7 нужна дополнительная функциональность, повышающая привлекательность UUIDv7 для разработчиков и бизнеса. Предложенная мной ниже спецификация UUIDv7 с дополнительной функциональностью описывает максимально надежный и удобный вариант структуры UUIDv7 для самых сложных и высоконагруженных информационных систем. Функциональность упорядочена по приоритету реализации
UUIDv7
Седьмая версия UUID (Universally Unique Identifier Version 7, UUID Version 7, UUIDv7) является модифицированной и стандартизованной версией ULID . Проект стандарта (далее стандарт) находится в ожидании окончательной проверки редактором. Но уже имеется большое количество реализаций UUIDv7, применяемых в действующих информационных системах. В интернете доступно большое количество информации по ключевому слову UUIDv7.
Как связать натуральные ключи с суррогатным в Anchor Modeling
Хранить значения натуральных ключей необходимо, потому что они связывают хранимые данные с реальным миром (внешними классификаторами, реестрами и т.п.), и с ними работают бизнес-пользователи: в выпадающих списках, отчетах и дашбордах. Но в методологии Anchor Modeling для связи таблиц используются только суррогатные ключи, не подверженные изменениям, и это правильно. Поэтому нужно хранить связь натуральных ключей с суррогатным ключом, предпочтительно формата UUIDv7 . Как же это сделать в методологии Anchor Modeling? Получить ответ
Hacker News 
