Записи реальных собесов и полезную инфу для подготовки можно найти на бусти 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
Примеры транзакций хорошие, и тема классная, спасибо! Хотел бы немного дать рекомендаций, что можно тут улучшить. 1) Хотелось бы с первых минут знать, на примере какой СУБД рассматриваются транзакции, прежде чем приступать к примерам запросов. 2) Как-то очень абстрактно рассказываешь, не расскрывая деталей. Пишу после просмотра первых 5 минут. Про изолированность транзакций было сказано что-то вроде "транзакции с одного терминала не видят транзакции с другого терминала". Звучит как-то непонятно. А что означает тут слово "терминал"? Мне кажется, более приближенный к практике пример - это не 2 терминала, открытые на одной машине в vscode, а 2 пользователя / приложения, подключённые к одной базе. Понимаю, что контент может быть для тех, кто только начинает изучать эту тему, но хотелось бы, чтобы информация подавалась чуть более подробно, если это возможно. Возможно дальше и раскроется тема. Если раскроется - удалю коммент Без негатива, успехов в развитии канала
Самое смешное что решать эти проблемы требуется только в определенных предметных областях в программировании. А спрашивают везде, даже когда сами все используют по умолчанию настройки. Не только лишь всем понадобится решать такие проблемы, а ограниченному кругу разработчиков. Тоже самое касается про репликацию и шардировние, никто не реализовывал, но спрашивает
Попробовала сделать запрос с serializable в другой транзакции параллельно но для другого room_id и все равно постгрес ругается на read/write зависимость
может я не прав, но как мне кажется что для ситуации на 21:52 не нужна блокировка совсем, так как по логике прога увидит сразу что остался один врач, и роллбекнет транзакцию
лост апдейт попадает под класс неповторяющегося чтения? Ведь когда делается апдейт, значение читается, над ним производится операция, новое значение записывается
Не понял в seriaizable , ты говоришь что может даже не существует строки для блокировки. Но утаблицы есть room id (остальные понятно nil), и по этой же room id оно понимает что что-то происходит и включает блокировку. То есть это происходит именно по всей колонке, тогда можно сказать что вся таблица блокируется? Или если действительно пустая страница, я создам в нескольких окнах новые данные, как распрнделяться id новых записей? Спасибо за видео!
"Третий день пишу видос, сам не рад, что начал" - здесь улыбнулся. Делаешь ролик на 5 минут - 80 тыщ просмотров, три дня - 300 просмотров и все от бабушки. Посмотрел ролик 3 раза, чтобы тебя поддержать. Хорошее видео.
примеры не очень, нафига жестко ставить баланс на счету? не честно получается, надо было с одного вычитать величину , а на другом туже прибавлять, тогда хоть и тоже все сломалось, но так честнее
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 - абсолютно минорный момент как назвать ситуацию, что вы читаете незакоммиченные данные. Коммента достаточно, что я не общепринятый термин случайно сказал.
Может тогда по умолчанию использовать уровень изоляции SERIALIZIBLE? Для чего нам тогда другие уровни изоляций, если они не дают гарантированной защиты от аномалий?
Есть уровни изоляции и аномалии при них. Чем ниже уровень - тем больше аномалий, но и производительность системы выше. Ты, как разработчик, должен решить, какого уровня будет достаточно для твоей системы, без избыточной изоляции. При уровне SERIALIZIBLE говорить о параллелизме не приходится, это прям из названия следует - транзакции просто выполняются последовательно по очереди.
Бывает, когда нам не нужны гарантии выполнения транзакции. А работу нужно ускорить. Например, логи записываешь. Ну не страшно, если что-то там не зафиксируется и на графике подведения итогов будет вместо 159384 записей 159383. Общей картины это не меняет. А записи частые и стоит побыстрее заталкивать. Вот и придуманы способы.
@@VitaliyZlobin Serializable это не про реализацию, а про результат. Более того, уже давно есть реализации serializable которые по мере возможности выполняют транзакции параллельно.
@@zakharka3938 алгоритм с вложенным циклом может выполниться за O(n), однако такой алгоритм имеет сложность O(n^2). Я бы сильно не полагался, на то что там что-то параллельно может выполниться - это подкапотная оптимизация СУБД, а не твоих процессов. И где я писал, что serializable про реализацию?
Все это нужно в очень редких кейсах, но в рф любят почти на каждом собесе поумничать. В реальном мире в 99% случаев это не нужно, так как все решается настройками по-умолчанию. Когда действительно сталкиваешься, то читаешь доку, вспоминаешь, и потом снова забываешь. Это как дедовщина в армии: видать одного замучили на собесе, он поклялся все это выучить, и потом других мучить ))) Был и у меня на работе такой умник. Когда его спрашивали свои же, зачем ты это все спрашиваешь? Он отвечал, что ему интересно понаблюдать как человек мучается и выкручивается. Редкий говнюк был, видать в школе хорошо огребал. Когда же возникали проблемы на бэке, сам же лез в доку и там вкуривал как в той или иной БД транзакционность реализована, какие уровни изоляции поддерживаются и т.д. Ну а так, хорошо всё показал. Молодец!
Записи реальных собесов и полезную инфу для подготовки можно найти на бусти 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
Успехов ))
Лайк за Хана. Какой же кайф
Отлично рассказал. Спасибо.
Пересмотрел дважды, пробежался по всем примерам руками, бро, обожаю тебя😅
Примеры транзакций хорошие, и тема классная, спасибо! Хотел бы немного дать рекомендаций, что можно тут улучшить.
1) Хотелось бы с первых минут знать, на примере какой СУБД рассматриваются транзакции, прежде чем приступать к примерам запросов.
2) Как-то очень абстрактно рассказываешь, не расскрывая деталей. Пишу после просмотра первых 5 минут. Про изолированность транзакций было сказано что-то вроде "транзакции с одного терминала не видят транзакции с другого терминала". Звучит как-то непонятно. А что означает тут слово "терминал"? Мне кажется, более приближенный к практике пример - это не 2 терминала, открытые на одной машине в vscode, а 2 пользователя / приложения, подключённые к одной базе. Понимаю, что контент может быть для тех, кто только начинает изучать эту тему, но хотелось бы, чтобы информация подавалась чуть более подробно, если это возможно. Возможно дальше и раскроется тема. Если раскроется - удалю коммент
Без негатива, успехов в развитии канала
Это лучший материал про уровни изоляции и аномалии! Респект!
Супер! Большое спасибо! Очень понятно с отличными наглядными примерами!
Самое смешное что решать эти проблемы требуется только в определенных предметных областях в программировании. А спрашивают везде, даже когда сами все используют по умолчанию настройки. Не только лишь всем понадобится решать такие проблемы, а ограниченному кругу разработчиков. Тоже самое касается про репликацию и шардировние, никто не реализовывал, но спрашивает
Причем это не только про базу данных.
Идеальное видео с качественными примерами. Красавчик!
Спасибо большое, все кратко и по делу! Восхитительно!
Толково изложено! В MySQL лост апдейты тоже (как и в постгресс) невозможны на уровне "repeatable read" ?
Попробовала сделать запрос с serializable в другой транзакции параллельно но для другого room_id и все равно постгрес ругается на read/write зависимость
Спасибо за классный контент! Твои 3 дня потраченные на видео прошли не зря)
Спасибо! Очень классно и наглядно показано
Ух огромное спасибо) отличный ролик. очень доступно объяснил
может я не прав, но как мне кажется что для ситуации на 21:52 не нужна блокировка совсем, так как по логике прога увидит сразу что остался один врач, и роллбекнет транзакцию
Спасибо тебе, Кристиан Бэйл
Иван, поясни пожалуйста про ретрай запросов? Можешь раскрыть тему, как это делается?
услышал подкрадули, подписался)
лост апдейт попадает под класс неповторяющегося чтения? Ведь когда делается апдейт, значение читается, над ним производится операция, новое значение записывается
В последнем примере с serializable можно поставить блокировку на строку из таблицы room по room_id и все будет ок без serializable. Или я не прав?
Не понял в seriaizable , ты говоришь что может даже не существует строки для блокировки. Но утаблицы есть room id (остальные понятно nil), и по этой же room id оно понимает что что-то происходит и включает блокировку. То есть это происходит именно по всей колонке, тогда можно сказать что вся таблица блокируется? Или если действительно пустая страница, я создам в нескольких окнах новые данные, как распрнделяться id новых записей?
Спасибо за видео!
Я один против мира - Александр Гоголев
Крутой тутор! Случайно наткнулся на канал, коммент для продвижения)
Все видео, я хотел дать тебе баночку энергетика)
Спасибо!
Весьма полезно.
Это база(с) Спасибо. Исчерпывающий гайд.
В примере про случай когда блокировки не спасают: если там установить уровень read commited, то вроде как проблема решится. Или нет?
"Третий день пишу видос, сам не рад, что начал" - здесь улыбнулся. Делаешь ролик на 5 минут - 80 тыщ просмотров, три дня - 300 просмотров и все от бабушки. Посмотрел ролик 3 раза, чтобы тебя поддержать. Хорошее видео.
И что делать, когда транзакция зависла из-за другой неоконченной транзакции?
Есть настройка у постгреса скок максимум можно висеть, если время превысится - ролбекнет
Очень годно, продолжай в том же духе!
это лучшее объяснение
Классно, спасибо!
А можно вернуть кринжовую музыку? Это единственное, что мне близко из темы твоего канала😘😘😘😘😘
Полезное видео. Лайк за видос.
Топовое видео, спасибо большое
примеры не очень, нафига жестко ставить баланс на счету? не честно получается, надо было с одного вычитать величину , а на другом туже прибавлять, тогда хоть и тоже все сломалось, но так честнее
Лайк за Хана Замая!!!!
Очень интересно и полезно, спасибо большое!!!
Снимай видосы, интересный материал
шикарный пример
очень полезный видос, спасибо!
7:26 - а в чём тут парадокс? Разве транзакция это не инструкция, описывающая что нужно сделать с актуальными данными базы? Я просто новичёк, не знаю нюансов ещё. Или после begin предполагается, что мы должны работать с изначальным состоянием базы, не беря во внимание последующие её апдейты?
Просто в примере вроде всё логично: после первой транзакции у Alice на балансе 2, а у Bob 998. Вторая транзакция выполняет инструкцию установить для Alice значение 998, а для Bob прибавить 2 и прибавляет к его текущему значению, которое равно 998.
А почему актуальными? Коммит второй транзакции не произошел еще. Апдейт бы брался во внимание, если бы изменения эти были в одной транзакции, а не в разных. В postgresql в момент открытия команды begin при уровне repeatable read, строится так называемый "снимок данных". С помощью этого снимка в postgresql как раз и избегается аномалия неповторяющегося чтения.
@@pyramidhead9692 когда идёт 3-й апдейт, после коммита, там лежат актуальные данные у Alice 2 рубля!!! И не верно ей ставить просто 998! тут даже без транзакций будет ошибка
Для чего впихивать в одну транзакцию две одинаковых операции на чтение, которые потенциально могут иметь разный результат?
Первое, что пришло в голову - по разному обрабатываем данные, можем применить разную функцию при двух одинаковых чтениях одних и тех же данных
"на уровне репитабл рид бывает только два типа аномалий" - а как же фантомы? несогласованное чтение разве не попадает под класс фантомы?
когда доктор боб хочет уйти он видит двоих на дежурстве. А когда снимается с дежурства, делая апдейт уже видит неявно одного себя. Алиса ведь себя уже закоммитила
Топ контент!
Bro, snimau svou treugolky. Spasibo
Иван, спасибо за видео, но его нужно переснимать.
В процессе просмотра было несколько неточностей. Одна из них кем-то упоминалась в коментах, что мол 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, думал в целом так сказать академический подход
Лайков за Замая...
Может тогда по умолчанию использовать уровень изоляции SERIALIZIBLE? Для чего нам тогда другие уровни изоляций, если они не дают гарантированной защиты от аномалий?
Есть уровни изоляции и аномалии при них.
Чем ниже уровень - тем больше аномалий, но и производительность системы выше. Ты, как разработчик, должен решить, какого уровня будет достаточно для твоей системы, без избыточной изоляции.
При уровне SERIALIZIBLE говорить о параллелизме не приходится, это прям из названия следует - транзакции просто выполняются последовательно по очереди.
Бывает, когда нам не нужны гарантии выполнения транзакции. А работу нужно ускорить. Например, логи записываешь. Ну не страшно, если что-то там не зафиксируется и на графике подведения итогов будет вместо 159384 записей 159383. Общей картины это не меняет. А записи частые и стоит побыстрее заталкивать. Вот и придуманы способы.
@@VitaliyZlobin Serializable это не про реализацию, а про результат. Более того, уже давно есть реализации serializable которые по мере возможности выполняют транзакции параллельно.
@@zakharka3938 алгоритм с вложенным циклом может выполниться за O(n), однако такой алгоритм имеет сложность O(n^2).
Я бы сильно не полагался, на то что там что-то параллельно может выполниться - это подкапотная оптимизация СУБД, а не твоих процессов.
И где я писал, что serializable про реализацию?
Race condition?
Все это нужно в очень редких кейсах, но в рф любят почти на каждом собесе поумничать. В реальном мире в 99% случаев это не нужно, так как все решается настройками по-умолчанию. Когда действительно сталкиваешься, то читаешь доку, вспоминаешь, и потом снова забываешь. Это как дедовщина в армии: видать одного замучили на собесе, он поклялся все это выучить, и потом других мучить )))
Был и у меня на работе такой умник. Когда его спрашивали свои же, зачем ты это все спрашиваешь? Он отвечал, что ему интересно понаблюдать как человек мучается и выкручивается. Редкий говнюк был, видать в школе хорошо огребал. Когда же возникали проблемы на бэке, сам же лез в доку и там вкуривал как в той или иной БД транзакционность реализована, какие уровни изоляции поддерживаются и т.д.
Ну а так, хорошо всё показал. Молодец!
9:29 Обновил всем баланс в 0 что не так?
нравятся твои видосы, но тут ты прям уже погас к середине видоса, похоже и правда с похмела)
бросай ты это дело, а видосы снимать продолжай)
Транзакции Антихайпа
ЗАМАЙ 2024
лайк с нулевой
Привет горшочку!
Да ббббббддддддддддддджжддддддддддддддщджддщдддддддддддддджждщддббббббббббббдддббщддлоо научить ь. Юююююжжюююэээ!э!.!
Ь. Ьььььллллллллддллл. Ьььььлллллббббббэ
клад!
блин, зря сделал += 2, лучше бы везде сделал +998 -998 а то код странно смотрится((