@@Niki-nx6cd Угу. Повторение повторение - мать учения мать учения. А если серьёзно - то действительно выбросив повторы видео можно сделать вполовину короче.
Классное видео, хорошая подача материала. На 15 слайде вы по сути рассказываете про Event Sourcing (сохраняются все изменения состояния баланса пользователя в виде событий транзакций) который в основном конечно используется вместе с CQRS, но CQRS может использоваться и без Event Sourcing что не предполагает сохранение всех изменений состояния приложения в виде событий.
Привет! Спасибо за коммент. На самом деле там нет противоречий. Могу использовать cqrs в любом виде, с event sourcing и без. Я бы мыслил немного с противоположной точки зрения, которая будет более generic и покроет частный случай с event sourcing. Я там уточнял в видево про сам паттерн, принцип и как он используется. Его реализация может быть разными способами. Говорим не про конкретную реализацию и event sourcing, к примеру , а принцип.
В транзакциях, по идее, не стоит кидать запросы куда-либо, кроме самой БД. Вынесение этого из транзакции, конечно же, всё усложняет. Этой теме можно даже отдельное видео посвятить.
Да, не стоит. Для этого есть разные техники обеспечения согласованности. Как минимум три знаю, если про распределеные системы. Но, я просто как пример привёл, тк там может быть что-то очень специфическое, не обязательно запрос.
Привет. Если джун уже хорошо сам язык знает, стоит это тоже все начинать изучать. Так как язык - инструмент. Я почти все собрал про них в паре видео и это сэкономит десятки часов, а кому-то и лет, если вместо сериала просто несколько раз их просмотреть и сами принципы запомнить и где быстро найти, если забыл. Чаще джуна такое не спрашивают, но, чем раньше хотя-бы узнать про это, тем больше мест, где ты будешь видеть это в работе и понимать.
Спасибо большое за замечательные объяснения. По поводу коротких видео. Честно говоря не хотелось бы такое увидеть на Вашем канале. Не смотрите пожалуйста в сторону создания контента для людей, у которых синдром Даннига-Крюгера на лбу написан. И так такого полно.
В SQL операторы всегда выполняются в рамках какой-либо транзакции: либо явно созданной, либо неявно созданной. То что автор называет атомарной операцией на самом деле оператор, выполняющийся в неявно созданной транзакции. Также и в вашем случае, перед выполнением запроса будет неявно создана транзакция.
С версиями атомарно блокировать прикольно (в том плане, что что-то новое для себя узнал). Я обычно использую " locked TINYINT(1) DEFAULT 0". И в селекте беру "WHERE locked=0". В апдейте "SET locked=1". Когда нужно снять блокировку отдельно: "SET locked=0". Типа release/acquire. В чем преимущество именно версий? Помимо того, что не надо лишний апдейт делать, как в моем случае, когда снимается блокировка. Также version же должен быть AUTOINCREMENT? Что-то в видосе упустил этот момент.
Видел такое, да. Не стал включать, так как чаще используется для блокировки на ресурс, но покрывается другими способами, про которые говорили. Усложняет логику программы самой, не всегда будет ясно, когда анлок делать и не сделать это с конфликтом или вообще забыть сделать. Добавляет дополнительно лишний запрос. Думаю, оно может в некоторых специфичных местах заюзаться. Типа залочить заказ на всегда, пока не разлочу сам вручную. Но, могу забыть и тд. Начинаются ручные анлоки, и проч. Вы ещё работаете с ним или забыли просто анлок? Вариант, если ресурсов мало и таких моментов мало. Получается оч жёсткий хороший контроль. Если их миллионы, то там уже не получится
Ну и сам понимаешь, помимо нагрузки и лишнего запроса оно тормознет жёстко. Тут я бы больше с пессимистик сравнивал, а не с версиями. Они больше при параллельной работе и обновлениях. Миллионы запросов и они spare по отношению к разделяемым ресурсам.
Ну я там говорил про версии, что мы их сами меняем в запросе. Тебе надо инкрементировать вручную для атомарности. А использовать можно и timestamp или что-то ещё, но чаще version. Compare and swap idiom.
Странно, пробую воспроизвести ситуацию из 35:16 на postgresql 16.1. Дефолтная изоляция read commited, запускаю паралллельно обе транзации, выполняю часть первой вплоть до update, но пока не коммичу, выполняю часть второй вплоть до update и этот update замирает - ждет, когда первая транзакция будет закоммичена или на ней будет выполнен откат. Получает поведение аналогичное поведению с использованием инкремента, но при этом без использования инкремента. Как я понял по видео - тут обе транзакции должны отработать без блокировки друг друга на update. Что может вызывать такое отличное поведение?
Привет. Это норм в пг. Так и будет. Он обеспечивает авто локи. Тебе надо глянуть видос с практикой про уровни изоляции транзакций - там делаем как раз это. Тут смысл не в блокировках или их отсутствии, а в аномалии - последние данные будут из второго запроса. У первого затрутся. Потом мы говорим, как сделать так, чтобы lost update избежать.
@@koduryem Привет, спасибо за ответ! Вот как раз тоже думал об этом, получается, что хоть транзакции и выполнялись параллельно до лока, та, которая первая возьмет лок закоммитится первой, а другая второй. Получается этакое почти последовательное выполнение. Но раз они выполнялись, можно сказать, последовательно, то можно ли это считать за lost update? Казалось, что lost update - это когда мы потеряли обновление в процессе транзакции, т.к. если бы не было лока, то первая транзакция обновила бы данные, например, записав 200, а вторая, в тот момент, когда первая еще не закончилась, записала бы 300. Тогда, после обновления второй транзакции, первая транзакция бы у себя оперировала значением 300, а не 200, как казалось. Она бы могла еще что-то делать с этим обновленным значением, например, посчитать что-то на его основе и получив из-за этого неправильные результаты.
Эта аномалия разные формы принимает. Но её паттерн везде один и тот же - одна действие затирает все, что делало предыдущее действие. Программа считала значение и на основе него применяет бизнес логику и сохраняет измененное значение в бд. В данном случае считаем, что мы добавили дельту к исходному значению. Два раза. В отдельных транзакциях. А в результате одна дельта потерялась. Чего мы не хотели получить. А хотели и первую добавить и вторую тоже. Представь, что эти операции прилетают с нашего сервиса в бд по сети. Считали, посчитали на сколько добавить и закинул обратно. И потеряли.
Замечательный выпуск. Каждый жду с нетерпением. Даешь Побольше сложных тем для помидоров!
Классно. Жду с нетерпением лабораторку по теории 👍
Годнота!!! Без рекламы курсов, автор красавчик.
Очень бы хотелось от вас увидеть видео на тему сисдиза! Контент у вас супер!
А можешь такие же видосы сделать подробные по Кафке?
больше лайков этому человеку
Мощно, качественный материал, продолжай подобное)
Вот это ультанул, спасибо от души!
Плюс этого видео, что не просто сухое объяснение, но и примеры где и как такое может получиться. Минус, одно и тоже объясняешь по нескольку раз.
Это чтобы точно все поняли
@@Niki-nx6cd Угу. Повторение повторение - мать учения мать учения. А если серьёзно - то действительно выбросив повторы видео можно сделать вполовину короче.
Ждал этого видео, спасибо !
Классное видео, хорошая подача материала. На 15 слайде вы по сути рассказываете про Event Sourcing (сохраняются все изменения состояния баланса пользователя в виде событий транзакций) который в основном конечно используется вместе с CQRS, но CQRS может использоваться и без Event Sourcing что не предполагает сохранение всех изменений состояния приложения в виде событий.
Привет! Спасибо за коммент. На самом деле там нет противоречий. Могу использовать cqrs в любом виде, с event sourcing и без. Я бы мыслил немного с противоположной точки зрения, которая будет более generic и покроет частный случай с event sourcing. Я там уточнял в видево про сам паттерн, принцип и как он используется. Его реализация может быть разными способами. Говорим не про конкретную реализацию и event sourcing, к примеру , а принцип.
@@koduryem так про то и речь, что CQRS в данном контексте проблему race condition сам по себе не решит, а вот event sourcing - решит
Да, я понимаю, о чем он говорил. Проблем с этим нет, я просто мыслил в других категориях немного. Спасибо за коммент!
Спасибо за видео! Возможно, вы сделаете ролик про свои любимые книги для бекендеров? Книги, ведь, все читают 😅
Спасибо большое!
В транзакциях, по идее, не стоит кидать запросы куда-либо, кроме самой БД. Вынесение этого из транзакции, конечно же, всё усложняет. Этой теме можно даже отдельное видео посвятить.
Да, не стоит. Для этого есть разные техники обеспечения согласованности. Как минимум три знаю, если про распределеные системы. Но, я просто как пример привёл, тк там может быть что-то очень специфическое, не обязательно запрос.
Вообще, ты очень чётко это подметил. Спасибо :)
А можно ссылочку на донаты?
На каком уровне (джун, мидл..) надо знать про изоляции транзакций и все эти техники?
Привет. Если джун уже хорошо сам язык знает, стоит это тоже все начинать изучать. Так как язык - инструмент. Я почти все собрал про них в паре видео и это сэкономит десятки часов, а кому-то и лет, если вместо сериала просто несколько раз их просмотреть и сами принципы запомнить и где быстро найти, если забыл. Чаще джуна такое не спрашивают, но, чем раньше хотя-бы узнать про это, тем больше мест, где ты будешь видеть это в работе и понимать.
@@koduryem понял, спасибо. Сам Джун, но я каким то образом запоминаю все сразу что ты говоришь ( ну или 99%)
Было бы круто, если бы объяснили как в postgresql работает уровень изоляции serializable!
Т.е. как под капотом оно работает.
Спасибо большое за замечательные объяснения. По поводу коротких видео. Честно говоря не хотелось бы такое увидеть на Вашем канале. Не смотрите пожалуйста в сторону создания контента для людей, у которых синдром Даннига-Крюгера на лбу написан. И так такого полно.
Спасибо за видео!
Скажите, а если мы атомарно делаем запрос, но в запросе много подзапросов и возможно cte, то оно выполнится атомарно?
В SQL операторы всегда выполняются в рамках какой-либо транзакции: либо явно созданной, либо неявно созданной. То что автор называет атомарной операцией на самом деле оператор, выполняющийся в неявно созданной транзакции. Также и в вашем случае, перед выполнением запроса будет неявно создана транзакция.
С версиями атомарно блокировать прикольно (в том плане, что что-то новое для себя узнал). Я обычно использую "
locked TINYINT(1) DEFAULT 0". И в селекте беру "WHERE locked=0". В апдейте "SET locked=1". Когда нужно снять блокировку отдельно: "SET locked=0". Типа release/acquire. В чем преимущество именно версий? Помимо того, что не надо лишний апдейт делать, как в моем случае, когда снимается блокировка.
Также version же должен быть AUTOINCREMENT? Что-то в видосе упустил этот момент.
Видел такое, да. Не стал включать, так как чаще используется для блокировки на ресурс, но покрывается другими способами, про которые говорили. Усложняет логику программы самой, не всегда будет ясно, когда анлок делать и не сделать это с конфликтом или вообще забыть сделать. Добавляет дополнительно лишний запрос. Думаю, оно может в некоторых специфичных местах заюзаться. Типа залочить заказ на всегда, пока не разлочу сам вручную. Но, могу забыть и тд. Начинаются ручные анлоки, и проч. Вы ещё работаете с ним или забыли просто анлок? Вариант, если ресурсов мало и таких моментов мало. Получается оч жёсткий хороший контроль. Если их миллионы, то там уже не получится
Ну и сам понимаешь, помимо нагрузки и лишнего запроса оно тормознет жёстко. Тут я бы больше с пессимистик сравнивал, а не с версиями. Они больше при параллельной работе и обновлениях. Миллионы запросов и они spare по отношению к разделяемым ресурсам.
Ну я там говорил про версии, что мы их сами меняем в запросе. Тебе надо инкрементировать вручную для атомарности. А использовать можно и timestamp или что-то ещё, но чаще version. Compare and swap idiom.
Странно, пробую воспроизвести ситуацию из 35:16 на postgresql 16.1. Дефолтная изоляция read commited, запускаю паралллельно обе транзации, выполняю часть первой вплоть до update, но пока не коммичу, выполняю часть второй вплоть до update и этот update замирает - ждет, когда первая транзакция будет закоммичена или на ней будет выполнен откат. Получает поведение аналогичное поведению с использованием инкремента, но при этом без использования инкремента. Как я понял по видео - тут обе транзакции должны отработать без блокировки друг друга на update. Что может вызывать такое отличное поведение?
Привет. Это норм в пг. Так и будет. Он обеспечивает авто локи. Тебе надо глянуть видос с практикой про уровни изоляции транзакций - там делаем как раз это. Тут смысл не в блокировках или их отсутствии, а в аномалии - последние данные будут из второго запроса. У первого затрутся. Потом мы говорим, как сделать так, чтобы lost update избежать.
Пг хоть и подождет, но запишет новые данные из второго запроса, забыв, что было до этого.
Как раз такое поведение поможет тебе при использовании атомарных апдейтов, в которые мы добавим условия дополнительно для гарантий, если нужно.
@@koduryem Привет, спасибо за ответ! Вот как раз тоже думал об этом, получается, что хоть транзакции и выполнялись параллельно до лока, та, которая первая возьмет лок закоммитится первой, а другая второй. Получается этакое почти последовательное выполнение. Но раз они выполнялись, можно сказать, последовательно, то можно ли это считать за lost update? Казалось, что lost update - это когда мы потеряли обновление в процессе транзакции, т.к. если бы не было лока, то первая транзакция обновила бы данные, например, записав 200, а вторая, в тот момент, когда первая еще не закончилась, записала бы 300. Тогда, после обновления второй транзакции, первая транзакция бы у себя оперировала значением 300, а не 200, как казалось. Она бы могла еще что-то делать с этим обновленным значением, например, посчитать что-то на его основе и получив из-за этого неправильные результаты.
Эта аномалия разные формы принимает. Но её паттерн везде один и тот же - одна действие затирает все, что делало предыдущее действие. Программа считала значение и на основе него применяет бизнес логику и сохраняет измененное значение в бд. В данном случае считаем, что мы добавили дельту к исходному значению. Два раза. В отдельных транзакциях. А в результате одна дельта потерялась. Чего мы не хотели получить. А хотели и первую добавить и вторую тоже. Представь, что эти операции прилетают с нашего сервиса в бд по сети. Считали, посчитали на сколько добавить и закинул обратно. И потеряли.
строго по теме: а не меняйте бд, и ничего не испортится ахаха!
нет, это не шутка