Как работать с бд правильно? (гайд, основные техники, pessimistic, optimistic, concurrency control)

Подписаться 1,5 тыс.

Просмотров 1,9 тыс.

50% 1

Контроль конкурентности. Concurrency Control.
Всем привет! В этом видео попробуем рассмотреть основные вопросы на собесе и по работе о том, как работать с разделяемыми данными в бд и не испортить их. Какие есть основные и не очень техники и в какой ситуации их употреблять. Что такое и когда использовать pessimistic или optimistic, for update, nowait и другое. Посмотрим, стоит ли использовать уровни изоляций транзакций или можно обойтись без них.
Telegram: t.me/dev_pushkin
Leetcode: leetcode.com/idfumg
GitHub: github.com/idfumg
Gists: gist.github.com/idfumg
0:00 Начинаем
04:10 Паттерны
05:21 Пессимистичный лок
14:45 Оптимистичный лок
21:18 Что лучше?
28:23 Read-Modify-Write
32:10 Two Threads
33:10 Lost Update
35:12 Transactions
37:38 Atomic Operations
42:58 FOR UPDATE
46:57 Serializable
48:32 Optimistic #1
53:25 Optimistic #2
1:01:27 CQRS
1:06:40 CQRS+FOR UPDATE
1:10:51 NOWAIT
1:16:17 SKIP LOCKED
1:28:02 Outro
#isolation #isolation_levels #transaction #transaction_isolation_levels #programming #database #interview #job #backend #developer #изоляция #уровни_изоляции #транзакции #изоляция_транзакций #базы данных #бд #интервью #работа #собес #собеседование #бэкенд #разработка #concurrency #concurrency_control #контроль_конкурентности #конкурентность #for_update #postgresql

Наука

Опубликовано:

8 май 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 34

@Mihes22 12 дней назад

Классно. Жду с нетерпением лабораторку по теории 👍

@aghori267 12 дней назад

Замечательный выпуск. Каждый жду с нетерпением. Даешь Побольше сложных тем для помидоров!

@user-bo7se2wm5e 11 дней назад

Мощно, качественный материал, продолжай подобное)

@korshyn05 12 дней назад

Ждал этого видео, спасибо !

@megaman13able 12 дней назад

Вот это ультанул, спасибо от души!

@Scarlett-hs9fd 10 дней назад

Спасибо большое!

@stanislavshultchov3402 11 дней назад

Классное видео, хорошая подача материала. На 15 слайде вы по сути рассказываете про Event Sourcing (сохраняются все изменения состояния баланса пользователя в виде событий транзакций) который в основном конечно используется вместе с CQRS, но CQRS может использоваться и без Event Sourcing что не предполагает сохранение всех изменений состояния приложения в виде событий.

@dev_pushkin 11 дней назад

Привет! Спасибо за коммент. На самом деле там нет противоречий. Могу использовать cqrs в любом виде, с event sourcing и без. Я бы мыслил немного с противоположной точки зрения, которая будет более generic и покроет частный случай с event sourcing. Я там уточнял в видево про сам паттерн, принцип и как он используется. Его реализация может быть разными способами. Говорим не про конкретную реализацию и event sourcing, к примеру , а принцип.

@deshtechno 11 дней назад

В транзакциях, по идее, не стоит кидать запросы куда-либо, кроме самой БД. Вынесение этого из транзакции, конечно же, всё усложняет. Этой теме можно даже отдельное видео посвятить.

@dev_pushkin 11 дней назад

Да, не стоит. Для этого есть разные техники обеспечения согласованности. Как минимум три знаю, если про распределеные системы. Но, я просто как пример привёл, тк там может быть что-то очень специфическое, не обязательно запрос.

@dev_pushkin 11 дней назад

Вообще, ты очень чётко это подметил. Спасибо :)

@Mihes22 12 дней назад

А можно ссылочку на донаты?

@vladimireliseev7602 12 дней назад

Спасибо за видео! Скажите, а если мы атомарно делаем запрос, но в запросе много подзапросов и возможно cte, то оно выполнится атомарно?

@3ombieautopilot 12 дней назад

Спасибо за видео! Возможно, вы сделаете ролик про свои любимые книги для бекендеров? Книги, ведь, все читают 😅

@vladimireliseev7602 12 дней назад

Было бы круто, если бы объяснили как в postgresql работает уровень изоляции serializable! Т.е. как под капотом оно работает.

@GuruNemo 12 дней назад

Плюс этого видео, что не просто сухое объяснение, но и примеры где и как такое может получиться. Минус, одно и тоже объясняешь по нескольку раз.

@Niki-nx6cd 11 дней назад

Это чтобы точно все поняли

@jirikropocev9911 9 дней назад

@@Niki-nx6cd Угу. Повторение повторение - мать учения мать учения. А если серьёзно - то действительно выбросив повторы видео можно сделать вполовину короче.

@mjeday 9 дней назад

С версиями атомарно блокировать прикольно (в том плане, что что-то новое для себя узнал). Я обычно использую " locked TINYINT(1) DEFAULT 0". И в селекте беру "WHERE locked=0". В апдейте "SET locked=1". Когда нужно снять блокировку отдельно: "SET locked=0". Типа release/acquire. В чем преимущество именно версий? Помимо того, что не надо лишний апдейт делать, как в моем случае, когда снимается блокировка. Также version же должен быть AUTOINCREMENT? Что-то в видосе упустил этот момент.

@dev_pushkin 8 дней назад

Видел такое, да. Не стал включать, так как чаще используется для блокировки на ресурс, но покрывается другими способами, про которые говорили. Усложняет логику программы самой, не всегда будет ясно, когда анлок делать и не сделать это с конфликтом или вообще забыть сделать. Добавляет дополнительно лишний запрос. Думаю, оно может в некоторых специфичных местах заюзаться. Типа залочить заказ на всегда, пока не разлочу сам вручную. Но, могу забыть и тд. Начинаются ручные анлоки, и проч. Вы ещё работаете с ним или забыли просто анлок? Вариант, если ресурсов мало и таких моментов мало. Получается оч жёсткий хороший контроль. Если их миллионы, то там уже не получится

@dev_pushkin 8 дней назад

Ну и сам понимаешь, помимо нагрузки и лишнего запроса оно тормознет жёстко. Тут я бы больше с пессимистик сравнивал, а не с версиями. Они больше при параллельной работе и обновлениях. Миллионы запросов и они spare по отношению к разделяемым ресурсам.

@dev_pushkin 8 дней назад

Ну я там говорил про версии, что мы их сами меняем в запросе. Тебе надо инкрементировать вручную для атомарности. А использовать можно и timestamp или что-то ещё, но чаще version. Compare and swap idiom.

@stalkerandrei9984 11 дней назад

На каком уровне (джун, мидл..) надо знать про изоляции транзакций и все эти техники?

@dev_pushkin 11 дней назад

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

@stalkerandrei9984 11 дней назад

@@dev_pushkin понял, спасибо. Сам Джун, но я каким то образом запоминаю все сразу что ты говоришь ( ну или 99%)

@aleksey6639 7 дней назад

Странно, пробую воспроизвести ситуацию из 35:16 на postgresql 16.1. Дефолтная изоляция read commited, запускаю паралллельно обе транзации, выполняю часть первой вплоть до update, но пока не коммичу, выполняю часть второй вплоть до update и этот update замирает - ждет, когда первая транзакция будет закоммичена или на ней будет выполнен откат. Получает поведение аналогичное поведению с использованием инкремента, но при этом без использования инкремента. Как я понял по видео - тут обе транзакции должны отработать без блокировки друг друга на update. Что может вызывать такое отличное поведение?

@dev_pushkin 7 дней назад

Привет. Это норм в пг. Так и будет. Он обеспечивает авто локи. Тебе надо глянуть видос с практикой про уровни изоляции транзакций - там делаем как раз это. Тут смысл не в блокировках или их отсутствии, а в аномалии - последние данные будут из второго запроса. У первого затрутся. Потом мы говорим, как сделать так, чтобы lost update избежать.

@dev_pushkin 7 дней назад

Пг хоть и подождет, но запишет новые данные из второго запроса, забыв, что было до этого.

@dev_pushkin 7 дней назад

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

@aleksey6639 7 дней назад

@@dev_pushkin Привет, спасибо за ответ! Вот как раз тоже думал об этом, получается, что хоть транзакции и выполнялись параллельно до лока, та, которая первая возьмет лок закоммитится первой, а другая второй. Получается этакое почти последовательное выполнение. Но раз они выполнялись, можно сказать, последовательно, то можно ли это считать за lost update? Казалось, что lost update - это когда мы потеряли обновление в процессе транзакции, т.к. если бы не было лока, то первая транзакция обновила бы данные, например, записав 200, а вторая, в тот момент, когда первая еще не закончилась, записала бы 300. Тогда, после обновления второй транзакции, первая транзакция бы у себя оперировала значением 300, а не 200, как казалось. Она бы могла еще что-то делать с этим обновленным значением, например, посчитать что-то на его основе и получив из-за этого неправильные результаты.

@dev_pushkin 7 дней назад

Эта аномалия разные формы принимает. Но её паттерн везде один и тот же - одна действие затирает все, что делало предыдущее действие. Программа считала значение и на основе него применяет бизнес логику и сохраняет измененное значение в бд. В данном случае считаем, что мы добавили дельту к исходному значению. Два раза. В отдельных транзакциях. А в результате одна дельта потерялась. Чего мы не хотели получить. А хотели и первую добавить и вторую тоже. Представь, что эти операции прилетают с нашего сервиса в бд по сети. Считали, посчитали на сколько добавить и закинул обратно. И потеряли.