RFC 9562 рекомендует для БД бинарное 128-битовое представление UUID, если это возможно. Например, для этого хорошо подходит тип данных UUID в PostgreSQL. Для других систем я бы тоже посоветовал по возможности использовать бинарное внутреннее представление.
Для текстового представления могу посоветовать кодировку Crockford's Base32. Что-то близкое будет добавлено в RFC 9562 - сейчас авторы RFC 9562 это активно обсуждают. Но совместимость Crockford's Base32 с будущим стандартом маловероятна, так как алфавит, возможно, немного изменится, и последние два бита, возможно, будут использованы под контрольную сумму.
Зачем нужна предгенерация префикса (или любой другой части) при запуске приложения - мне непонятно.
А вообще тема производительности именно генерации UUID - надуманная. Для БД UUID генерятся заведомо быстрее, чем БД способна создать записи в таблице, где используются эти UUID. То есть, производительность генераторов UUID избыточная.
Седьмая версия UUID в дополнение к каноническому виду имеет три альтернативных метода реализации, и их вдобавок можно комбинировать. Вполне можно было реализовать что-то для описанного случая, не отклоняясь от RFC 9562. Например, если тормозит криптостойкий генератор случайных чисел, то случайный сегмент можно было укоротить за счет добавления субмиллисекундного сегмента и/или счетчика, инициализируемого случайным числом (с использованием предусмотренных RFC 9562 мер защиты от переполнения счетчика). Или нагенерить случайных чисел впрок.
Ваш комментарий навел меня на мысль: обычная русская латиница и русская латиница для русских имен собственных, когда они используются в качестве идентификаторов (только в именительном падеже и не в составе предложения), должна быть разной. Обычная русская латиница должна быть с диакритикой, чтобы не тащить в язык громоздкие конструкции из нескольких букв для одного звука. Нужно честно признать, что оригинальный латинский алфавит возможно был хорош для латыни, но плох даже для английского языка. Латиница для русских имен собственных, когда они используются в качестве идентификаторов (только в именительном падеже и не в составе предложения), должна быть транслитерацией на английский язык (со всеми этими ch, zh, sh, shch, kh, ts, yo, ya, yu) - как на дорожных указателях, в интернет-адресах и т.п. - чтобы, например, люди не страдали от четырех способов написания своего имени в разных документах и базах данных. Не потребуется дублировать названия топонимов на картах и схемах. Это уже и сейчас так во многих случаях - английский используется в русских текстах для написания торговых марок, названий компаний, имен иностранцев. Например, по моим наблюдениям, чаще пишут Windows, чем Виндовз. Иностранные имена (François, Benoît и т.п.), кроме английских, могут дублироваться обычной русской латиницей - чтобы было понятно, как их прочитать.
Ценное в нем то, что сейчас на нем думают 147 миллионов человек, а еще 113 миллионов владеют им как вторым языком. Русский язык - важная часть их личности. И эти люди не смогут, да и не захотят, чтобы их насильно переводили на английский, которым они не смогут пользоваться так же свободно (и не факт, что многим не придется еще учить китайский). Кроме того, есть большой культурный пласт на русском языке. И еще русский язык мешает массовой миграции населения в обе стороны, защищая основную часть населения от связанных с этим катаклизмов (утечка мозгов, безработица и падение зарплат, конфликты с соседними странами и т.д.). Это все, конечно, не означает, что не нужно изучать иностранные языки.
2 Эстонский (и в меннее выраженном виде также другие языки, где есть умлауты). Диграфы для смягчения согласных (h) хуже читаются, чем диакритические знаки (акут). Тем более, букву h любой русский скорее прочтет как [х], чем как мягкий знак.
3 Я имел в виду прежде всего использование диакритических знаков в латинице славянских языков.
4 В разных языках решаются одни и те же проблемы. Во многих случаях они решаются одинаковым образом. Было бы неразумным не исследовать этот опыт, а изобретать свой велосипед. Кроме того, многие люди знают или изучают несколько языков, и им проще, когда эти языки похожи по начертанию и букв и по обозначаемым этими буквами фонемам.
В алфавите по возможности не должно быть ничего необычного и тем более путающего. Например, использование "x" для обозначения звука [ш] кого угодно собьет с толку. Использование букв (J), которые в разных языках обозначают разные фонемы или даже несколько разных фонем, - тоже плохо. Применение букв (I), которые в разных местах текста обозначают разные звуки ([и] и [ы]), нарушает принцип фонетического письма, приближая текст к иероглифам.
Использование одного и того же диакритического знака "точка под буквой" для выполнения совершенно разных функций (смягчение согласных и обозначение шипящих звуков [ч] и [щ]) сбивает с толку. Каждый диакритический знак должен выполнять свою уникальную функцию (смягчение предшествующей согласной, отверждение предшествующей согласной (перед [э] и [ы]), смягчение согласной, обозначение шипящей согласной, ударение).
5 Ваш отказ от умлаутов, смягчающих предшествующие согласные, а особенно от автоматического смягчения согласных перед латинскими E и I приводит к перегрузке текста диакритическими знаками, смягчающими согласные. Кроме того, на самом деле звуки, обозначаемые буквами Я и А, Ю и У, Е и Э, И и Ы, Ё и О отличаются друг от друга не только смягчением предшествующей согласной, но и своим тоном. Поэтому неправильно выкидывать из алфавита половину гласных.
То, что ChatGPT смог без подсказок понять совершенно новый для него алфавит говорит о том, что это фонетический и системный алфавит, а не нагромождение исключений из правил.
Транслитерация русской латиницы на английский нужна именно для использования имен в английских текстах (паспорта, дорожные указатели и т.п.).
Для шипящих звуков в качестве основы следует использовать те буквы, фонемы которых похожи, так как создаются похожими действиями говорящего. Именно такой принцип традиционно применяется в латинице славянских языков. Опять же, похожесть алфавитов может быть удобной. Чередование звонких и глухих согласных не имеет к этому никакого отношения. Буква Ч вообще не имеет пары, и тогда от какой звонкой согласной ее нужно образовывать? Вы, кстати, как и я, в этом случае взяли за основу Ц. Та же ситуация и с Щ.
Это совершенно нечитабельный вариант русской латиницы. У такого результата несколько причин: 1. Очень поверхностный, неполный и ненаучный анализ русской фонетики 2. Необоснованно отброшено смягчение согласных перед определенными гласными, которые в других языках обозначаются с помощью умлаута 3. Не было проведено анализа того, как другие языки передают латиницей звуки, похожие на звуки русского языка 4. Не было проведено анализа того, как другие языки обозначают на латинице смягчение или отверждение согласных, а также шипящие согласные и ударение с помощью диакритических знаков 5. Справедливо отказавшись от одних диграфов, автор предлагает другие, о которые спотыкается взгляд при чтении
Вот читабельный вариант русской латиницы, лишенный этих недостатков: Sovremennaya russkaya latinica. Эту латиницу ChatGPT безошибочно переводит на кириллицу без каких-либо подсказок, промптов или правил. Любой русскоязычный человек бегло читает ее без подготовки и не зная правил.
Более того, программа, которую программист увидит в IDE для такой концепции, может не иметь вообще ничего общего с теми простынями программного кода, к которым все привыкли. Возможно, программа в окне IDE будет вообще состоять из нетекстовых элементов: виджеты и разные элементы графического интерфейса, иконки, вложенные блоки, сниппеты, карточки, вкладки, слои, таблицы, списки выбора и меню, экранные формы, разнообразные диаграммы, конструкторы запросов, диалоги с ИИ-ассистентом, гиперссылки, средства обеспечения версионности и форков, средства документации и планирования разработки и т.д. Какие-то данные тоже могут быть частью программы: логи, записи макросов, тест-кейсы, таблицы решений, словари и справочники и т.д. Текст вовсе не обязателен не только для хранения программного кода, но и для взаимодействия с программистом. А те модели, которые архитекторы сейчас рисуют в отрыве от программного кода (гексагональная архитектура и т.п.), станут просто частью программы.
Из обязательных функциональных требований к ХОРОШЕЙ функции генерации UUIDv7 можно отметить:
1) Наличие (между таймстемпом и случайной частью) счетчика длиной от 18 до 42 бит, инициализируемого каждую миллисекунду случайным значением, кроме старшего бита, иницилизируемого нулем (этим обеспечивается монотонность внутри миллисекунды и обеспечивается защита от переполнения счетчика)
2) Наличие формального параметра timestamp_offset сдвига таймстемпа по времени (позволяет скрыть истинные дату и время создания записи)
Опциональный формальный параметр seed (такой же, как параметр функции generateUUIDv7 в ClickHouse), который позволяет получить одинаковые значения UUIDv7 при нескольких вызовах функции, если это необходимо в SQL-запросе.
Единый генератор UUIDv7 на каждый сервер, что обеспечит монотонность генерируемых на сервере UUIDv7 внутри миллисекунды при параллельной записи в таблицу базы данных (как функция generateUUIDv7 в СУБД ClickHouse). Монотонность при многопоточности необходима, например, если нескольким микросервисам разрешено делать записи в общей таблице.
"Очень странно, что вы пишете про UUIDv1-5... в базе данных применять UUIDv5 почти то же самое, что применять строку в качестве первичного ключа, но если у вас на примете есть строка, подходящая на роль первичного ключа, то почему бы не взять её напрямую" =>
Да есть разработчики, которые упорно тащат UUIDv5 в БД, так как у них в источнике данных строка, а в БД у них уже UUID ("исторически так сложилось"). После долгих препирательств с ними пришлось вставить в RFC 9562 рекомендацию против таких ненадежных костылей: "Designers of database schema are cautioned against using name-based UUIDs (see Sections 5.3 and 5.5) as primary keys in tables. ... The general advice is to avoid name-based UUID natural keys and, instead, to utilize time-based UUID surrogate keys...".
________________________
"когда мы начинаем подмешивать UUIDv7, то они интенсивно заполняют очень узкую полосу значений, и всё, что оказалось правее, становится практически вечными кандидатами на смещение " =>
Да, есть такая проблема, но она успешно решается в современных СУБД. Например, B-Tree индексы в PostgreSQL спроектированы для эффективной работы с упорядоченными данными. Они автоматически управляют распределением данных по страницам и перебалансировкой дерева при необходимости (например, при операциях разделения страниц).
________________________
"Если не использовать сдвиг времени, то ULID, UUIDv6 и UUIDv7 совместимы внутри одной таблицы" => В PostgreSQL и в ClickHouse для хранения UUID любых версий используется один и тот же тип данных. Таким образом, внутри одной таблицы совместимы UUID любых версий, причем независимо от того, есть ли сдвиг времени таймстемпа.
Я не предлагаю делать новые записи с устаревшими UUIDv1-5. Но в таблицу с имеющимися записями с UUIDv1-5 можно добавлять записи с UUIDv7. Благодаря тому, что записи в БД хранятся не сплошным массивом, а в 8-килобайтных станицах, а страницы заполнены не полностью, не придется раздвигать имеющиеся записи (точнее, перезаписывать индексы) при вставке новых записей. Свободное пространство на странице используется для размещения новых записей или обновления существующих без необходимости перераспределения данных на других страницах. Это решение позволяет не переделывать старые ключи в формате UUIDv1-5 на новые в формате UUIDv7, что очень обременительно. И при этом не будет никаких нежелательных последствий.
Лучше бы лежачих полицейских положили на тротуарах и пешеходных дорожках как здесь: https://t.me/c/1765085644/12320 Это, мне кажется, эффективнее. И сразу понятно, где именно требуется снижать скорость. А то городские власти якобы ее снизили, но постоянно приходится шарахаться от гонщиков
RFC 9562 рекомендует для БД бинарное 128-битовое представление UUID, если это возможно. Например, для этого хорошо подходит тип данных UUID в PostgreSQL. Для других систем я бы тоже посоветовал по возможности использовать бинарное внутреннее представление.
Для текстового представления могу посоветовать кодировку Crockford's Base32. Что-то близкое будет добавлено в RFC 9562 - сейчас авторы RFC 9562 это активно обсуждают. Но совместимость Crockford's Base32 с будущим стандартом маловероятна, так как алфавит, возможно, немного изменится, и последние два бита, возможно, будут использованы под контрольную сумму.
Зачем нужна предгенерация префикса (или любой другой части) при запуске приложения - мне непонятно.
А вообще тема производительности именно генерации UUID - надуманная. Для БД UUID генерятся заведомо быстрее, чем БД способна создать записи в таблице, где используются эти UUID. То есть, производительность генераторов UUID избыточная.
Седьмая версия UUID в дополнение к каноническому виду имеет три альтернативных метода реализации, и их вдобавок можно комбинировать. Вполне можно было реализовать что-то для описанного случая, не отклоняясь от RFC 9562. Например, если тормозит криптостойкий генератор случайных чисел, то случайный сегмент можно было укоротить за счет добавления субмиллисекундного сегмента и/или счетчика, инициализируемого случайным числом (с использованием предусмотренных RFC 9562 мер защиты от переполнения счетчика). Или нагенерить случайных чисел впрок.
Ваш комментарий навел меня на мысль: обычная русская латиница и русская латиница для русских имен собственных, когда они используются в качестве идентификаторов (только в именительном падеже и не в составе предложения), должна быть разной. Обычная русская латиница должна быть с диакритикой, чтобы не тащить в язык громоздкие конструкции из нескольких букв для одного звука. Нужно честно признать, что оригинальный латинский алфавит возможно был хорош для латыни, но плох даже для английского языка. Латиница для русских имен собственных, когда они используются в качестве идентификаторов (только в именительном падеже и не в составе предложения), должна быть транслитерацией на английский язык (со всеми этими ch, zh, sh, shch, kh, ts, yo, ya, yu) - как на дорожных указателях, в интернет-адресах и т.п. - чтобы, например, люди не страдали от четырех способов написания своего имени в разных документах и базах данных. Не потребуется дублировать названия топонимов на картах и схемах. Это уже и сейчас так во многих случаях - английский используется в русских текстах для написания торговых марок, названий компаний, имен иностранцев. Например, по моим наблюдениям, чаще пишут Windows, чем Виндовз. Иностранные имена (François, Benoît и т.п.), кроме английских, могут дублироваться обычной русской латиницей - чтобы было понятно, как их прочитать.
Особенности хорошей реализации UUIDv7:
Binary, including UUID type
Timestamp offset
Incremented timestamp on overflow
Short counter segment initialized to 0 (the most significant, leftmost bit)
Long enough counter segment initialized with random data
Global counter or microsecond precision
Can generate the same UUIDs at function calls
Особенности хорошей реализации UUIDv7:
Binary, including UUID type
Timestamp offset
Incremented timestamp on overflow
Short counter segment initialized to 0 (the most significant, leftmost bit)
Long enough counter segment initialized with random data
Global counter or microsecond precision
Can generate the same UUIDs at function calls
Да ведь это одно и то же
Ценное в нем то, что сейчас на нем думают 147 миллионов человек, а еще 113 миллионов владеют им как вторым языком. Русский язык - важная часть их личности. И эти люди не смогут, да и не захотят, чтобы их насильно переводили на английский, которым они не смогут пользоваться так же свободно (и не факт, что многим не придется еще учить китайский). Кроме того, есть большой культурный пласт на русском языке. И еще русский язык мешает массовой миграции населения в обе стороны, защищая основную часть населения от связанных с этим катаклизмов (утечка мозгов, безработица и падение зарплат, конфликты с соседними странами и т.д.). Это все, конечно, не означает, что не нужно изучать иностранные языки.
@smallreg
1 https://foxford.ru/wiki/russkiy-yazyk/sootnoshenie-bukv-i-zvukov
2 Эстонский (и в меннее выраженном виде также другие языки, где есть умлауты). Диграфы для смягчения согласных (h) хуже читаются, чем диакритические знаки (акут). Тем более, букву h любой русский скорее прочтет как [х], чем как мягкий знак.
3 Я имел в виду прежде всего использование диакритических знаков в латинице славянских языков.
4 В разных языках решаются одни и те же проблемы. Во многих случаях они решаются одинаковым образом. Было бы неразумным не исследовать этот опыт, а изобретать свой велосипед. Кроме того, многие люди знают или изучают несколько языков, и им проще, когда эти языки похожи по начертанию и букв и по обозначаемым этими буквами фонемам.
В алфавите по возможности не должно быть ничего необычного и тем более путающего. Например, использование "x" для обозначения звука [ш] кого угодно собьет с толку. Использование букв (J), которые в разных языках обозначают разные фонемы или даже несколько разных фонем, - тоже плохо. Применение букв (I), которые в разных местах текста обозначают разные звуки ([и] и [ы]), нарушает принцип фонетического письма, приближая текст к иероглифам.
Использование одного и того же диакритического знака "точка под буквой" для выполнения совершенно разных функций (смягчение согласных и обозначение шипящих звуков [ч] и [щ]) сбивает с толку. Каждый диакритический знак должен выполнять свою уникальную функцию (смягчение предшествующей согласной, отверждение предшествующей согласной (перед [э] и [ы]), смягчение согласной, обозначение шипящей согласной, ударение).
5 Ваш отказ от умлаутов, смягчающих предшествующие согласные, а особенно от автоматического смягчения согласных перед латинскими E и I приводит к перегрузке текста диакритическими знаками, смягчающими согласные. Кроме того, на самом деле звуки, обозначаемые буквами Я и А, Ю и У, Е и Э, И и Ы, Ё и О отличаются друг от друга не только смягчением предшествующей согласной, но и своим тоном. Поэтому неправильно выкидывать из алфавита половину гласных.
То, что ChatGPT смог без подсказок понять совершенно новый для него алфавит говорит о том, что это фонетический и системный алфавит, а не нагромождение исключений из правил.
Транслитерация русской латиницы на английский нужна именно для использования имен в английских текстах (паспорта, дорожные указатели и т.п.).
Для шипящих звуков в качестве основы следует использовать те буквы, фонемы которых похожи, так как создаются похожими действиями говорящего. Именно такой принцип традиционно применяется в латинице славянских языков. Опять же, похожесть алфавитов может быть удобной. Чередование звонких и глухих согласных не имеет к этому никакого отношения. Буква Ч вообще не имеет пары, и тогда от какой звонкой согласной ее нужно образовывать? Вы, кстати, как и я, в этом случае взяли за основу Ц. Та же ситуация и с Щ.
Чешская латиница ужасна. Аж 42 буквы. Бессистемная. Множество исключений из правил. Тогда уж хорватская
Вот пример того, что это не так: Гаевица
Это совершенно нечитабельный вариант русской латиницы. У такого результата несколько причин:
1. Очень поверхностный, неполный и ненаучный анализ русской фонетики
2. Необоснованно отброшено смягчение согласных перед определенными гласными, которые в других языках обозначаются с помощью умлаута
3. Не было проведено анализа того, как другие языки передают латиницей звуки, похожие на звуки русского языка
4. Не было проведено анализа того, как другие языки обозначают на латинице смягчение или отверждение согласных, а также шипящие согласные и ударение с помощью диакритических знаков
5. Справедливо отказавшись от одних диграфов, автор предлагает другие, о которые спотыкается взгляд при чтении
Вот читабельный вариант русской латиницы, лишенный этих недостатков: Sovremennaya russkaya latinica. Эту латиницу ChatGPT безошибочно переводит на кириллицу без каких-либо подсказок, промптов или правил. Любой русскоязычный человек бегло читает ее без подготовки и не зная правил.
Полностью согласен с Вами.
Более того, программа, которую программист увидит в IDE для такой концепции, может не иметь вообще ничего общего с теми простынями программного кода, к которым все привыкли. Возможно, программа в окне IDE будет вообще состоять из нетекстовых элементов: виджеты и разные элементы графического интерфейса, иконки, вложенные блоки, сниппеты, карточки, вкладки, слои, таблицы, списки выбора и меню, экранные формы, разнообразные диаграммы, конструкторы запросов, диалоги с ИИ-ассистентом, гиперссылки, средства обеспечения версионности и форков, средства документации и планирования разработки и т.д. Какие-то данные тоже могут быть частью программы: логи, записи макросов, тест-кейсы, таблицы решений, словари и справочники и т.д. Текст вовсе не обязателен не только для хранения программного кода, но и для взаимодействия с программистом. А те модели, которые архитекторы сейчас рисуют в отрыве от программного кода (гексагональная архитектура и т.п.), станут просто частью программы.
Из обязательных функциональных требований к ХОРОШЕЙ функции генерации UUIDv7 можно отметить:
1) Наличие (между таймстемпом и случайной частью) счетчика длиной от 18 до 42 бит, инициализируемого каждую миллисекунду случайным значением, кроме старшего бита, иницилизируемого нулем (этим обеспечивается монотонность внутри миллисекунды и обеспечивается защита от переполнения счетчика)
2) Наличие формального параметра timestamp_offset сдвига таймстемпа по времени (позволяет скрыть истинные дату и время создания записи)
3) Гарантия монотонности генерируемых UUIDv7 внутри миллисекунды при параллельной работе нескольких микросервисов с одной и той же таблицей — благодаря единому генератору UUIDv7 на сервер (реализовано в ClickHouse: https://clickhouse.com/docs/en/sql-reference/functions/uuid-functions#generateUUIDv7 )
4) Возможность получать одни и те же значения UUIDv7 для нескольких вызовов функций, если это необходимо в SQL-запросе (это интересно реализовано в ClickHouse с помощью параметра: https://github.com/ClickHouse/ClickHouse/pull/62852#issuecomment-2150127227 )
Что еще следовало бы добавить:
Опциональный формальный параметр seed (такой же, как параметр функции generateUUIDv7 в ClickHouse), который позволяет получить одинаковые значения UUIDv7 при нескольких вызовах функции, если это необходимо в SQL-запросе.
Единый генератор UUIDv7 на каждый сервер, что обеспечит монотонность генерируемых на сервере UUIDv7 внутри миллисекунды при параллельной записи в таблицу базы данных (как функция generateUUIDv7 в СУБД ClickHouse). Монотонность при многопоточности необходима, например, если нескольким микросервисам разрешено делать записи в общей таблице.
Разговор в данном случае идет об использовании именно в БД. Ваш комментарий неуместен.
"Очень странно, что вы пишете про UUIDv1-5... в базе данных применять UUIDv5 почти то же самое, что применять строку в качестве первичного ключа, но если у вас на примете есть строка, подходящая на роль первичного ключа, то почему бы не взять её напрямую" =>
Да есть разработчики, которые упорно тащат UUIDv5 в БД, так как у них в источнике данных строка, а в БД у них уже UUID ("исторически так сложилось"). После долгих препирательств с ними пришлось вставить в RFC 9562 рекомендацию против таких ненадежных костылей: "Designers of database schema are cautioned against using name-based UUIDs (see Sections 5.3 and 5.5) as primary keys in tables. ... The general advice is to avoid name-based UUID natural keys and, instead, to utilize time-based UUID surrogate keys...".
________________________
"когда мы начинаем подмешивать UUIDv7, то они интенсивно заполняют очень узкую полосу значений, и всё, что оказалось правее, становится практически вечными кандидатами на смещение " =>
Да, есть такая проблема, но она успешно решается в современных СУБД. Например, B-Tree индексы в PostgreSQL спроектированы для эффективной работы с упорядоченными данными. Они автоматически управляют распределением данных по страницам и перебалансировкой дерева при необходимости (например, при операциях разделения страниц).
________________________
"Если не использовать сдвиг времени, то ULID, UUIDv6 и UUIDv7 совместимы внутри одной таблицы" =>
В PostgreSQL и в ClickHouse для хранения UUID любых версий используется один и тот же тип данных. Таким образом, внутри одной таблицы совместимы UUID любых версий, причем независимо от того, есть ли сдвиг времени таймстемпа.
Я не предлагаю делать новые записи с устаревшими UUIDv1-5. Но в таблицу с имеющимися записями с UUIDv1-5 можно добавлять записи с UUIDv7. Благодаря тому, что записи в БД хранятся не сплошным массивом, а в 8-килобайтных станицах, а страницы заполнены не полностью, не придется раздвигать имеющиеся записи (точнее, перезаписывать индексы) при вставке новых записей. Свободное пространство на странице используется для размещения новых записей или обновления существующих без необходимости перераспределения данных на других страницах. Это решение позволяет не переделывать старые ключи в формате UUIDv1-5 на новые в формате UUIDv7, что очень обременительно. И при этом не будет никаких нежелательных последствий.
Лучше бы лежачих полицейских положили на тротуарах и пешеходных дорожках как здесь: https://t.me/c/1765085644/12320 Это, мне кажется, эффективнее. И сразу понятно, где именно требуется снижать скорость. А то городские власти якобы ее снизили, но постоянно приходится шарахаться от гонщиков
Кто-то быстренько опубликовал перевод статьи на английский
Спасибо за комментарий. По поднятым в нем вопросам я внес уточнения в текст статьи.