Всем привет!
Наверное все здесь знают, что такое UUID. Universally Unique IDentifier. Можно использовать как искусственный ключ. С высокой точностью обеспечивает уникальность, хотя и не 100%. Казалось бы, о чем здесь можно рассказывать. Ну и UUID и UUID.
А если я скажу, что недавно вышла 7-я (!) версия стандарта?) Для меня это было сюрпризом.
Вот описание первых 5 версий: https://habr.com/ru/companies/vk/articles/522094/
Вот - какие проблемы решает 7-й https://www.pvsm.ru/sistemnoe-programmirovanie/367012
А вот генератор разных версий с кратким описанием каждой: https://idtools.co/uuid/v7
Если вкратце про суть проблемы - UUID часто используют в БД как ключ. Но при таком использовании у него есть один большой минус - значения UUID не возрастают монолитно, как, например, обычный инкремент. Где это может быть полезно - сортировка и партиционирование таблиц.
Что интересно - в первой версии UUID было зашито время, а время - это тоже счетчик, в формате "с начала эпохи" или Unix time. Но в первой версии время хранилось в 2 разных частях UUID, причем еще и в перевернутом виде.
А 6-я версия - легкая модификация 1-й, где первый блок, содержащий время, хранят в нормальном формате и по таким UUID возможна сортировка.
#uuid #rdbms
Наверное все здесь знают, что такое UUID. Universally Unique IDentifier. Можно использовать как искусственный ключ. С высокой точностью обеспечивает уникальность, хотя и не 100%. Казалось бы, о чем здесь можно рассказывать. Ну и UUID и UUID.
А если я скажу, что недавно вышла 7-я (!) версия стандарта?) Для меня это было сюрпризом.
Вот описание первых 5 версий: https://habr.com/ru/companies/vk/articles/522094/
Вот - какие проблемы решает 7-й https://www.pvsm.ru/sistemnoe-programmirovanie/367012
А вот генератор разных версий с кратким описанием каждой: https://idtools.co/uuid/v7
Если вкратце про суть проблемы - UUID часто используют в БД как ключ. Но при таком использовании у него есть один большой минус - значения UUID не возрастают монолитно, как, например, обычный инкремент. Где это может быть полезно - сортировка и партиционирование таблиц.
Что интересно - в первой версии UUID было зашито время, а время - это тоже счетчик, в формате "с начала эпохи" или Unix time. Но в первой версии время хранилось в 2 разных частях UUID, причем еще и в перевернутом виде.
А 6-я версия - легкая модификация 1-й, где первый блок, содержащий время, хранят в нормальном формате и по таким UUID возможна сортировка.
#uuid #rdbms
Хабр
Как генерируются UUID
Вы наверняка уже использовали в своих проектах UUID и полагали, что они уникальны. Давайте рассмотрим основные аспекты реализации и разберёмся, почему UUID практически уникальны, поскольку существует...
🔥4❤2
UUID ключи в PostgreSQL
Я уже писал про версии UUID https://t.me/javaKotlinDevOps/264
Особенно интересной выглядит 7-я версия для использования в БД для построения индексов по двум причинам:
1) позволяет сортировать записи по времени создания
2) значение содержит метку времени, ее можно извлечь
Ну и эффект, наблюдаемый только в БД - записи ложатся последовательно в индексах и, соответственно, partition благодаря тому, что генерируются монотонно возрастающие значения.
Стандарт был принят в мае 2024 года https://datatracker.ietf.org/doc/rfc9562/
И не прошло и полгода (прошел год, но в мире БД это кажется даже быстро) и появляется PostgreSQL 18 c нативной поддержкой UUID v7 (функции uuidv7() и uuid_extract_timestamp) https://habr.com/ru/companies/spring_aio/articles/946168/
P.S. Если вчитаться в стандарт - попадаешь в кроличью нору:
1) для целей безопасности метка времени обрезается до миллисекунд
2) но чтобы получить возрастающие значения используется счетчик
3) счетчик инициализируется случайным числом, во избежание коллизий
4) есть защита от переполнения счетчика - допустимо использовать как счетчик ту часть метки времени, которую мы обнулили ранее, главное не перейти за границы миллисекунды. Если и этого не хватит - вопрос...
5) генератор должен хранить время t0, чтобы при переводе времени продолжать использовать исходное время и значения были уникальными и монотонно возрастающими
...
#postgresql #uuid
Я уже писал про версии UUID https://t.me/javaKotlinDevOps/264
Особенно интересной выглядит 7-я версия для использования в БД для построения индексов по двум причинам:
1) позволяет сортировать записи по времени создания
2) значение содержит метку времени, ее можно извлечь
Ну и эффект, наблюдаемый только в БД - записи ложатся последовательно в индексах и, соответственно, partition благодаря тому, что генерируются монотонно возрастающие значения.
Стандарт был принят в мае 2024 года https://datatracker.ietf.org/doc/rfc9562/
И не прошло и полгода (прошел год, но в мире БД это кажется даже быстро) и появляется PostgreSQL 18 c нативной поддержкой UUID v7 (функции uuidv7() и uuid_extract_timestamp) https://habr.com/ru/companies/spring_aio/articles/946168/
P.S. Если вчитаться в стандарт - попадаешь в кроличью нору:
1) для целей безопасности метка времени обрезается до миллисекунд
2) но чтобы получить возрастающие значения используется счетчик
3) счетчик инициализируется случайным числом, во избежание коллизий
4) есть защита от переполнения счетчика - допустимо использовать как счетчик ту часть метки времени, которую мы обнулили ранее, главное не перейти за границы миллисекунды. Если и этого не хватит - вопрос...
5) генератор должен хранить время t0, чтобы при переводе времени продолжать использовать исходное время и значения были уникальными и монотонно возрастающими
...
#postgresql #uuid
Telegram
(java || kotlin) && devOps
Всем привет!
Наверное все здесь знают, что такое UUID. Universally Unique IDentifier. Можно использовать как искусственный ключ. С высокой точностью обеспечивает уникальность, хотя и не 100%. Казалось бы, о чем здесь можно рассказывать. Ну и UUID и UUID.…
Наверное все здесь знают, что такое UUID. Universally Unique IDentifier. Можно использовать как искусственный ключ. С высокой точностью обеспечивает уникальность, хотя и не 100%. Казалось бы, о чем здесь можно рассказывать. Ну и UUID и UUID.…
👀2