Способы работы с базой данных в микросервисах (все приёмы на работу и собес для любого разработчика)

Рет қаралды 4,940

Күн бұрын

Пікірлер: 56

@serhiirubets6630 2 ай бұрын

Огромное спасибо за видео, очень полезное. Пожалуйста, продолжайте в таком же духе, пусть это будет глубоко, без спешки. Пусть будут длинные видео, развернутая мысль. Не делайте пожалуйста как другие каналы, поверхностно пробежались и ничего не понятно. Вообще не понятно для кого такие видео делают. У вас очень крутой стиль подачи информации, не меняйте его, надо долго, делайте долго, главное что б было понятно не только для собесов, но и для реальной практики. Очень круто что вы разбираете такие темы, которые многие обходят стороной, спасибо за это. Если будет возможность - снимайте больше подобного контента, архитектура, микросервисы, event-driven design, DDD, kafka, нюансы разработки в HighLoad системах, всякие штуки из System Design, проектирование БД, проектирование тех или иных систем, как вы это видите. Еще раз спасибо, поддержал вас на бусте :)

@koduryem 2 ай бұрын

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

@karimpardayev 27 күн бұрын

Спасибо за объяснения! Чем глубже тем лучше, особенно по реальным кейсам RDB тип как распростроняются лочки если наша сущность с релешенами тд тп . Спасибо, делаешь круто!

@aghori267 8 ай бұрын

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

@TAF3000 2 ай бұрын

Вообще чётко! Красава, автору спасибо что всё в 1-м месте собрал и записал отличный видос!

@nostradamus_tech 6 ай бұрын

А можешь такие же видосы сделать подробные по Кафке?

@andrey95875 8 ай бұрын

Годнота!!! Без рекламы курсов, автор красавчик.

@Андрей-и6з4ъ 3 ай бұрын

Спасибо большое за все знания которыми ты делишься и раскладываешь всё по полочкам🙂😎

@Mihes22 8 ай бұрын

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

@odoyevsky 7 ай бұрын

Очень бы хотелось от вас увидеть видео на тему сисдиза! Контент у вас супер!

@lobiritus1512 2 ай бұрын

Спасибо за такой годный контент! Искал золото, нашел алмаз)

@koduryem 2 ай бұрын

Спасибо :)

@megaman13able 8 ай бұрын

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

@user-bo7se2wm5e 8 ай бұрын

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

@igorolikov1997 3 ай бұрын

А где именно ты нашел (1:24:30) FOR UPDATE - NOWAIT/SKIP LOCKED? В доке по постргресу только 1)FOR UPDATE 2) FOR NO KEY UPDATE 3) FOR SHARE 4) FOR KEY SHARE ?из раздела явных блокировок.

@koduryem 3 ай бұрын

www.postgresql.org/docs/current/sql-select.html

@igorolikov1997 3 ай бұрын

@@koduryem sps

@stanislavshultchov3402 8 ай бұрын

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

@koduryem 8 ай бұрын

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

@justfakkenloginme 8 ай бұрын

@@koduryem так про то и речь, что CQRS в данном контексте проблему race condition сам по себе не решит, а вот event sourcing - решит

@koduryem 8 ай бұрын

Да, я понимаю, о чем он говорил. Проблем с этим нет, я просто мыслил в других категориях немного. Спасибо за коммент!

@korshyn05 8 ай бұрын

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

@ЕкатеринаКригер-ы9в 5 ай бұрын

больше лайков этому человеку

@deshtechno 8 ай бұрын

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

@koduryem 8 ай бұрын

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

@koduryem 8 ай бұрын

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

@vladimireliseev7602 8 ай бұрын

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

@grigorii9019 7 ай бұрын

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

@stalkerandrei9984 8 ай бұрын

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

@koduryem 8 ай бұрын

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

@stalkerandrei9984 8 ай бұрын

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

@Антон-р8о8з Ай бұрын

Какой уровень изоляции предотвращает Lost Update?

@koduryem Ай бұрын

Смотри видео

@3ombieautopilot 8 ай бұрын

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

@aleksey6639 8 ай бұрын

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

@koduryem 8 ай бұрын

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

@koduryem 8 ай бұрын

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

@koduryem 8 ай бұрын

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

@aleksey6639 8 ай бұрын

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

@koduryem 8 ай бұрын

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

@mjeday 8 ай бұрын

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

@koduryem 8 ай бұрын

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

@koduryem 8 ай бұрын

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

@koduryem 8 ай бұрын

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

@LifeJoy22 Ай бұрын

Супер ❤

@Scarlett-hs9fd 8 ай бұрын

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

@Mihes22 8 ай бұрын

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

@lindx2533 2 ай бұрын

в шапке канала

@vladimireliseev7602 8 ай бұрын

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

@zakharka3938 8 ай бұрын

В SQL операторы всегда выполняются в рамках какой-либо транзакции: либо явно созданной, либо неявно созданной. То что автор называет атомарной операцией на самом деле оператор, выполняющийся в неявно созданной транзакции. Также и в вашем случае, перед выполнением запроса будет неявно создана транзакция.

@GuruNemo 8 ай бұрын

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

@Niki-nx6cd 8 ай бұрын

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

@jiři.kropocev 8 ай бұрын

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