ТРАНЗАКЦИИ И БЛОКИРОВКИ ПРОСТЫМ ЯЗЫКОМ
HTML-код
- Опубликовано: 19 июн 2024
- Записи реальных собесов и полезную инфу для подготовки можно найти на бусти boosty.to/vanyaio
Пиши мне любой вопрос в телегу: vanyaio
0:00 Вступление
1:10 Что такое транзакции
3:00 Пример использования
5:10 Аномалии
8:50 Неповторяющееся и фантомное чтение
11:33 Уровни изоляций
12:36 Repeatable read
16:37 Аномалии на repeatable read
18:56 Блокировки
21:00 Классификация аномалий на repeatable read
21:48 Блокировки на read commited уровне
23:32 Дефолтные блокировки и deadlock
25:15 Когда блокировки не спасают
28:10 Serializable
Записи реальных собесов и полезную инфу для подготовки можно найти на бусти boosty.to/vanyaio
Офф. дока по теме:
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 - это аномалия.
Ты очень крутой, спасибо. Читал книжку с кабанчиком, и твоё видео гораздо нагляднее, особенно с примером про докторов.
Счастья и здоровья тебе на всю нафиг жизнь ❤
Про Serializable для меня вообще было открытием. Спасибо!
Ух огромное спасибо) отличный ролик. очень доступно объяснил
Очень годно, продолжай в том же духе!
Супер! Большое спасибо! Очень понятно с отличными наглядными примерами!
Годный осмотр транзакций.
Контент зайдет для всех кто пишет бек, неважно на каком языке.
Особенно круто что прошёлся по локам, кстати советую ещё зрителям посмотреть какой то более конкретный пример с локами, например как обновляется одна строка в бд при конкурентном доступе от Реста и от Брокера. И почему в такой ситуации круто подходит Лок а не другие способы по типу siriazible
Очень интересно и полезно, спасибо большое!!!
Крутой тутор! Случайно наткнулся на канал, коммент для продвижения)
Идеальное видео с качественными примерами. Красавчик!
очень полезный видос, спасибо!
Спасибо!
Весьма полезно.
Спасибо! Очень классно и наглядно показано
Это лучший материал про уровни изоляции и аномалии! Респект!
Топовое видео, спасибо большое
Пересмотрел дважды, пробежался по всем примерам руками, бро, обожаю тебя😅
Это база(с) Спасибо. Исчерпывающий гайд.
Классно, спасибо!
Лайк за Хана. Какой же кайф
Полезное видео. Лайк за видос.
Как же жить стало проще когда узнал про SERIALIZABLE ISOLATION
Успехов ))
Отличный материал, только в конце про SERIALIZABLE я бы добавил, что он конкретно так лочит таблицу, из-за чего падает производительность, но зато все транзакции идут последовательно.
Спасибо, интересно. Единственное не рассказал как базу на работе локнул 😅
Топ контент!
Самое смешное что решать эти проблемы требуется только в определенных предметных областях в программировании. А спрашивают везде, даже когда сами все используют по умолчанию настройки. Не только лишь всем понадобится решать такие проблемы, а ограниченному кругу разработчиков. Тоже самое касается про репликацию и шардировние, никто не реализовывал, но спрашивает
Толково изложено! В MySQL лост апдейты тоже (как и в постгресс) невозможны на уровне "repeatable read" ?
Снимай видосы, интересный материал
"Третий день пишу видос, сам не рад, что начал" - здесь улыбнулся. Делаешь ролик на 5 минут - 80 тыщ просмотров, три дня - 300 просмотров и все от бабушки. Посмотрел ролик 3 раза, чтобы тебя поддержать. Хорошее видео.
Лайк за Хана Замая!!!!
В этом видео понятно, для примера баланс как число в таблице хранится. Когда храним финансовую информацию более правильно ее представить в виде истории изменения баланса. То есть приход 100 рублей, списание 5, приход 2. А баланс получать (рассчитывать) как сумму +100 - 5 + 2. Меньше вероятность запортить данные, чем хранить просто как значение в ячейке. И в случае проблем, легче разобраться в причинах и восстановить.
я не сталкивался, но делал бы 2 таблицы - одна с логом, другая с агрегирующим значением по этому логу
лост апдейт попадает под класс неповторяющегося чтения? Ведь когда делается апдейт, значение читается, над ним производится операция, новое значение записывается
Иван, поясни пожалуйста про ретрай запросов? Можешь раскрыть тему, как это делается?
Все видео, я хотел дать тебе баночку энергетика)
В последнем примере с serializable можно поставить блокировку на строку из таблицы room по room_id и все будет ок без serializable. Или я не прав?
Bro, snimau svou treugolky. Spasibo
В примере про случай когда блокировки не спасают: если там установить уровень read commited, то вроде как проблема решится. Или нет?
Лайков за Замая...
А можно вернуть кринжовую музыку? Это единственное, что мне близко из темы твоего канала😘😘😘😘😘
клад!
Все это нужно в очень редких кейсах, но в рф любят почти на каждом собесе поумничать. В реальном мире в 99% случаев это не нужно, так как все решается настройками по-умолчанию. Когда действительно сталкиваешься, то читаешь доку, вспоминаешь, и потом снова забываешь. Это как дедовщина в армии: видать одного замучили на собесе, он поклялся все это выучить, и потом других мучить )))
Был и у меня на работе такой умник. Когда его спрашивали свои же, зачем ты это все спрашиваешь? Он отвечал, что ему интересно понаблюдать как человек мучается и выкручивается. Редкий говнюк был, видать в школе хорошо огребал. Когда же возникали проблемы на бэке, сам же лез в доку и там вкуривал как в той или иной БД транзакционность реализована, какие уровни изоляции поддерживаются и т.д.
Ну а так, хорошо всё показал. Молодец!
И что делать, когда транзакция зависла из-за другой неоконченной транзакции?
Есть настройка у постгреса скок максимум можно висеть, если время превысится - ролбекнет
Может тогда по умолчанию использовать уровень изоляции SERIALIZIBLE? Для чего нам тогда другие уровни изоляций, если они не дают гарантированной защиты от аномалий?
Есть уровни изоляции и аномалии при них.
Чем ниже уровень - тем больше аномалий, но и производительность системы выше. Ты, как разработчик, должен решить, какого уровня будет достаточно для твоей системы, без избыточной изоляции.
При уровне SERIALIZIBLE говорить о параллелизме не приходится, это прям из названия следует - транзакции просто выполняются последовательно по очереди.
Бывает, когда нам не нужны гарантии выполнения транзакции. А работу нужно ускорить. Например, логи записываешь. Ну не страшно, если что-то там не зафиксируется и на графике подведения итогов будет вместо 159384 записей 159383. Общей картины это не меняет. А записи частые и стоит побыстрее заталкивать. Вот и придуманы способы.
@@VitaliyZlobin Serializable это не про реализацию, а про результат. Более того, уже давно есть реализации serializable которые по мере возможности выполняют транзакции параллельно.
@@zakharka3938 алгоритм с вложенным циклом может выполниться за O(n), однако такой алгоритм имеет сложность O(n^2).
Я бы сильно не полагался, на то что там что-то параллельно может выполниться - это подкапотная оптимизация СУБД, а не твоих процессов.
И где я писал, что serializable про реализацию?
Для чего впихивать в одну транзакцию две одинаковых операции на чтение, которые потенциально могут иметь разный результат?
лайк с нулевой
Race condition?
Иван, спасибо за видео, но его нужно переснимать.
В процессе просмотра было несколько неточностей. Одна из них кем-то упоминалась в коментах, что мол 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, думал в целом так сказать академический подход
Привет горшочку!
Да ббббббддддддддддддджжддддддддддддддщджддщдддддддддддддджждщддббббббббббббдддббщддлоо научить ь. Юююююжжюююэээ!э!.!
Ь. Ьььььллллллллддллл. Ьььььлллллббббббэ
"на уровне репитабл рид бывает только два типа аномалий" - а как же фантомы? несогласованное чтение разве не попадает под класс фантомы?
когда доктор боб хочет уйти он видит двоих на дежурстве. А когда снимается с дежурства, делая апдейт уже видит неявно одного себя. Алиса ведь себя уже закоммитила
7:26 - а в чём тут парадокс? Разве транзакция это не инструкция, описывающая что нужно сделать с актуальными данными базы? Я просто новичёк, не знаю нюансов ещё. Или после begin предполагается, что мы должны работать с изначальным состоянием базы, не беря во внимание последующие её апдейты?
Просто в примере вроде всё логично: после первой транзакции у Alice на балансе 2, а у Bob 998. Вторая транзакция выполняет инструкцию установить для Alice значение 998, а для Bob прибавить 2 и прибавляет к его текущему значению, которое равно 998.
А почему актуальными? Коммит второй транзакции не произошел еще. Апдейт бы брался во внимание, если бы изменения эти были в одной транзакции, а не в разных. В postgresql в момент открытия команды begin при уровне repeatable read, строится так называемый "снимок данных". С помощью этого снимка в postgresql как раз и избегается аномалия неповторяющегося чтения.
9:29 Обновил всем баланс в 0 что не так?
Транзакции Антихайпа
блин, зря сделал += 2, лучше бы везде сделал +998 -998 а то код странно смотрится((