Записи реальных собесов и полезную инфу для подготовки можно найти на бусти boosty.to/vanyaio Тренажер по Go для подготовки к собесу: stepik.org/a/206788 Задачи на горутины и каналы Go для собесов: stepik.org/a/207625 Офф. дока по теме: www.postgresql.org/docs/current/transaction-iso.html www.postgresql.org/docs/current/explicit-locking.html Много хороших примеров в книжках: postgrespro.ru/education/books/internals глава про изоляцию Книжка с кабаном - designing data-intensive applications - глава 7 про транзакции
Чувак прямо в двух одновременно открытых терминалах с разными транзакциями в реальном времени показывает, что происходит в одной транзакции, и что в другой. Красавчик, мне именно такого видоса не хватало, чтобы до конца понять эту тему!
Ты очень крутой, спасибо. Читал книжку с кабанчиком, и твоё видео гораздо нагляднее, особенно с примером про докторов. Счастья и здоровья тебе на всю нафиг жизнь ❤
В этом видео понятно, для примера баланс как число в таблице хранится. Когда храним финансовую информацию более правильно ее представить в виде истории изменения баланса. То есть приход 100 рублей, списание 5, приход 2. А баланс получать (рассчитывать) как сумму +100 - 5 + 2. Меньше вероятность запортить данные, чем хранить просто как значение в ячейке. И в случае проблем, легче разобраться в причинах и восстановить.
Супер! Спасибо за такую качественную инфомрацию! Я тоже помню как долго разбирался с этим, но никогда наглядно не демонстрировал таким образом! Молодец автор!
Отличный материал, только в конце про SERIALIZABLE я бы добавил, что он конкретно так лочит таблицу, из-за чего падает производительность, но зато все транзакции идут последовательно.
Не все так просто. Цитата: Для полной гарантии сериализуемости в Postgres Pro применяются предикатные блокировки, то есть блокировки, позволяющие определить, когда запись могла бы повлиять на результат предыдущего чтения параллельной транзакции, если бы эта запись выполнялась сначала. В Postgres Pro эти блокировки не приводят к фактическим блокировкам данных и, следовательно, никоим образом не могут повлечь взаимоблокировки транзакций. Они помогают выявить и отметить зависимости между параллельными транзакциями уровня Serializable, которые в определённых сочетаниях могут приводить к аномалиям сериализации. Транзакции Read Committed или Repeatable Read для обеспечения целостности данных, напротив, должны либо блокировать таблицы целиком, что помешает пользователям обращаться к этим таблицам, либо применять SELECT FOR UPDATE или SELECT FOR SHARE, что не только заблокирует другие транзакции, но и создаст дополнительную нагрузку на диск.
Годный осмотр транзакций. Контент зайдет для всех кто пишет бек, неважно на каком языке. Особенно круто что прошёлся по локам, кстати советую ещё зрителям посмотреть какой то более конкретный пример с локами, например как обновляется одна строка в бд при конкурентном доступе от Реста и от Брокера. И почему в такой ситуации круто подходит Лок а не другие способы по типу siriazible
Попробовала сделать запрос с serializable в другой транзакции параллельно но для другого room_id и все равно постгрес ругается на read/write зависимость
"Третий день пишу видос, сам не рад, что начал" - здесь улыбнулся. Делаешь ролик на 5 минут - 80 тыщ просмотров, три дня - 300 просмотров и все от бабушки. Посмотрел ролик 3 раза, чтобы тебя поддержать. Хорошее видео.
лост апдейт попадает под класс неповторяющегося чтения? Ведь когда делается апдейт, значение читается, над ним производится операция, новое значение записывается
Не понял в seriaizable , ты говоришь что может даже не существует строки для блокировки. Но утаблицы есть room id (остальные понятно nil), и по этой же room id оно понимает что что-то происходит и включает блокировку. То есть это происходит именно по всей колонке, тогда можно сказать что вся таблица блокируется? Или если действительно пустая страница, я создам в нескольких окнах новые данные, как распрнделяться id новых записей? Спасибо за видео!
может я не прав, но как мне кажется что для ситуации на 21:52 не нужна блокировка совсем, так как по логике прога увидит сразу что остался один врач, и роллбекнет транзакцию
Самое смешное что решать эти проблемы требуется только в определенных предметных областях в программировании. А спрашивают везде, даже когда сами все используют по умолчанию настройки. Не только лишь всем понадобится решать такие проблемы, а ограниченному кругу разработчиков. Тоже самое касается про репликацию и шардировние, никто не реализовывал, но спрашивает
Примеры транзакций хорошие, и тема классная, спасибо! Хотел бы немного дать рекомендаций, что можно тут улучшить. 1) Хотелось бы с первых минут знать, на примере какой СУБД рассматриваются транзакции, прежде чем приступать к примерам запросов. 2) Как-то очень абстрактно рассказываешь, не расскрывая деталей. Пишу после просмотра первых 5 минут. Про изолированность транзакций было сказано что-то вроде "транзакции с одного терминала не видят транзакции с другого терминала". Звучит как-то непонятно. А что означает тут слово "терминал"? Мне кажется, более приближенный к практике пример - это не 2 терминала, открытые на одной машине в vscode, а 2 пользователя / приложения, подключённые к одной базе. Понимаю, что контент может быть для тех, кто только начинает изучать эту тему, но хотелось бы, чтобы информация подавалась чуть более подробно, если это возможно. Возможно дальше и раскроется тема. Если раскроется - удалю коммент Без негатива, успехов в развитии канала
Чувак если он такие элементарные вещи будет еще объяснять ролик будет в два раза дольше. Терминал он из него пишет запрос к бд, как бы отдельная сессия с бд создается , получается две параллельные сессии пользователя субд. База данных у него postgresql
7:26 - а в чём тут парадокс? Разве транзакция это не инструкция, описывающая что нужно сделать с актуальными данными базы? Я просто новичёк, не знаю нюансов ещё. Или после begin предполагается, что мы должны работать с изначальным состоянием базы, не беря во внимание последующие её апдейты? Просто в примере вроде всё логично: после первой транзакции у Alice на балансе 2, а у Bob 998. Вторая транзакция выполняет инструкцию установить для Alice значение 998, а для Bob прибавить 2 и прибавляет к его текущему значению, которое равно 998.
А почему актуальными? Коммит второй транзакции не произошел еще. Апдейт бы брался во внимание, если бы изменения эти были в одной транзакции, а не в разных. В postgresql в момент открытия команды begin при уровне repeatable read, строится так называемый "снимок данных". С помощью этого снимка в postgresql как раз и избегается аномалия неповторяющегося чтения.
@@pyramidhead9692 когда идёт 3-й апдейт, после коммита, там лежат актуальные данные у Alice 2 рубля!!! И не верно ей ставить просто 998! тут даже без транзакций будет ошибка
Иван, спасибо за видео, но его нужно переснимать. В процессе просмотра было несколько неточностей. Одна из них кем-то упоминалась в коментах, что мол read uncommitted это не аномалия, а название изоляции. Про другие не вспомню сейчас, т.к. в несколько заходов смотрю видео. Причиной для того, чтобы перезаписать видос, на мой взгляд, является то, что на 15:10 ты говоришь что изоляция repeatable read избавляет от фантомного чтения. Это не так. Repeatable read имеет самое кричащее название (имхо) и гарантирует (внезапно) то, что чтение строки будет повторятся (но не количество строк). Фантомное чтение - это аномалия которая невозможна только на Serializable уровне. Т.е. если на repeatable read 2-ая транзакция изменит данные в рамках одной строки, то ок (1-ая транзакция их не увидит при повторном чтении, аномалия с неповторяющимся чтением не воспроизводится). Но если 2-ая транзакция изменит количество строк (обновит/удалит), то 1-ая транзакция (при повторном выполнении того же самого селекта) должна увидеть добавленные/удаленные строки. Это и есть фантомное чтение, которое не обеспечивается repeatable read-ом.
Про dirty read / read uncommitted - абсолютно минорный момент как назвать ситуацию, что вы читаете незакоммиченные данные. Коммента достаточно, что я не общепринятый термин случайно сказал.
@@zicksu2142так в итоге что? Повт чтение устраняет аномалию фантомного чтения, просто мне тоже казалось что это только на уровне serializable можно избежать
@@Parsifal-j4j Ситуация интересная) В документации pg сказано, что фантомное чтение в принципе возможно на уровне repeatable read, но не в случае с PG. Дословно: "Allowed, but not in PG". Дальше отсебятина. Получается, что академически изоляция repeatable read не защищает от фантомного чтения, но не в случае с PG (хотят тут тоже есть нюанс, который ниже опишу). Могу ошибаться, но видимо за счет MVCC подхода (когда каждая транзакция до начала создает свой снэпшот данных и с ним работает) в PG как раз достигается отсутствие фантомов при повторном чтении. Что за нюанс? - снэпшот данных создается для каждой транзакции при старте и он попросту не видит того, что может случиться с данными в БД вне этого снэпшота пока работает текущая транзакция. Если первая транзакция работает со своим снэпшотом, а вторая транзакция в это время удалила строку (и закомитилась, а эта удаленная строка вошла в состав снэпшота первой транзакции), то в реальной БД этой строки нет, а в снэпшоте первой транзакции она есть и при повторном чтении в этой первой транзакции будет возвращен тот же результат, а значит фантомного чтения нет. Т.е. получается, что отсутствие фантомов обеспечивается в РАМКАХ ОДНОЙ ТРАНЗАКЦИИ ПРИ ПОВТОРНОМ ВЫПОЛНЕНИИ ЗАПРОСА. Т.е. отсутствие фантомов не абсолютное - в снэпшоте первой транзакции строка есть, а в реальной БД ее нет. И вероятно, когда первая транзакция будет комитится, то она пофейлится, т.к. PG увидит что данные из ее снэпшота содержат то, что уже удалено. И тогда придется делать ретрай для первой транзакции. Еще раз - это исключительное мое понимание и вольная трактовка инфы из доки. Могу быть не прав.
Может тогда по умолчанию использовать уровень изоляции SERIALIZIBLE? Для чего нам тогда другие уровни изоляций, если они не дают гарантированной защиты от аномалий?
Есть уровни изоляции и аномалии при них. Чем ниже уровень - тем больше аномалий, но и производительность системы выше. Ты, как разработчик, должен решить, какого уровня будет достаточно для твоей системы, без избыточной изоляции. При уровне SERIALIZIBLE говорить о параллелизме не приходится, это прям из названия следует - транзакции просто выполняются последовательно по очереди.
Бывает, когда нам не нужны гарантии выполнения транзакции. А работу нужно ускорить. Например, логи записываешь. Ну не страшно, если что-то там не зафиксируется и на графике подведения итогов будет вместо 159384 записей 159383. Общей картины это не меняет. А записи частые и стоит побыстрее заталкивать. Вот и придуманы способы.
@@VitaliyZlobin Serializable это не про реализацию, а про результат. Более того, уже давно есть реализации serializable которые по мере возможности выполняют транзакции параллельно.
@@zakharka3938 алгоритм с вложенным циклом может выполниться за O(n), однако такой алгоритм имеет сложность O(n^2). Я бы сильно не полагался, на то что там что-то параллельно может выполниться - это подкапотная оптимизация СУБД, а не твоих процессов. И где я писал, что serializable про реализацию?
примеры не очень, нафига жестко ставить баланс на счету? не честно получается, надо было с одного вычитать величину , а на другом туже прибавлять, тогда хоть и тоже все сломалось, но так честнее
"на уровне репитабл рид бывает только два типа аномалий" - а как же фантомы? несогласованное чтение разве не попадает под класс фантомы? когда доктор боб хочет уйти он видит двоих на дежурстве. А когда снимается с дежурства, делая апдейт уже видит неявно одного себя. Алиса ведь себя уже закоммитила
Все это нужно в очень редких кейсах, но в рф любят почти на каждом собесе поумничать. В реальном мире в 99% случаев это не нужно, так как все решается настройками по-умолчанию. Когда действительно сталкиваешься, то читаешь доку, вспоминаешь, и потом снова забываешь. Это как дедовщина в армии: видать одного замучили на собесе, он поклялся все это выучить, и потом других мучить ))) Был и у меня на работе такой умник. Когда его спрашивали свои же, зачем ты это все спрашиваешь? Он отвечал, что ему интересно понаблюдать как человек мучается и выкручивается. Редкий говнюк был, видать в школе хорошо огребал. Когда же возникали проблемы на бэке, сам же лез в доку и там вкуривал как в той или иной БД транзакционность реализована, какие уровни изоляции поддерживаются и т.д. Ну а так, хорошо всё показал. Молодец!
Я считаю что это база и ее нужно знать, может быть на Джуна достаточно просто уметь писать crud запросы но если ты хочешь больше зарабатывать то ты должен это знать
![Seungmin "그렇게, 천천히, 우리(As we are)" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/kAzmhLHePqU/mqdefault.jpg)
Записи реальных собесов и полезную инфу для подготовки можно найти на бусти boosty.to/vanyaio
Тренажер по Go для подготовки к собесу: stepik.org/a/206788
Задачи на горутины и каналы Go для собесов: stepik.org/a/207625
Офф. дока по теме:
www.postgresql.org/docs/current/transaction-iso.html
www.postgresql.org/docs/current/explicit-locking.html
Много хороших примеров в книжках:
postgrespro.ru/education/books/internals глава про изоляцию
Книжка с кабаном - designing data-intensive applications - глава 7 про транзакции
Read uncommitted - это не аномалия, а уровень изоляция. Dirty read - это аномалия.
Чувак прямо в двух одновременно открытых терминалах с разными транзакциями в реальном времени показывает, что происходит в одной транзакции, и что в другой.
Красавчик, мне именно такого видоса не хватало, чтобы до конца понять эту тему!
Ты очень крутой, спасибо. Читал книжку с кабанчиком, и твоё видео гораздо нагляднее, особенно с примером про докторов.
Счастья и здоровья тебе на всю нафиг жизнь ❤
В этом видео понятно, для примера баланс как число в таблице хранится. Когда храним финансовую информацию более правильно ее представить в виде истории изменения баланса. То есть приход 100 рублей, списание 5, приход 2. А баланс получать (рассчитывать) как сумму +100 - 5 + 2. Меньше вероятность запортить данные, чем хранить просто как значение в ячейке. И в случае проблем, легче разобраться в причинах и восстановить.
я не сталкивался, но делал бы 2 таблицы - одна с логом, другая с агрегирующим значением по этому логу
Супер! Спасибо за такую качественную инфомрацию! Я тоже помню как долго разбирался с этим, но никогда наглядно не демонстрировал таким образом!
Молодец автор!
Отличный материал, только в конце про SERIALIZABLE я бы добавил, что он конкретно так лочит таблицу, из-за чего падает производительность, но зато все транзакции идут последовательно.
Не все так просто.
Цитата:
Для полной гарантии сериализуемости в Postgres Pro применяются предикатные блокировки, то есть блокировки, позволяющие определить, когда запись могла бы повлиять на результат предыдущего чтения параллельной транзакции, если бы эта запись выполнялась сначала. В Postgres Pro эти блокировки не приводят к фактическим блокировкам данных и, следовательно, никоим образом не могут повлечь взаимоблокировки транзакций. Они помогают выявить и отметить зависимости между параллельными транзакциями уровня Serializable, которые в определённых сочетаниях могут приводить к аномалиям сериализации. Транзакции Read Committed или Repeatable Read для обеспечения целостности данных, напротив, должны либо блокировать таблицы целиком, что помешает пользователям обращаться к этим таблицам, либо применять SELECT FOR UPDATE или SELECT FOR SHARE, что не только заблокирует другие транзакции, но и создаст дополнительную нагрузку на диск.
Про Serializable для меня вообще было открытием. Спасибо!
Очень классный видос, пересмотрел пол ютуба перед тем, как найти конфетку)
Это одно из самых полезных видео по уровням изоляции транзакций. Большое спасибо! 🎉
Лайк за Хана. Какой же кайф
Годный осмотр транзакций.
Контент зайдет для всех кто пишет бек, неважно на каком языке.
Особенно круто что прошёлся по локам, кстати советую ещё зрителям посмотреть какой то более конкретный пример с локами, например как обновляется одна строка в бд при конкурентном доступе от Реста и от Брокера. И почему в такой ситуации круто подходит Лок а не другие способы по типу siriazible
Красавчик! Все по полкам раскидал, были бы такие преподы в универах
Ух огромное спасибо) отличный ролик. очень доступно объяснил
Супер! Большое спасибо! Очень понятно с отличными наглядными примерами!
Спасибо, интересно. Единственное не рассказал как базу на работе локнул 😅
Отлично рассказал. Спасибо.
Спасибо большое, все кратко и по делу! Восхитительно!
Спасибо! Очень классно и наглядно показано
Как же жить стало проще когда узнал про SERIALIZABLE ISOLATION
Успехов ))
Скажите а версионирование строки под капотом по умолчанию идет ? А оптимистический и пессимистический режимы есть такое?
Пересмотрел дважды, пробежался по всем примерам руками, бро, обожаю тебя😅
Это лучший материал про уровни изоляции и аномалии! Респект!
Идеальное видео с качественными примерами. Красавчик!
Спасибо за классный контент! Твои 3 дня потраченные на видео прошли не зря)
Спасибо!
Весьма полезно.
Классный канал:)
Крутой тутор! Случайно наткнулся на канал, коммент для продвижения)
Толково изложено! В MySQL лост апдейты тоже (как и в постгресс) невозможны на уровне "repeatable read" ?
Попробовала сделать запрос с serializable в другой транзакции параллельно но для другого room_id и все равно постгрес ругается на read/write зависимость
Топовое видео, спасибо большое
"Третий день пишу видос, сам не рад, что начал" - здесь улыбнулся. Делаешь ролик на 5 минут - 80 тыщ просмотров, три дня - 300 просмотров и все от бабушки. Посмотрел ролик 3 раза, чтобы тебя поддержать. Хорошее видео.
Классно, спасибо!
Очень годно, продолжай в том же духе!
услышал подкрадули, подписался)
Иван, поясни пожалуйста про ретрай запросов? Можешь раскрыть тему, как это делается?
Спасибо тебе, Кристиан Бэйл
Это база(с) Спасибо. Исчерпывающий гайд.
лост апдейт попадает под класс неповторяющегося чтения? Ведь когда делается апдейт, значение читается, над ним производится операция, новое значение записывается
это лучшее объяснение
Полезное видео. Лайк за видос.
В последнем примере с serializable можно поставить блокировку на строку из таблицы room по room_id и все будет ок без serializable. Или я не прав?
В примере про случай когда блокировки не спасают: если там установить уровень read commited, то вроде как проблема решится. Или нет?
Не понял в seriaizable , ты говоришь что может даже не существует строки для блокировки. Но утаблицы есть room id (остальные понятно nil), и по этой же room id оно понимает что что-то происходит и включает блокировку. То есть это происходит именно по всей колонке, тогда можно сказать что вся таблица блокируется? Или если действительно пустая страница, я создам в нескольких окнах новые данные, как распрнделяться id новых записей?
Спасибо за видео!
шикарный пример
может я не прав, но как мне кажется что для ситуации на 21:52 не нужна блокировка совсем, так как по логике прога увидит сразу что остался один врач, и роллбекнет транзакцию
Очень интересно и полезно, спасибо большое!!!
Самое смешное что решать эти проблемы требуется только в определенных предметных областях в программировании. А спрашивают везде, даже когда сами все используют по умолчанию настройки. Не только лишь всем понадобится решать такие проблемы, а ограниченному кругу разработчиков. Тоже самое касается про репликацию и шардировние, никто не реализовывал, но спрашивает
Причем это не только про базу данных.
очень полезный видос, спасибо!
Примеры транзакций хорошие, и тема классная, спасибо! Хотел бы немного дать рекомендаций, что можно тут улучшить.
1) Хотелось бы с первых минут знать, на примере какой СУБД рассматриваются транзакции, прежде чем приступать к примерам запросов.
2) Как-то очень абстрактно рассказываешь, не расскрывая деталей. Пишу после просмотра первых 5 минут. Про изолированность транзакций было сказано что-то вроде "транзакции с одного терминала не видят транзакции с другого терминала". Звучит как-то непонятно. А что означает тут слово "терминал"? Мне кажется, более приближенный к практике пример - это не 2 терминала, открытые на одной машине в vscode, а 2 пользователя / приложения, подключённые к одной базе. Понимаю, что контент может быть для тех, кто только начинает изучать эту тему, но хотелось бы, чтобы информация подавалась чуть более подробно, если это возможно. Возможно дальше и раскроется тема. Если раскроется - удалю коммент
Без негатива, успехов в развитии канала
Чувак если он такие элементарные вещи будет еще объяснять ролик будет в два раза дольше. Терминал он из него пишет запрос к бд, как бы отдельная сессия с бд создается , получается две параллельные сессии пользователя субд. База данных у него postgresql
И что делать, когда транзакция зависла из-за другой неоконченной транзакции?
Есть настройка у постгреса скок максимум можно висеть, если время превысится - ролбекнет
7:26 - а в чём тут парадокс? Разве транзакция это не инструкция, описывающая что нужно сделать с актуальными данными базы? Я просто новичёк, не знаю нюансов ещё. Или после begin предполагается, что мы должны работать с изначальным состоянием базы, не беря во внимание последующие её апдейты?
Просто в примере вроде всё логично: после первой транзакции у Alice на балансе 2, а у Bob 998. Вторая транзакция выполняет инструкцию установить для Alice значение 998, а для Bob прибавить 2 и прибавляет к его текущему значению, которое равно 998.
А почему актуальными? Коммит второй транзакции не произошел еще. Апдейт бы брался во внимание, если бы изменения эти были в одной транзакции, а не в разных. В postgresql в момент открытия команды begin при уровне repeatable read, строится так называемый "снимок данных". С помощью этого снимка в postgresql как раз и избегается аномалия неповторяющегося чтения.
@@pyramidhead9692 когда идёт 3-й апдейт, после коммита, там лежат актуальные данные у Alice 2 рубля!!! И не верно ей ставить просто 998! тут даже без транзакций будет ошибка
Лайк за Хана Замая!!!!
Я один против мира - Александр Гоголев
Все видео, я хотел дать тебе баночку энергетика)
Иван, спасибо за видео, но его нужно переснимать.
В процессе просмотра было несколько неточностей. Одна из них кем-то упоминалась в коментах, что мол read uncommitted это не аномалия, а название изоляции. Про другие не вспомню сейчас, т.к. в несколько заходов смотрю видео.
Причиной для того, чтобы перезаписать видос, на мой взгляд, является то, что на 15:10 ты говоришь что изоляция repeatable read избавляет от фантомного чтения. Это не так. Repeatable read имеет самое кричащее название (имхо) и гарантирует (внезапно) то, что чтение строки будет повторятся (но не количество строк). Фантомное чтение - это аномалия которая невозможна только на Serializable уровне.
Т.е. если на repeatable read 2-ая транзакция изменит данные в рамках одной строки, то ок (1-ая транзакция их не увидит при повторном чтении, аномалия с неповторяющимся чтением не воспроизводится). Но если 2-ая транзакция изменит количество строк (обновит/удалит), то 1-ая транзакция (при повторном выполнении того же самого селекта) должна увидеть добавленные/удаленные строки. Это и есть фантомное чтение, которое не обеспечивается repeatable read-ом.
Откуда эта инфа? Офф дока постгреса про phantom read на уровне Repeatable read - Allowed, but not in PG
Про dirty read / read uncommitted - абсолютно минорный момент как назвать ситуацию, что вы читаете незакоммиченные данные. Коммента достаточно, что я не общепринятый термин случайно сказал.
@@ivangolang да, верно. Прошу прощения. Как-то упустил что видос исключительно про pg, думал в целом так сказать академический подход
@@zicksu2142так в итоге что? Повт чтение устраняет аномалию фантомного чтения, просто мне тоже казалось что это только на уровне serializable можно избежать
@@Parsifal-j4j Ситуация интересная) В документации pg сказано, что фантомное чтение в принципе возможно на уровне repeatable read, но не в случае с PG. Дословно: "Allowed, but not in PG". Дальше отсебятина. Получается, что академически изоляция repeatable read не защищает от фантомного чтения, но не в случае с PG (хотят тут тоже есть нюанс, который ниже опишу). Могу ошибаться, но видимо за счет MVCC подхода (когда каждая транзакция до начала создает свой снэпшот данных и с ним работает) в PG как раз достигается отсутствие фантомов при повторном чтении. Что за нюанс? - снэпшот данных создается для каждой транзакции при старте и он попросту не видит того, что может случиться с данными в БД вне этого снэпшота пока работает текущая транзакция. Если первая транзакция работает со своим снэпшотом, а вторая транзакция в это время удалила строку (и закомитилась, а эта удаленная строка вошла в состав снэпшота первой транзакции), то в реальной БД этой строки нет, а в снэпшоте первой транзакции она есть и при повторном чтении в этой первой транзакции будет возвращен тот же результат, а значит фантомного чтения нет. Т.е. получается, что отсутствие фантомов обеспечивается в РАМКАХ ОДНОЙ ТРАНЗАКЦИИ ПРИ ПОВТОРНОМ ВЫПОЛНЕНИИ ЗАПРОСА. Т.е. отсутствие фантомов не абсолютное - в снэпшоте первой транзакции строка есть, а в реальной БД ее нет. И вероятно, когда первая транзакция будет комитится, то она пофейлится, т.к. PG увидит что данные из ее снэпшота содержат то, что уже удалено. И тогда придется делать ретрай для первой транзакции. Еще раз - это исключительное мое понимание и вольная трактовка инфы из доки. Могу быть не прав.
Снимай видосы, интересный материал
Race condition?
9:29 Обновил всем баланс в 0 что не так?
Может тогда по умолчанию использовать уровень изоляции SERIALIZIBLE? Для чего нам тогда другие уровни изоляций, если они не дают гарантированной защиты от аномалий?
Есть уровни изоляции и аномалии при них.
Чем ниже уровень - тем больше аномалий, но и производительность системы выше. Ты, как разработчик, должен решить, какого уровня будет достаточно для твоей системы, без избыточной изоляции.
При уровне SERIALIZIBLE говорить о параллелизме не приходится, это прям из названия следует - транзакции просто выполняются последовательно по очереди.
Бывает, когда нам не нужны гарантии выполнения транзакции. А работу нужно ускорить. Например, логи записываешь. Ну не страшно, если что-то там не зафиксируется и на графике подведения итогов будет вместо 159384 записей 159383. Общей картины это не меняет. А записи частые и стоит побыстрее заталкивать. Вот и придуманы способы.
@@VitaliyZlobin Serializable это не про реализацию, а про результат. Более того, уже давно есть реализации serializable которые по мере возможности выполняют транзакции параллельно.
@@zakharka3938 алгоритм с вложенным циклом может выполниться за O(n), однако такой алгоритм имеет сложность O(n^2).
Я бы сильно не полагался, на то что там что-то параллельно может выполниться - это подкапотная оптимизация СУБД, а не твоих процессов.
И где я писал, что serializable про реализацию?
Лайков за Замая...
Bro, snimau svou treugolky. Spasibo
примеры не очень, нафига жестко ставить баланс на счету? не честно получается, надо было с одного вычитать величину , а на другом туже прибавлять, тогда хоть и тоже все сломалось, но так честнее
А можно вернуть кринжовую музыку? Это единственное, что мне близко из темы твоего канала😘😘😘😘😘
Для чего впихивать в одну транзакцию две одинаковых операции на чтение, которые потенциально могут иметь разный результат?
Первое, что пришло в голову - по разному обрабатываем данные, можем применить разную функцию при двух одинаковых чтениях одних и тех же данных
Топ контент!
"на уровне репитабл рид бывает только два типа аномалий" - а как же фантомы? несогласованное чтение разве не попадает под класс фантомы?
когда доктор боб хочет уйти он видит двоих на дежурстве. А когда снимается с дежурства, делая апдейт уже видит неявно одного себя. Алиса ведь себя уже закоммитила
Все это нужно в очень редких кейсах, но в рф любят почти на каждом собесе поумничать. В реальном мире в 99% случаев это не нужно, так как все решается настройками по-умолчанию. Когда действительно сталкиваешься, то читаешь доку, вспоминаешь, и потом снова забываешь. Это как дедовщина в армии: видать одного замучили на собесе, он поклялся все это выучить, и потом других мучить )))
Был и у меня на работе такой умник. Когда его спрашивали свои же, зачем ты это все спрашиваешь? Он отвечал, что ему интересно понаблюдать как человек мучается и выкручивается. Редкий говнюк был, видать в школе хорошо огребал. Когда же возникали проблемы на бэке, сам же лез в доку и там вкуривал как в той или иной БД транзакционность реализована, какие уровни изоляции поддерживаются и т.д.
Ну а так, хорошо всё показал. Молодец!
Я считаю что это база и ее нужно знать, может быть на Джуна достаточно просто уметь писать crud запросы но если ты хочешь больше зарабатывать то ты должен это знать
нравятся твои видосы, но тут ты прям уже погас к середине видоса, похоже и правда с похмела)
бросай ты это дело, а видосы снимать продолжай)
ЗАМАЙ 2024
лайк с нулевой
Транзакции Антихайпа
Привет горшочку!
Да ббббббддддддддддддджжддддддддддддддщджддщдддддддддддддджждщддббббббббббббдддббщддлоо научить ь. Юююююжжюююэээ!э!.!
Ь. Ьььььллллллллддллл. Ьььььлллллббббббэ
клад!
блин, зря сделал += 2, лучше бы везде сделал +998 -998 а то код странно смотрится((
Скажите а версионирование строки под капотом по умолчанию идет ? А оптимистический и пессимистический режимы есть такое?