01:38 - Вопрос про перевод денег между аккаунтами в банке 04:40 - Блокировка строк, взаимная блокировка (deadlock), иерархическая блокировка 08:23 - Транзакции, ACID 09:57 - Изоляция транзакций, уровни изоляции 19:27 - Вопрос об оптимизации СУБД и обращения к ней 20:53 - Анализ запросов - EXPLAIN ANALYSE 22:43 - Реорганизация структуры БД - денормализация 23:54 - Вертикальное масштабирование / Репликация / Партиционирование 27:57 - CQRS, проекции 31:08 - Вопрос о мониторинге - Prometheus, Grafana, виды метрик и что стоит покрывать метриками 48:29 - О курсе по Event Sourcing, Event Driven и DDD
Посмотрел на одном дыхании) Будучи джуном, пытался залететь на сеньора и мне задавали аналогичные вопросы. Теперь я более опытен, но все равно не знаю как подать некоторые вещи на собеседовании. А тут все довольно круто изложено и аргументировано: Андрей - вы очень крутой преподаватель и разработчик)
Уважаемые разработчики, изначально задача ставилась как уйти от дедлок, я не очень понял как транзакции могут в этом помочь. Прокомментируйте, пожалуйста.
В общем случае фантомные чтения разрешены на уровне RepeatableRead. Но мы рассуждали про postgres, а у него такая ситуация невозможна. www.postgresql.org/docs/current/transaction-iso.html
отличие ждуна от мидла в том что джун не триггерится с теоретических бесполезных вопросов пока он пытается рассказать как что должно работать, а останавливается и думает над максимально подробным ответом
Если у нас есть две параллельные операции, которые прибавляют 100 к текущему значению, то, вероятно, мы бы хотели, чтобы результат этих операций был 200. Мы можем себе это позволить (операции ассоциативны). В результате выполнения вашего кода, если одна операция справилась первой, то вторая ничего не обновит и результат будет 100. В postgres все проблемы решит такая конструкция UPDATE accounts SET amount = amount + 100 WHERE id = 1; В данном случае amount = amount + 100 сработает как CAS (compare and set) операция. Не будет ни грязного чтения, ни потерянного обновления.
С каждым упомянутым в суе предложением денормализовать чужую базу грейд надо понижать на 1 :) Ее другие мидлы и сеньеры нормализвали не от нечего делать.
Иногда нам всем требуется вносить обширные изменения в наши системы. За всем этим стоит понятие целесообразности. Приходится оценивать вероятные затраты на внесение этих изменений и сравнить их с выгодой (возможно, долгосрочной) от них. Существуют ситуации, когда бизнес масштабируется и требует масштабируемости своих IT решений. И тут нет места для сомнений, вида "раз другие синьеры нормализовали базу, то, наверное, не зря", ведь они действовали целесообразно тому контексту, в котором находились. Безусловно, необдуманные изменения это не то, чего мы хотим. Однако, в формате собеседования, советовал бы предлагать как можно больше опций, для того, чтобы раскрыть себя для интервьюера, показать, что у вас есть не один способ решения проблемы.
Да собеседуемый не знает контекта нормализации базы, а сеньер должен был бы ими поинтересоваться. прежде чем предлагать рецепт волшебных таблеток . От меня собеседуемый получил бы встречный вопрос. "В каких контекстах, обстоятельствах, случаях денормализация базы еще больше понизит производительность ? "
Отличный вопрос, который позволит увидеть, как думает кандидат. И все же, на собеседовании, как правило, хочется поговорить с кандидатов вширь, посмотреть его размышления в разных ситуациях, поэтому часто нет времени обсуждать во всех деталях текущую реализацию. То же касается и формата "собеседование на youtube" :)
@@sukhoa Для разговора в ширь первым вопросом должен быть " какие максимальное и минимальное число могу храниться в одном байте информации ?" :) А дальше ширь в любую сторону, начиная от отличия кодировки utf8 от других типа cp1251 до маски сети, мимо машиного слова и размера блока ntfs которими dma общается с диском. :) с плавным переходом в алгоритмику и и оптимизацию на кешах процесора. Сеньеры должны обладать фундаментальными знаниями.
Очень интересно было услышать рассуждения опытного специалиста. Спасибо за интервью
01:38 - Вопрос про перевод денег между аккаунтами в банке
04:40 - Блокировка строк, взаимная блокировка (deadlock), иерархическая блокировка
08:23 - Транзакции, ACID
09:57 - Изоляция транзакций, уровни изоляции
19:27 - Вопрос об оптимизации СУБД и обращения к ней
20:53 - Анализ запросов - EXPLAIN ANALYSE
22:43 - Реорганизация структуры БД - денормализация
23:54 - Вертикальное масштабирование / Репликация / Партиционирование
27:57 - CQRS, проекции
31:08 - Вопрос о мониторинге - Prometheus, Grafana, виды метрик и что стоит покрывать метриками
48:29 - О курсе по Event Sourcing, Event Driven и DDD
Круто! Мне понравилось, спасибо за контент)
как по мне просто отлично, Юрка наверно половину не понял 😁 т.к. таких развёрнутых ответов на собесах не встретишь
Интересно, ждем следующее видео)
Посмотрел на одном дыхании) Будучи джуном, пытался залететь на сеньора и мне задавали аналогичные вопросы. Теперь я более опытен, но все равно не знаю как подать некоторые вещи на собеседовании. А тут все довольно круто изложено и аргументировано: Андрей - вы очень крутой преподаватель и разработчик)
Уважаемые разработчики, изначально задача ставилась как уйти от дедлок, я не очень понял как транзакции могут в этом помочь. Прокомментируйте, пожалуйста.
Транзакция включает некий уровень изоляции и блокирует доступ к данным пока они обрабатываются.
Разве уровень транзакции RepetableRead решает проблему фантомного чтения? Ее вроде как решает как раз Serializable
В общем случае фантомные чтения разрешены на уровне RepeatableRead. Но мы рассуждали про postgres, а у него такая ситуация невозможна. www.postgresql.org/docs/current/transaction-iso.html
@@sukhoa спасибо за ответ)
отличие ждуна от мидла в том что джун не триггерится с теоретических бесполезных вопросов пока он пытается рассказать как что должно работать, а останавливается и думает над максимально подробным ответом
Сомнительно, но окэй
Размазали видео почти на час, много воды (верю, что это препод из универа). Лучше идти по сценарию интервью и придерживаться ему.
первый вопрос дичь. Деньги хранятся в виде дебита и кредита
Не должно быть грязного чтения и:
x := (SELECT amount FROM accounts WHERE id = 1);
UPDATE accounts SET amount = x + 100 WHERE id = 1 AND amount = x;
Если у нас есть две параллельные операции, которые прибавляют 100 к текущему значению, то, вероятно, мы бы хотели, чтобы результат этих операций был 200. Мы можем себе это позволить (операции ассоциативны). В результате выполнения вашего кода, если одна операция справилась первой, то вторая ничего не обновит и результат будет 100. В postgres все проблемы решит такая конструкция UPDATE accounts SET amount = amount + 100 WHERE id = 1; В данном случае amount = amount + 100 сработает как CAS (compare and set) операция. Не будет ни грязного чтения, ни потерянного обновления.
С каждым упомянутым в суе предложением денормализовать чужую базу грейд надо понижать на 1 :)
Ее другие мидлы и сеньеры нормализвали не от нечего делать.
Иногда нам всем требуется вносить обширные изменения в наши системы. За всем этим стоит понятие целесообразности. Приходится оценивать вероятные затраты на внесение этих изменений и сравнить их с выгодой (возможно, долгосрочной) от них. Существуют ситуации, когда бизнес масштабируется и требует масштабируемости своих IT решений. И тут нет места для сомнений, вида "раз другие синьеры нормализовали базу, то, наверное, не зря", ведь они действовали целесообразно тому контексту, в котором находились.
Безусловно, необдуманные изменения это не то, чего мы хотим. Однако, в формате собеседования, советовал бы предлагать как можно больше опций, для того, чтобы раскрыть себя для интервьюера, показать, что у вас есть не один способ решения проблемы.
Да собеседуемый не знает контекта нормализации базы, а сеньер должен был бы ими поинтересоваться. прежде чем предлагать рецепт волшебных таблеток .
От меня собеседуемый получил бы встречный вопрос. "В каких контекстах, обстоятельствах, случаях денормализация базы еще больше понизит производительность ? "
Отличный вопрос, который позволит увидеть, как думает кандидат. И все же, на собеседовании, как правило, хочется поговорить с кандидатов вширь, посмотреть его размышления в разных ситуациях, поэтому часто нет времени обсуждать во всех деталях текущую реализацию. То же касается и формата "собеседование на youtube" :)
@@sukhoa Для разговора в ширь первым вопросом должен быть " какие максимальное и минимальное число могу храниться в одном байте информации ?" :)
А дальше ширь в любую сторону, начиная от отличия кодировки utf8 от других типа cp1251 до маски сети, мимо машиного слова и размера блока ntfs которими dma общается с диском.
:)
с плавным переходом в алгоритмику и и оптимизацию на кешах процесора.
Сеньеры должны обладать фундаментальными знаниями.
Очень много воды, отвечал бы по сути уважаемый
наиграно пипец