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

[@ivangolang]

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

[@adwawdwad2499]

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

[@flower-py]

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

[@cintock]

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

[@alekseysverbeev2934]

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

[@dshyryayev]

Супер! Спасибо за такую качественную инфомрацию! Я тоже помню как долго разбирался с этим, но никогда наглядно не демонстрировал таким образом! Молодец автор!

[@niknt]

Это одно из самых полезных видео по уровням изоляции транзакций. Большое спасибо! 🎉

[@ZeBatua]

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

[@kuznet1941]

Не все так просто. Цитата: Для полной гарантии сериализуемости в Postgres Pro применяются предикатные блокировки, то есть блокировки, позволяющие определить, когда запись могла бы повлиять на результат предыдущего чтения параллельной транзакции, если бы эта запись выполнялась сначала. В Postgres Pro эти блокировки не приводят к фактическим блокировкам данных и, следовательно, никоим образом не могут повлечь взаимоблокировки транзакций. Они помогают выявить и отметить зависимости между параллельными транзакциями уровня Serializable, которые в определённых сочетаниях могут приводить к аномалиям сериализации. Транзакции Read Committed или Repeatable Read для обеспечения целостности данных, напротив, должны либо блокировать таблицы целиком, что помешает пользователям обращаться к этим таблицам, либо применять SELECT FOR UPDATE или SELECT FOR SHARE, что не только заблокирует другие транзакции, но и создаст дополнительную нагрузку на диск.

[@alex-0x6b]

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

[@DmitriyVassilyev]

Отлично рассказал. Спасибо.

[@borymskyi]

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

[@sergeyplotnikov4303]

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

[@Atikan37]

Спасибо большое, все кратко и по делу! Восхитительно!

[@cfirfbbg4344]

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

[@aleksandrzaremba6520]

Красавчик! Все по полкам раскидал, были бы такие преподы в универах

[@МаксимИващенко-л5о]

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

[@oksigenoksi]

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

[@VoroN93Rus]

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

[@Angelisme1995]

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

[@Hairy89pro]

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

[@eugenenazirov]

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

[@КоньЛюдоед-ф6ф]

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

[@dreamer_vi905]

Спасибо за классный контент! Твои 3 дня потраченные на видео прошли не зря)

[@sugukha]

услышал подкрадули, подписался)

[@yashkevich8164]

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

[@kuznet1941]

Причем это не только про базу данных.

[@MrSunchezz]

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

[@peteris6992]

Спасибо тебе, Кристиан Бэйл

[@SemyonF89]

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

[@bobhutchinson3638]

это лучшее объяснение

[@viktorz1986]

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

[@vlad_issslove]

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

[@pocketpodpopcorn]

Я один против мира - Александр Гоголев

[@foobarspam8548]

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

[@bobhutchinson3638]

шикарный пример

[@ЯковЛазоренко]

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

[@vova_dev]

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

[@userqh67vey6]

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

[@egorzrobko8053]

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

[@chefirka.]

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

[@andreikhotko5206]

Примеры транзакций хорошие, и тема классная, спасибо! Хотел бы немного дать рекомендаций, что можно тут улучшить. 1) Хотелось бы с первых минут знать, на примере какой СУБД рассматриваются транзакции, прежде чем приступать к примерам запросов. 2) Как-то очень абстрактно рассказываешь, не расскрывая деталей. Пишу после просмотра первых 5 минут. Про изолированность транзакций было сказано что-то вроде "транзакции с одного терминала не видят транзакции с другого терминала". Звучит как-то непонятно. А что означает тут слово "терминал"? Мне кажется, более приближенный к практике пример - это не 2 терминала, открытые на одной машине в vscode, а 2 пользователя / приложения, подключённые к одной базе. Понимаю, что контент может быть для тех, кто только начинает изучать эту тему, но хотелось бы, чтобы информация подавалась чуть более подробно, если это возможно. Возможно дальше и раскроется тема. Если раскроется - удалю коммент Без негатива, успехов в развитии канала

[@gera5458]

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

[@llwebstylell242]

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

[@Иван-д1д2б]

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

[@palach_666]

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

[@javalexiy]

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

[@НиколайПлегунов]

Не понял в seriaizable , ты говоришь что может даже не существует строки для блокировки. Но утаблицы есть room id (остальные понятно nil), и по этой же room id оно понимает что что-то происходит и включает блокировку. То есть это происходит именно по всей колонке, тогда можно сказать что вся таблица блокируется? Или если действительно пустая страница, я создам в нескольких окнах новые данные, как распрнделяться id новых записей? Спасибо за видео!

[@cheapdramas313]

может я не прав, но как мне кажется что для ситуации на 21:52 не нужна блокировка совсем, так как по логике прога увидит сразу что остался один врач, и роллбекнет транзакцию

[@bilorus-marschak]

Топ контент!

[@Драугр]

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

[@Boyarsskiy]

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

[@olgababoshina-rj4us]

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

[@SemenP-i4x]

Bro, snimau svou treugolky. Spasibo

[@ЯковЛазоренко]

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

[@p0isonspear]

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

[@maximderevnin6646]

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

[@ПолинаПомогаева-е9ж]

Попробовала сделать запрос с serializable в другой транзакции параллельно но для другого room_id и все равно постгрес ругается на read/write зависимость

[@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, думал в целом так сказать академический подход

[@vladddd1380]

ЗАМАЙ 2024

[@tier61wro]

нравятся твои видосы, но тут ты прям уже погас к середине видоса, похоже и правда с похмела) бросай ты это дело, а видосы снимать продолжай)

[@raphaelpashaev6683]

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

[@p0isonspear]

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

[@sander1614]

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

[@codebrainy6246]

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

[@OREH88]

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

[@kl45gp]

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

[@YanchikDev]

Race condition?

[@kibarabara]

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

[@kibarabara]

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

[@kibarabara]

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

[@777ElfenLied777]

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

[@pyramidhead9692]

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

[@TAF3000]

@@pyramidhead9692 когда идёт 3-й апдейт, после коммита, там лежат актуальные данные у Alice 2 рубля!!! И не верно ей ставить просто 998! тут даже без транзакций будет ошибка

[@BYGUR]

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

[@ИльяЗубков-ф8ж]

Первое, что пришло в голову - по разному обрабатываем данные, можем применить разную функцию при двух одинаковых чтениях одних и тех же данных

[@justniktolol]

клад!

[@ГубкаБоб-р8ъ]

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

[@VitaliyZlobin]

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

[@lelelelevv]

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

[@zakharka3938]

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

[@VitaliyZlobin]

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

[@АлексейКузьмичёв-ц7о]

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

[@nikolay4362]

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