ТРАНЗАКЦИИ И БЛОКИРОВКИ ПРОСТЫМ ЯЗЫКОМ

Записи реальных собесов и полезную инфу для подготовки можно найти на бусти 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

[@ivangolang]

Записи реальных собесов и полезную инфу для подготовки можно найти на бусти 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 про транзакции

[@adwawdwad2499]

Read uncommitted - это не аномалия, а уровень изоляция. Dirty read - это аномалия.

[@user-ge6pt5lp9u]

Пересмотрел дважды, пробежался по всем примерам руками, бро, обожаю тебя😅

[@flower-py]

Ты очень крутой, спасибо. Читал книжку с кабанчиком, и твоё видео гораздо нагляднее, особенно с примером про докторов. Счастья и здоровья тебе на всю нафиг жизнь ❤

[@alex-0x6b]

Про Serializable для меня вообще было открытием. Спасибо!

[@user-ir4vd5yk4x]

Ух огромное спасибо) отличный ролик. очень доступно объяснил

[@gera5458]

Очень годно, продолжай в том же духе!

[@chefirka.]

Очень интересно и полезно, спасибо большое!!!

[@vlad_issslove]

Крутой тутор! Случайно наткнулся на канал, коммент для продвижения)

[@eugenenazirov]

Идеальное видео с качественными примерами. Красавчик!

[@borymskyi]

Годный осмотр транзакций. Контент зайдет для всех кто пишет бек, неважно на каком языке. Особенно круто что прошёлся по локам, кстати советую ещё зрителям посмотреть какой то более конкретный пример с локами, например как обновляется одна строка в бд при конкурентном доступе от Реста и от Брокера. И почему в такой ситуации круто подходит Лок а не другие способы по типу siriazible

[@sergeyplotnikov4303]

Супер! Большое спасибо! Очень понятно с отличными наглядными примерами!

[@user-uo4ff6qb5r]

очень полезный видос, спасибо!

[@MrSunchezz]

Спасибо! Весьма полезно.

[@oksigenoksi]

Это лучший материал про уровни изоляции и аномалии! Респект!

[@Angelisme1995]

Спасибо! Очень классно и наглядно показано

[@egorzrobko8053]

Топовое видео, спасибо большое

[@cfirfbbg4344]

Лайк за Хана. Какой же кайф

[@vova_dev]

Классно, спасибо!

[@userqh67vey6]

Полезное видео. Лайк за видос.

[@VoroN93Rus]

Спасибо, интересно. Единственное не рассказал как базу на работе локнул 😅

[@SemyonF89]

Это база(с) Спасибо. Исчерпывающий гайд.

[@user-wb1ln3um3g]

Как же жить стало проще когда узнал про SERIALIZABLE ISOLATION Успехов ))

[@bilorus-marschak]

Топ контент!

[@ZeBatua]

Отличный материал, только в конце про SERIALIZABLE я бы добавил, что он конкретно так лочит таблицу, из-за чего падает производительность, но зато все транзакции идут последовательно.

[@user-yr9rq7we2n]

Толково изложено! В MySQL лост апдейты тоже (как и в постгресс) невозможны на уровне "repeatable read" ?

[@javalexiy]

Иван, поясни пожалуйста про ретрай запросов? Можешь раскрыть тему, как это делается?

[@yashkevich8164]

Самое смешное что решать эти проблемы требуется только в определенных предметных областях в программировании. А спрашивают везде, даже когда сами все используют по умолчанию настройки. Не только лишь всем понадобится решать такие проблемы, а ограниченному кругу разработчиков. Тоже самое касается про репликацию и шардировние, никто не реализовывал, но спрашивает

[@foobarspam8548]

Лайк за Хана Замая!!!!

[@p0isonspear]

лост апдейт попадает под класс неповторяющегося чтения? Ведь когда делается апдейт, значение читается, над ним производится операция, новое значение записывается

[@maximderevnin6646]

В последнем примере с serializable можно поставить блокировку на строку из таблицы room по room_id и все будет ок без serializable. Или я не прав?

[@viktorz1986]

"Третий день пишу видос, сам не рад, что начал" - здесь улыбнулся. Делаешь ролик на 5 минут - 80 тыщ просмотров, три дня - 300 просмотров и все от бабушки. Посмотрел ролик 3 раза, чтобы тебя поддержать. Хорошее видео.

[@user-yr9rq7we2n]

В примере про случай когда блокировки не спасают: если там установить уровень read commited, то вроде как проблема решится. Или нет?

[@palach_666]

Все видео, я хотел дать тебе баночку энергетика)

[@llwebstylell242]

Снимай видосы, интересный материал

[@user-pr5sl7sw8k]

Bro, snimau svou treugolky. Spasibo

[@user-up6vl1wd3i]

Лайков за Замая...

[@cintock]

В этом видео понятно, для примера баланс как число в таблице хранится. Когда храним финансовую информацию более правильно ее представить в виде истории изменения баланса. То есть приход 100 рублей, списание 5, приход 2. А баланс получать (рассчитывать) как сумму +100 - 5 + 2. Меньше вероятность запортить данные, чем хранить просто как значение в ячейке. И в случае проблем, легче разобраться в причинах и восстановить.

[@alekseysverbeev2934]

я не сталкивался, но делал бы 2 таблицы - одна с логом, другая с агрегирующим значением по этому логу

[@olgababoshina-rj4us]

А можно вернуть кринжовую музыку? Это единственное, что мне близко из темы твоего канала😘😘😘😘😘

[@user-lc2sp8hi1d]

клад!

[@zicksu2142]

Иван, спасибо за видео, но его нужно переснимать. В процессе просмотра было несколько неточностей. Одна из них кем-то упоминалась в коментах, что мол read uncommitted это не аномалия, а название изоляции. Про другие не вспомню сейчас, т.к. в несколько заходов смотрю видео. Причиной для того, чтобы перезаписать видос, на мой взгляд, является то, что на 15:10 ты говоришь что изоляция repeatable read избавляет от фантомного чтения. Это не так. Repeatable read имеет самое кричащее название (имхо) и гарантирует (внезапно) то, что чтение строки будет повторятся (но не количество строк). Фантомное чтение - это аномалия которая невозможна только на Serializable уровне. Т.е. если на repeatable read 2-ая транзакция изменит данные в рамках одной строки, то ок (1-ая транзакция их не увидит при повторном чтении, аномалия с неповторяющимся чтением не воспроизводится). Но если 2-ая транзакция изменит количество строк (обновит/удалит), то 1-ая транзакция (при повторном выполнении того же самого селекта) должна увидеть добавленные/удаленные строки. Это и есть фантомное чтение, которое не обеспечивается repeatable read-ом.

[@ivangolang]

Откуда эта инфа? Офф дока постгреса про phantom read на уровне Repeatable read - Allowed, but not in PG

[@ivangolang]

Про dirty read / read uncommitted - абсолютно минорный момент как назвать ситуацию, что вы читаете незакоммиченные данные. Коммента достаточно, что я не общепринятый термин случайно сказал.

[@zicksu2142]

@@ivangolang да, верно. Прошу прощения. Как-то упустил что видос исключительно про pg, думал в целом так сказать академический подход

[@YanchikDev]

Race condition?

[@BYGUR]

Для чего впихивать в одну транзакцию две одинаковых операции на чтение, которые потенциально могут иметь разный результат?

[@sander1614]

И что делать, когда транзакция зависла из-за другой неоконченной транзакции?

[@codebrainy6246]

Есть настройка у постгреса скок максимум можно висеть, если время превысится - ролбекнет

[@raphaelpashaev6683]

лайк с нулевой

[@777ElfenLied777]

7:26 - а в чём тут парадокс? Разве транзакция это не инструкция, описывающая что нужно сделать с актуальными данными базы? Я просто новичёк, не знаю нюансов ещё. Или после begin предполагается, что мы должны работать с изначальным состоянием базы, не беря во внимание последующие её апдейты? Просто в примере вроде всё логично: после первой транзакции у Alice на балансе 2, а у Bob 998. Вторая транзакция выполняет инструкцию установить для Alice значение 998, а для Bob прибавить 2 и прибавляет к его текущему значению, которое равно 998.

[@pyramidhead9692]

А почему актуальными? Коммит второй транзакции не произошел еще. Апдейт бы брался во внимание, если бы изменения эти были в одной транзакции, а не в разных. В postgresql в момент открытия команды begin при уровне repeatable read, строится так называемый "снимок данных". С помощью этого снимка в postgresql как раз и избегается аномалия неповторяющегося чтения.

[@Boyarsskiy]

Все это нужно в очень редких кейсах, но в рф любят почти на каждом собесе поумничать. В реальном мире в 99% случаев это не нужно, так как все решается настройками по-умолчанию. Когда действительно сталкиваешься, то читаешь доку, вспоминаешь, и потом снова забываешь. Это как дедовщина в армии: видать одного замучили на собесе, он поклялся все это выучить, и потом других мучить ))) Был и у меня на работе такой умник. Когда его спрашивали свои же, зачем ты это все спрашиваешь? Он отвечал, что ему интересно понаблюдать как человек мучается и выкручивается. Редкий говнюк был, видать в школе хорошо огребал. Когда же возникали проблемы на бэке, сам же лез в доку и там вкуривал как в той или иной БД транзакционность реализована, какие уровни изоляции поддерживаются и т.д. Ну а так, хорошо всё показал. Молодец!

[@user-wb5dh1ps4x]

9:29 Обновил всем баланс в 0 что не так?

[@user-it3yo1sn6i]

Может тогда по умолчанию использовать уровень изоляции SERIALIZIBLE? Для чего нам тогда другие уровни изоляций, если они не дают гарантированной защиты от аномалий?

[@VitaliyZlobin]

Есть уровни изоляции и аномалии при них. Чем ниже уровень - тем больше аномалий, но и производительность системы выше. Ты, как разработчик, должен решить, какого уровня будет достаточно для твоей системы, без избыточной изоляции. При уровне SERIALIZIBLE говорить о параллелизме не приходится, это прям из названия следует - транзакции просто выполняются последовательно по очереди.

[@lelelelevv]

Бывает, когда нам не нужны гарантии выполнения транзакции. А работу нужно ускорить. Например, логи записываешь. Ну не страшно, если что-то там не зафиксируется и на графике подведения итогов будет вместо 159384 записей 159383. Общей картины это не меняет. А записи частые и стоит побыстрее заталкивать. Вот и придуманы способы.

[@zakharka3938]

@@VitaliyZlobin Serializable это не про реализацию, а про результат. Более того, уже давно есть реализации serializable которые по мере возможности выполняют транзакции параллельно.

[@VitaliyZlobin]

@@zakharka3938 алгоритм с вложенным циклом может выполниться за O(n), однако такой алгоритм имеет сложность O(n^2). Я бы сильно не полагался, на то что там что-то параллельно может выполниться - это подкапотная оптимизация СУБД, а не твоих процессов. И где я писал, что serializable про реализацию?

[@kibarabara]

Привет горшочку!

[@kibarabara]

Да ббббббддддддддддддджжддддддддддддддщджддщдддддддддддддджждщддббббббббббббдддббщддлоо научить ь. Юююююжжюююэээ!э!.!

[@kibarabara]

Ь. Ьььььллллллллддллл. Ьььььлллллббббббэ

[@p0isonspear]

"на уровне репитабл рид бывает только два типа аномалий" - а как же фантомы? несогласованное чтение разве не попадает под класс фантомы? когда доктор боб хочет уйти он видит двоих на дежурстве. А когда снимается с дежурства, делая апдейт уже видит неявно одного себя. Алиса ведь себя уже закоммитила

[@OREH88]

Транзакции Антихайпа

[@nikolay4362]

блин, зря сделал += 2, лучше бы везде сделал +998 -998 а то код странно смотрится((