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