Comments 35
Оо, спасибо, добавлю в бенчмарк и опишу. Конечно, смущает, что у пакетов с реализацией этой версии количество загрузок на уровне экспериментов отдельных людей, но никак не продакшен-использования.
А нам всего-то и нужен сортируемый последовательно-возрастающий глобально-уникальный идентификатор чтобы использовать его в качестве ключа. Где его взять?
Использовать ULID, вместо GUID.
Я раньше не мог понять, почему в 1С guid элементов справочников при массовом создании из одного сеанса не совсем уникальные - они отличаются на 1.
С учетом того, что индекс по guid в 1С кластерный, всё встало на свои места.
Такой порядок делает лексикографическое упорядочивание немного бессмысленным.
так ms sql и сортирует guid не лексикографически
https://stackoverflow.com/questions/7810602/sql-server-guid-sort-algorithm-why
Все прекрасно, если у вас простые плоские структуры. Что вы будете делать, если задача - скопировать N записей, скажем от одного родителя к другому? Будете на клиенте генерировать ключи по одному, и ходить в БД с каждой записью? Как будете работать с клиентскими ключами, если у вас, например, трехуровневвая иерархия (школа-класс-ученик ;) ) - вы утонете в цепочках гуидов при подобной операции. Дальше - идемпотентность. Тоже все просто, если операция плоская. А если сломались чилдовые сущности после вставки родительских? Сможете поддержать трехуровневый маппер и правильно его накатить снова (и главное, для чего?)
Затем, мы оптимально вставили записи с гуид-ключами в таблицу. А отдаем ли мы себе отчет, какой у нас индекс динамичности данных (отношение W / (R + W))? Ибо если наш кластерный индекс длинный - то все некластерные индексы будут ссылаться на этот длинный индекс, равно как все FK будут иметь такую же длину. В итоге, страницы данных и индексов будут большими, вычитка их будет медленной, так как среднее кол-во записей на страницу упадет. Вы уверены, что скорость вставки именно в вашем случае это перевесит?
Я, возможно, не совсем понял вопрос. Мне кажется, что здесь задачи и зоны ответственности могут делиться очень по-разному в зависимости от того, какой сервис сохраняет класс, а какой ученика, и чья зона ответственности генерировать идентификаторы учеников — сервиса, который сохраняет класс или клиента этого сервиса, который и инициировал эту операцию.
Это же касается идемпотентности — если операция "атомарная" в том плане, что клиент сервиса классов посылает в метод создания список учеников, то он вполне и сгенерирует идентификаторы, а сервис классов вполне обработает в таком случае повторный запрос. А вот при генерации на стороне БД будет больно.
В случае с вычиткой я упоминал в статье бенчмарк, который показывает, что вычитка из разрозненного набора страниц не такая большая проблема (подозреваю, что "в некоторых сценариях" типа hdd или отчаяной нехватки оперативной памяти и необходимости чтения с диска это будет не так), но в общем случае я согласен с проблемой, что надо очень хорошо понимать не только индекс динамичности, но и профили запросов — потому что выстрелить себе в ногу в хранилищах проще простого.
я правильно понимаю, что вы против использования uuid и за использование восьмибитных int как идентификаторов?
Я против попытки сделать просто сложные вещи в общем виде. Это невозможно, как невозможен перпетуум-мобиле.
В случае эффективной работы с БД проблема, как таковая, никуда не уходит - а просто перемещается с бакенда на фронтенд, либо с записи на чтение. Как воздушный пузырь в частично наполненном водой шарике. В каком-то частном случае вам удобнее иметь пузырь с одной стороны - да, это облегчает вашу частно-определенную задачу, но из этого совсем не следует, что вы нашли эффективное решение задачи общего вида.
просто перемещается с бакенда на фронтенд
а в чём проблема на фронтенде? подключить библиотеку?
либо с записи на чтение
сомневаюсь, что на реальных данных вы увидите различие по производительности запросов на чтение между таблицами с 128-битным uuid и с 64-битным счётчиком.
ну а 32-битные счётчики и большие таблицы сегодня не очень совместимы, уже натыкался на переполнение.
Как будете работать с клиентскими ключами, если у вас, например, трехуровневвая иерархия (школа-класс-ученик ;) ) — вы утонете в цепочках гуидов при подобной операции.
А в чём, собственно, проблема, и чем цепочка гуидов принципиально отличается от цепочки каких-нибудь bigint?
Дальше — идемпотентность. Тоже все просто, если операция плоская. А если сломались чилдовые сущности после вставки родительских? Сможете поддержать трехуровневый маппер и правильно его накатить снова (и главное, для чего?)
Если вам нужна идемпотентность — то клиентская генерация идентификаторов как раз является единственным вариантом. Кстати, зачем тут вообще маппер?
Во-первых, подход с генерацией ключей в базе данных затрудняет или делает невозможным использование некоторых паттернов проектирования. Например, общий подход к идемпотентности заключается в создании идентификатора на клиенте и отправке его в запросе. Это позволяет легко устранять дублирование и гарантирует, что вы не вставите один и тот же объект дважды, так как легко обнаружить повторяющиеся запросы на вставку. Такой подход обычно невозможен с идентификаторами, сгенерированными базой данных.
Давайте не будем валить в одну кучу тёплое и мягкое. Есть ПОСТОЯННЫЙ идентификатор (с точки зрения хранящейся на сервере информации - идентификатор экземпляра сущности с неограниченным временем актуальности). Который отвечает за контроль уникальности. Есть ОДНОРАЗОВЫЙ идентификатор (с весьма ограниченным временем актуальности, для которого не возбраняется дублирование за пределами разумного периода времени). Который отвечает за одноразовость. Для первого - генерируем идентификатор на сервере и там же используем. Для второго - генерируем случайный идентификатор на клиенте (причём связанный с сеансом клиента, а не сеансом обращения клиента к серверу) и передаём серверу для контроля на предмет повторности выполнения. Так что такой подход невозможен с идентификаторами, сгенерированными базой данных потому, что базе данных в принципе не нужна генерация этого идентификатора. Её задача проверить обращение клиента на повторность - а для этого как раз нужен идентификатор от клиента, причём максимально вероятно обеспечивающий глобальную уникальность. Да, сервер может - но вот оно ему надо? да и затраты сервера на генерацию и передачу - не многовато ли за в общем никому не нужную унификацию этих идентификаторов?
Во-втроых, это усложняет код INSERT, поскольку вы должны убедиться, что возвращаете сгенерированные идентификаторы. EntityFramework под капотом назначает ID сущностям после вставки, но в случае с Dapper вам придётся делать это самим.
SQL-код INSERT не усложняется ни на копейку. И ему в принципе не надо в чём-то убеждаться - ну просто потому что СУБД (1) в принцип не может не сгенерировать идентификатор (2) в принципе не может сгенерировать повторно одно и то же значение. Да, возвращать ему тоже ничего не надо (ну за исключением случаев, когда текст запроса требует) - если клиенту потребуется, он спросит. А если какие-то там прослойки у себя под капотом содержат дополнительный код, который потенциально способен породить описанную проблему, или даже такого кода не содержат - то при чём тут СУБД-то? у неё как раз всё в порядке. Жалуйтесь на кривую прокладку.
Третья проблема возникает только в высоконагруженных приложениях — при вставке большого количества строк БД должна блокировать генератор идентификаторов чтобы избежать использования одного ID несколькими сущностями, это может стать узким местом в приложении.
Да, такая проблема частично есть. Но с ней вполне успешно борются, причём на уровне СУБД. Предзаказ идентификаторов, кэш идентификаторов... Кроме того, сравнивать по скорости/времени генерацию идентификатора, происходящую целиком и полностью в памяти сервера, и вставку записей, требующую достаточно медленных дисковых операций (да даже в случае SSD всё равно по сравнению с работой чисто в памяти - медленных, просто масштаб разницы не столь велик), надо с очень большой осторожностью.
Проблемы в репликации - да, тоже есть. Но тоже проблемы решаемые. А проблемы при масштабировании так и вовсе не проблемы. Особенно при наличии узла-координатора, пусть и динамического. Просто надо не вдруг в процессе эксплуатации обнаружить, что требуется описанное масштабирование и возникли проблемы. Для того же BIGINT раздавать диапазоны размером в INT можно до скончания века - и они не успеют кончиться.
Резюмируя - лично я так и остался не убеждённым в том, что GUID имеет ну хоть какое-то преимущество по сравнению с автогенерируемым INT / BIGINT значением.
Ну и, уж извините, вторая, экспериментальная, часть статьи оставила впечатление такое, что дано Вам утверждение, которое надо обосновать любой ценой - и Вы эту задачу решаете. Была тут недавно статья насчёт того, что играми со статистикой можно обосновать что угодно - ну очень похоже.
Просто надо не вдруг в процессе эксплуатации обнаружить, что требуется описанное масштабирование и возникли проблемы
)
Есть ПОСТОЯННЫЙ идентификатор (с точки зрения хранящейся на сервере информации — идентификатор экземпляра сущности с неограниченным временем актуальности). Который отвечает за контроль уникальности. Есть ОДНОРАЗОВЫЙ идентификатор (с весьма ограниченным временем актуальности, для которого не возбраняется дублирование за пределами разумного периода времени). Который отвечает за одноразовость. Для первого — генерируем идентификатор на сервере и там же используем. Для второго — генерируем случайный идентификатор на клиенте (причём связанный с сеансом клиента, а не сеансом обращения клиента к серверу) и передаём серверу для контроля на предмет повторности выполнения.
честно говоря, не понимаю, зачем нужны две сущности, если можно на клиенте сразу генерировать глобально-уникальный идентификатор
честно говоря, не понимаю, зачем нужны две сущности, если можно на клиенте сразу генерировать глобально-уникальный идентификатор
Вы не контролируете клиента. Вообще. Клиенту нельзя доверять вообще ни в чем. Особенно в таком важном вопросе как глобально уникальный идентификатор сущности.
Локальный для контроля данных именно этого клиента - не вопрос. Он сломав его только сам себе навредит. Нас это устраивает.
Про идемпотентность — да, есть решения с отдельным идентификатором типа requestId/operationId, которые требуют дополнительного механизма, и иногда могут усложнять композитную операцию, которую можно перевыполнить частично. В общем случае такой отдельный идентификатор полезен хотя бы потому, что не во всех запросах могут быть реальные идентификаторы, при этом такой подход ведь не исключает поддержку возможности повтора на уровне БД, когда Upsert должен корректно сработать при повторе вставки.
Про SQL insert — видимо, я тут как-то неточно сформулировал предложение. Вставка не усложниться, клиент, если надо, попросит, проблема тут в том, что клиенту обычно надо и он обычно просит, на столько, что ORM типа EF Core это "попросит" включает в запрос вставки, сразу делая insert + select. И в случае с микроорм и абстркатным REST клиент ожидает на вставку или сущность с идентификатором целиком, или сам идентификатор.
С последней частью статьи как-то хотелось подвести к тому, что решение нужно, библиотеки сущетсвуют, но вот нет сейчас чего-то "стандартного" из коробки или почти из коробки где-нибудь в либах EF Core, в BCL хотя бы известной community-библиотеки про RFC 4122. Чаще всего задачу решают ULIDом (для которого есть несколького надежных либ), но, учитывая некоторую хитрую "частично лексикографическую" сортировку ключей в SQL Server, это возможно только с сменой типа данных для хранения, что может оказаться очень значительным переходом.
Изначально я смотрел именно на NewId и надеялся проверить результаты на MySQL как более распространенную (субъективно по моим ощущениям) БД, но так и не нашёл нужного инструмента под неё, зато решил поискать другие реализации для генерации UUID version 1 и был сильно озадачен небольшим выбором.
Проблема Guid в том что у него родовая травма в виде различия строкового и бинарных представлений.
Вот тут https://github.com/dodopizza/primitives/blob/main/src/Dodo.Primitives/Uuid.cs есть реализация (за моим авторством), с API которое «идентично натуральному», но при этом содержит прямой порядк байт как в строковом, так и в бинарном представлении. Алгоритмы генерации можно сбоку написать какие угодно.
Вы создали что-то что называется стандартно, но при этом никто кроме вас не сможет получить нужные бинарные данные из строкового представления и наоборот никто кроме вас не сможет сказать как этот бинарный массив выглядит в виде строки. А вероятность того что у двух людей строковое представление бинарных данных не совпадет в экстремальной ситуации стремится к 100% (Мерфи не даст соврать)
Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте.
Вот ничему людей история не учит. LE и BE. Ну сколько можно по тем же граблям ходить?
Вы создали что-то что называется стандартно, но при этом никто кроме вас не сможет получить нужные бинарные данные из строкового представления и наоборот никто кроме вас не сможет сказать как этот бинарный массив выглядит в виде строки.
Я как раз это унифицировал. Подробности можно посмотреть в комментарии соседнего треда с @edo1h
А вероятность того что у двух людей строковое представление бинарных данных не совпадет в экстремальной ситуации стремится к 100% (Мерфи не даст соврать)
Да да, ровно поэтому я эту библиотеку и написал.
Вот ничему людей история не учит. LE и BE. Ну сколько можно по тем же граблям ходить?
Задавался этим вопросом при написании каждой строчки кода. Оно корнями ещё в WinApi вростает.
Вот тут https://github.com/dodopizza/primitives/blob/main/src/Dodo.Primitives/Uuid.cs есть реализация (за моим авторством), с API которое «идентично натуральному», но при этом содержит прямой порядк байт как в строковом, так и в бинарном представлении.
вы про этот guid?
Variant 2 UUIDs, historically used in Microsoft's COM/OLE libraries, use a mixed-endian format, whereby the first three components of the UUID are little-endian, and the last two are big-endian. For example, 00112233-4455-6677-c899-aabbccddeeff is encoded as the bytes 33 22 11 00 55 44 77 66 c8 99 aa bb cc dd ee ff.[11][12] See the section on Variants for details on why the '88' byte becomes 'c8' in Variant 2.
а он где-то её используется? сейчас перепроверил, select newid() в ms sql генерирует обычный uuid variant 1
Variant 1 UUIDs, nowadays the most common variant, are encoded in a big-endian format. For example, 00112233-4455-6677-8899-aabbccddeeff is encoded as the bytes 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
Вот такой незамысловатый пример
var input = new byte[]
{
0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77,
0x88, 0x99, 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF
};
var guid = new Guid(input);
byte* guidPtr = (byte*)&guid;
var real = string.Concat(Enumerable.Range(0, 15)
.Select(i => guidPtr[i])
.Select(x => x.ToString("X2")))
.ToUpper();
var bytesStr = string.Concat(guid.ToByteArray().Select(x => x.ToString("X2"))).ToUpper();
var toString = guid.ToString().Replace("-", "").ToUpper();realформируется путём последовательного чтения байт Guid'а
bytesStr формируется из ToByteArray()
toString формируется из вызова ToString()
подали на вход в виде массива байт00112233445566778899AABBCCDDEEFF и получаем такую картину:
real = 00112233445566778899AABBCCDDEE
bytesStr = 00112233445566778899AABBCCDDEEFF
toString = 33221100554477668899AABBCCDDEEFF
А теперь подадим на вход не массив байт, а строку
var input = "00112233445566778899AABBCCDDEEFF";
var guid = new Guid(input);
byte* guidPtr = (byte*)&guid;
var real = string.Concat(Enumerable.Range(0, 15)
.Select(i => guidPtr[i])
.Select(x => x.ToString("X2")))
.ToUpper();
var bytesStr = string.Concat(guid.ToByteArray().Select(x => x.ToString("X2"))).ToUpper();
var toString = guid.ToString().Replace("-", "").ToUpper();И теперь уже обратная картина
real = 33221100554477668899AABBCCDDEE
bytesStr = 33221100554477668899AABBCCDDEEFF
toString = 00112233445566778899AABBCCDDEEFF
То есть строковое и бинарное представление различаются. Корни эта проблема берёт из самой структуры System.Guid, реализаций конструкторов, методов парсинга и представления в виде строки. Ровно эту проблему я и решал, чтобы все 3 переменных были равны.
не верю, что для сишарпа нет готовых реализаций rfc 4122 и потребовалось изобретать велосипед
Теперь есть. Калькой послужили исходники самого Guid’а, только layout структуры правильный, как и все соответствующие методы. А способ сгенерировать 16 байт и положить в эту структуру, как я и писал выше - дело десятое.
P.S. - за велосипед обидно было. Там реализован весь API от System.Guid, полное покрытие тестами. По производительности оно эквивалентно System.Guid, причём как с точки зрения времени выполнения, так и с точки зрения аллоцируемой памяти. Проект с бенчмарками в том же солюшене, можете сами во всём убедиться.
Станиславский прям)
Но быстрая выборка соседних записей - это же был один из главных аргументов за отход от NEWID ( ) в сторону NEWSEQUENTIALID ( )! И тут вдруг : "Но на самом деле влияние фрагментации при чтении данных совсем не так велико, как может представляться — скорее можно назвать его незначительным. Вот пример замера производительности при чтении 10.000 записей и 100.000 записей в запросе."
Замеры на шпиндельном рэйде? Но уже 2022 год на дворе. Где в высоконагруженных системах крутятся шпинделя?
Проблема латчей (коротких блокировок на страницах в памяти) при так желаемых "плотных" вставках с нескольких потоков одновременно,- кажется у Дм.Короткевича был семинар на эту тему,- как раз для высоконагруженных систем.
Ну и это, мне кажется стоит определиться,- мы пилим реально "высоконагруженную систему" или всё-таки делаем масштабируемое решение строя для таблиц primary key clustered на uniqueidentifier .
по первому пункту ИМХО важнее случай когда таблица заметно больше кэша.
зачастую более активные обращения идут к последним данным, при неудачной генерации uuid после перестроения кластерного индекса данные окажутся перемешанными, то есть у нас не будет горячей области.
зачастую более активные обращения идут к последним данным,
Но в случае нормализованной модели бд это (ИМХО) не сильно применимо по отношению к справочникам (объём коих может превышать объём центральных таблиц). А при поиске в справочных/нормативных/... базах - вообще мрак ;)
В случае секционирования таблицы, слабо представляю себе как это сделать по кластерному индексу на GUID-ах (хотя это и не является целью,- как правило).
... надо будет как-нибудь придумать тест и "погонять чертей" на IM-OLTP в плане "GUID-индекс V Bigint+Bigint-индекс" ...
не сильно применимо по отношению к справочникам (объём коих может превышать объём центральных таблиц)
ну тут уже, как говорится, против лома нет приёма. если у нас в справочниках нет горячей области, помещающейся в память, то всё плохо.
В случае секционирования таблицы, слабо представляю себе как это сделать по кластерному индексу на GUID-ах (хотя это и не является целью,- как правило)
для таких задач как раз и придумывают упорядоченные uuid вроде описываемых в этой статье (а лучше ulid или планируемый uuidv7).
В случае секционирования таблицы, слабо представляю себе как это сделать по кластерному индексу на GUID-ах (хотя это и не является целью,- как правило)
для таких задач как раз и придумывают упорядоченные uuid вроде описываемых в этой статье (а лучше ulid или планируемый uuidv7).
Согласен. Но с оговоркой,- когда секционирование строится согласно порядку поступления данных,- тогда данные будут расти "в хвост" (например), а при слиянии баз записи, близкие по времени появления, будут группироваться рядом.
Если отдавать генерацию на сторону клиента, то это порождает сценарии, которые сложно контролировать.
Требуется как-то заставить всех внешних пользователей вашего API применять строго определённую схему генерации условно-последовательных GUID, которые будут наилучшим образом подходить для конкретного используемого хранилища. Например, у MSSQL свой подход к сортировке кластеризованных PK типа 'uniqueidentifier' (по части байтов). У другой БД может быть другой подход. А если разные сущности хранятся в хранилищах разного типа, то для каждой сущности придётся описывать свой тип генерации ID. А если использовать полностью случайные GUID, то это может порождать описанные в начале статьи проблемы с производительностью хранилища.
При этом сервер не имеет возможности как-то контролировать корректность генерации, т.е. мы вынуждены верить клиенту. А если такую возможность и реализовать (под конкретный тип хранилища), то она всё равно будет работать с определёнными допущениями, т.к. для генерации последовательного ID в любом случае придётся применять системное время на клиентской машине, а оно (хотя, сейчас такое редко встречается), вполне может отставать/опережать время сервера на какую-то дельту. Ну и это так же дополнительно породит для клиентов весьма специфичную ошибку "плохой ID сущности".
Смена хранилища (целиком, или для отдельной группы сущностей) - необходимость во всех внешних клиентах API менять механизм генерации ID этих сущностей.
GUID часто случайно совпадает, например в двух разных базах 1С в случае случайного совпадения GUID обмен данными будет(бывает часто) неправильным. Может лучше вообще никогда не использовать GUID поэтому ?
Если надо и ID от сервера, и идемпотентность, то почему бы не отделить получение ID от создания объекта?
Мне сразу Хабр приходит на ум. Мы сначала создаем черновик статьи. При этом сервер назначает ему ID. Это не идемпотентно, но лишний черновик - не проблема. Он может вечно жить своей тайной жизнью и никому не мешать. А на этапе публикации у нас уже есть ID.
Хотя такой забытый черновик всё же может вызвать некоторые сложности, если в таблице есть поля, которые FOREIGN KEY и при этом NOT NULL
Эффективная генерация сортируемых GUID для первичных ключей БД на клиенте