Спасибо за видео! Небольшие уточнения, вдруг будут кому-то интересно: 1)mvcc multiversion concurrency control, non multivalue 2) если мы говорим об mvcc то стоит упомянуть bcc lock based concurrency control это как раз таки про блокирующие алгоритмы 3) внутри каждой СУБД свое решение о том, как реализовать уровень изоляции, одни используют bcc (mySQL) другие mvcc (postgresql) поэтому в постгресе вам нужно на двух последних уровнях изоляции отлавливать ошибки сериализации, когда трансляция не прошла 4) про хранение индексов тоже есть большие отличия в разных СУБД, по этому не стоит так однозначно высказываться. В постгресе вообще нет кластерных индексов из-за многоверсионности
Макс, в сути своей твой материал хорош. Но видосы могли бы быть в 2 раза короче. Избавься от по-настоящему лишних слов в своей рече. Полезной нагрузки в них нет. Сэкономишь время зрителям, перформанс едва ли пострадает.
Очень много воды в виде инфы о нюансах собеседования, и оч мало реальной инфы о впросах и ответах. Может стоит разделять видео на тех часть с вопросами и ответами и часть с вопросами о моральном настрое и организации собеса?
Спасибо Макс за полезный и самое главное интересный контент. Все больше утверждают в мысли, что надо прочитать книгу Клеппмана о дизайне высоко-нагруженных приложений.
При раскрытии темы шардинга, неплохо было бы еще и рассказать про выбор ключа шардирования. Если это сделать неправильно, то вы рискуете бегать по шардам, собирая данные из разных мест при создании выборки для какого-то конкретного кастомера или нескольких кастомеров. В гео-распределенных кластерах ситуация будет только ухудшаться. И да, спасибо за видео) Очень помогают систематизировать уже имеющиеся знания и узнать что-то новое)
Неверное описание С (Consistency - Согласованность) при раскрытии темы ACID. Здесь используется другое значение Consistency - Consistency ensures that a transaction can only bring the database from one consistent state to another, preserving database invariants: any data written to the database must be valid according to all defined rules, including constraints, cascades, triggers, and any combination thereof. This prevents database corruption by an illegal transaction. Referential integrity guarantees the primary key-foreign key relationship
Я бы навскидку сделала просто на хеше, а-ля sha1, но на 6-7 символов. В случае коллизии можно рехешить хеш или ещë по какому-то цилическому воспроизводимому правилу работать. Коллизию от повторной вставки отличаем, сравнивая полный юрл. В таком случае не нужно держать вторую мапу, как в реализации с рандомными символами (которые тут в видео почему-то названы хеш-функцией, что неверно, т.к. результат недетерминирован).
Привет, Макс! Спасибо за классный рассказ) Разреши, добавлю как бы я отвечал про ключевое слово synchronized: к выводу о том, что потоки выстраиваются в очередь можно сказать, что вообще самое важное тут - выбрать правильный "замок", на котором происходит синхронизация. Собственно, именно от корректного замка и зависит работа. И если хочется проявить полет мысли, то добавить про "собственные внутренние замки", про "скрытые итераторы" и т.д. )) Concurrency - это большая отдельная тема)
Отличный вопрос! B-tree is a self-balancing tree data structure that maintains sorted data and allows searches, sequential access, insertions, and deletions in logarithmic time. The B-tree generalizes the binary search tree, allowing for nodes with more than two children. Unlike other self-balancing binary search trees, the B-tree is well suited for storage systems that read and write relatively large blocks of data, such as databases and file systems. По сути мы можем говорить, что B-Tree может быть случаем Binary Search Tree. Но окончательного слова (по науке) нет. Надо заглянуть в книгу Р. Лафоре по структурам данных и посмотреть что он говорит на этот счет.
18:25 На вопрос в формулировке "В чем проблема ключевого cлова synchronized в языке программирования Java?" Кажетcя единcтвенный адекватный ответ "Ни в чём" Похоже в тайтле ошибка Senior ~Java~ Database Engineer
Спасибо за видео. Посмотрел исходники. В видео озвучено, что решение "упрощено" в силу ограничений по времени и, если верно понял, иллюстрирует только работу на 1 инстансе приложения без персистентности. Но даже 1 инстанс такого приложения будет обрабатывать множество запросов (будет многопоточным). 1) Возможно стоит добавить оговорку, что решение еще и не учитывает много-поточность, которая точно возникнет в реальности даже на 1 инстансе. Прошу прощения, если такая оговорка была :) Почему решение не потоко-безопасно: использует HashMap, а не ConcurrentHashMap (или защиту локами/synchronized). Делает contains и put вместо атомарного и потоко-безопасного ConcurrentHashMap.putIfAbsent (или защиты локами/synchronized) и т.д. Т.о. текущая реализация может, например, отдать encoded, который в другом потоке был ассоциирован с другим longUrl 2) Нельзя ли было использовать DB и просто делать insert в таблицу с двумя полями (id с заполнением по sequence в базе и уникальным индексом, longUrl), а затем id корвертировать в base64 и отдавать как shortUrl? - и коллизий нет и потоко-безопасно и работает на нескольких инстансах (только для полноценного distributed high-load слабо подходит, что нормально "в силу ограничений по времени" и достаточно устно проговорить как изменяли бы архитектуру в этом случае)
Правильные мысли 👍 Данное решение действительно не предусматривает многопоточное использование. Просто так вопрос никто не ставил))) БД для собеседования слишком жирно наверное. Времени маловато. Но по хорошему так и должно быть. Потом можем применить приемы различные (например репликация) для распределения нагрузки, повышения доступности и устойчивости putIfAbsent - это вообще излюбленная фича 😻 Но как показывает собственная практика: часто игнорируется или забывается. Наверное шок собеседования кидает в первородные вещи 😹
Макс, спасибо за видео и ссылку на репо. Задачка на конструирование сервиса коротких ссылок, кажется, часто встречается и на секциях system design. Так что очень любопытно. Ну и вопросы по базам данных - очень актуально.
Все вопросы из секции-2 у меня бы не вызвали затруднений. Другой вопрос, что мне думается синьору хорошо бы позадавать уже вопросы помимо таких ещё и какие-нибудь позволяющие понять насколько человек ориентируется в окружении кода. Например, где человек предпочтет юзать БД, где брокеры сообщений, где рэдис. Или как бы человек организовал систему логирования и мониторинга в с нуля пишущемся приложении. Или как бы разбил всё и вся на микросервисы. Ну и подобное... А вот первая часть меня бы сбила с толку. При просмотре ролика сразу появились мысли в духе: "О боже, я не помню деталей реализации алгоритмов архивирования. Библиотек и классов предоставляющих такие возможности тоже ясен фиг не помню наизусть. Что вообще собеседующие хотят проверить? Навык за короткий срок хоть какое-то решение предоставить? Насколько свободно ориентируюсь в теме "жонглирования" строками/алгоритмами?" В общем когда Вы рассказали, что вариант с хэшированием был засчитан у меня возникла только одна реакция "а чо, так можно было"?
По поводу перевода дененг все очень поверхностно Что там за задаа и как делать не понятно, а с блокировками в этом эе разееле, Lost Update по сути - это состоянее гонки... и решается уже первой изоляцией , так же в реальности БД уже решаеют многие проблемы на уровне Read Comitted
Посмотрел исходники. Не понятно как предложенный алгоритм будет параллелится. Про борьбу с Read Uncommitted. К примеру, в Oracle и Postgre вообще нету этой проблемы в следствии архитектуры.
Можно ли называть решение 1 задачи хэшированием, если при этой операции один и тот же адрес каждый раз генерируется по разному. Соответственно это просто генерация. Поясните если чего то не понял.
Мне понравилось про пометку в письме "Коммерческая тайна", серьезно, с каких пор пометка где-то в письме или в присланном документе стала кого-то к чему-то обязывать? 😄
Зависит от законов конкретный страны. Если в ГК/УК страны указано, что для объявления "коммерческой тайны" достаточно этой пометки в письме - то эта фигня еще как имеет смысл. Это у нас она смысла никакого не несет в данном случае.
Спасибо за отличное видео! Маленький вопрос только по секции "Зачем нужен Replication": в чем принципиальное отличие пунктов "High Availability" и "No Downtime" (зачем они разнесены в два пункта)?
"High Availability" - скорость доступа к данным "No Downtime" - гарантия доступа к данным Это абсолютно разные вещи. Например, High Availability может зависеть от региона, который просто ближе к клиенту. В то время как, No Downtime может зависеть от количества инстансов в регионе или возможности достучаться в соседний (ближайший) регион, если текущий (ближайший) недоступен
Так, все було суцільно англійською мовою. Щоб добре проходити складні інтерв’ю (де не задаються заборонні закриті та біля-закриті питання) потрібно неменш ніж intermediate, а краще upper-intermediate Респект 👍
@@Jetbulb жесть, конечно. Про всю эту муть с транзакциями и уровнями изоляций даже на своем родном языке объяснить и не запутаться непросто, а на английском вообще ппц...
Не совсем понятно, как оптимистическая блокировка может помочь от Phantom Read? Можете подробно объяснить. Блокируется в данном случае набор records при попытке insert?
Большое спасибо что смотришь нас) Речь в интервью идеи про Восточную Европу и международный банк. В таком случае все интервью ведется на английском языке. От начала до конца. Исключением может быть интервью где не преследуется цель установить уровень знаний и навыков. Тогда может быть на локальном языке. В данном же примере все было на английском от первого касания до оффера.
Хороших вопрос. Если кратко: пришел, сделал проект, довел до релиза и ушел в закат. Динамика компании для меня слишком медленная. В банках очень все душно и нет драйва. А у меня «шило в попе» 😼 Компания отличая. Просто для менее реактивных людей. В какое отделение собираешься подаваться? Пиши в ЛС ТГ, если не хочешь тут распространяться ))) @maksymdobrynin
Максим, очень понравилось как вы ведëте собеседования и в целом материал на канале очень интересный. Хочу написать о главной, на мой взгляд, проблеме вашего изложения материала, может быть сочтëте полезным. Вне диалога и собеседования, на таком видео как это, в вашей речи очень сложно улавливать суть. Причины этого точно не определю, но предположу следующее. Вам часто пишут о большом количестве лишних слов в речи. Само по себе это мб не такая проблема для лектора, помогает не экать мэкать, если не успеваешь построить фразу, а вести плавное изложение. Но у вас этот мусор как будто забивает доносимую идею. У вас хорошая, не монотонная речь с акцентами, но акценты часто стоят именно на сорных словах. Итого мозг слушателя начинает отфильтровывать сначала лишние слова, потом и акценты, а в итоге и всю мысль целиком. Как говорят "с водой выплеснули ребëнка", а тут ребëнок в воде тонет и порой даже растворяется. Было бы классно, если бы получилось этот аспект доработать. В целом же ваша работа мне очень импонирует, спасибо за неë и за канал!
вот достаточно много посмотрел видео у данного автора. И по факту все видео говорят про одно: если ты мидл, ты должен умето говорить. Если сеньер, должен уметь делать. И вот тут как то странно происходит, делать то все это я могу, а вот говорить нет. Можно я сразу на сеньера пойду, устал мидлом сидеть... Естеты понапридумывали терминов, а по сути все всегда всеровно сводится к одному и тому же
Идеального источника не существует. Но… все очень зависит от реализации БД. Потому, хорошим источником правдивой информации будет документация к конкретной БД. Например, PostgreSQL www.postgresql.org/docs/current/transaction-iso.html
Много лишних рассуждений: Я подумал … Мне показалось … Наверно он подумал … Хочется слышать вопрос ответ А то прошло 10 минут, по Джава сказано ноль, зато сплошные рассуждения на тему коку что показалось
Это секретная информация)) Из уважения к компаниями не могу разглашать такую информацию Но у меня уже было как-то раз собеседование в Revoult. Там прикольно, хотя не уверен что их вопросы соответствуют задачам
Немного широкий вопрос. Можно подумать про репликацию, у нас есть мастер-нода с правами на запись. Остальные только на чтение. Но это широкий ответ, поскольку все зависит от конкретной задачи которую мы решаем.
No googling, чего? Они совсем куку чтоли, короче сразу нахер таких людей можно послать. Разработчики это огромная сеть комньюнити, которая постоянно делится, той или иной информацией, иногда забываются даже самые базовые вещи, ты и сам это знаешь. Тебе нужно им было просто сказать: "Вот видите у меня за спиной сколько наклеенных стикеров, с разными невыполненными задачами? Как думаете, можно ли удержать всю абсолютно информацию в голове? Ответ - нет! Именно поэтому я клею себе стикеры на стену". Вникнуть в код, понять четко поставленное условие - это уже немало времени, а разобраться со всем этим прибавив чтение одной лишь документации - это уже за гранью тех 45 мин. Всегда не понимал людей, которые хотят бля все быстро, дешево и качественно. Как сказал один очень хороший человек, вот выберите 2 любых пункта из 3, тогда и будет Вам решение.
А мне, как склонному к прокрастинации разработчику, наоборот заходит эта живая подача Макса. Словно увлекаешься беседой и, вместе с тем, полезные ништяки ловишь.
я тоже собеседовался в один банк, ING bank, прикольно было куча народа product owner, куча технических спецов, короче весело было. Несколько собесов, стресс и поведенческое собеседование и пр прелесть. Но я устроился в другой банк))
Привет, Макс! Очень приятно тебя слушать, выпускай побольше контента. Спасибо тебе огромное!
Спасибо большое))
Продолжаем в таком же режиме, но уже улучшенном 😎
Респект!
Спасибо за видео! Небольшие уточнения, вдруг будут кому-то интересно:
1)mvcc multiversion concurrency control, non multivalue
2) если мы говорим об mvcc то стоит упомянуть bcc lock based concurrency control это как раз таки про блокирующие алгоритмы
3) внутри каждой СУБД свое решение о том, как реализовать уровень изоляции, одни используют bcc (mySQL) другие mvcc (postgresql) поэтому в постгресе вам нужно на двух последних уровнях изоляции отлавливать ошибки сериализации, когда трансляция не прошла
4) про хранение индексов тоже есть большие отличия в разных СУБД, по этому не стоит так однозначно высказываться. В постгресе вообще нет кластерных индексов из-за многоверсионности
в mySQL тоже используется Multi-Versioning, в подсистеме InnoDB
Привет, классный формат, хотелось бы ещё таких видео)
Лучшее подробное описание ACID, такая сложная тема стала намного понятней 💯🔥
Спасибо Макс! Отличное видео! Как всегда! С праздниками тебя
Большое спасибо! Взаимно )
Чую, что в этом видео будет что-то годное)
Макс, в сути своей твой материал хорош. Но видосы могли бы быть в 2 раза короче. Избавься от по-настоящему лишних слов в своей рече. Полезной нагрузки в них нет. Сэкономишь время зрителям, перформанс едва ли пострадает.
Кому как, мне дополнительные разъяснения были не лишними
Очень много воды в виде инфы о нюансах собеседования, и оч мало реальной инфы о впросах и ответах. Может стоит разделять видео на тех часть с вопросами и ответами и часть с вопросами о моральном настрое и организации собеса?
Супер! На одном дыхании посмотрел. Хотелось бы ещё про кубер, манифесты, сервисы, истио, сервисмеш, прометеус, актуатор.
Большое спасибо за очередной выпуск!
Максим, большое спасибо тебе за качественный и супер-полезный контент!
Большое спасибо за выпуск!
btree это НЕ бинарное дерево, а наоборот, сильно ветвистое дерево 48:02
+1 en.wikipedia.org/wiki/B-tree
Очень крутое видео! Крутой формат! Никогда не пишу комменты, но этот случай - исключение!
Вот это крутой отзыв 👍
Респект, очень ценим!
Шикарное видео. Спасибо большое!
Радует что пошли интересные задачки
Большое спасибо! За счёт, в том числе, твоих видео устроился на крутую работу 💪😎 и увеличил зп в 3 раза
Спасибо Макс за полезный и самое главное интересный контент. Все больше утверждают в мысли, что надо прочитать книгу Клеппмана о дизайне высоко-нагруженных приложений.
При раскрытии темы шардинга, неплохо было бы еще и рассказать про выбор ключа шардирования. Если это сделать неправильно, то вы рискуете бегать по шардам, собирая данные из разных мест при создании выборки для какого-то конкретного кастомера или нескольких кастомеров. В гео-распределенных кластерах ситуация будет только ухудшаться.
И да, спасибо за видео) Очень помогают систематизировать уже имеющиеся знания и узнать что-то новое)
Отличный коммент. Большое спасибо))
Почаще таких видео. Оч полезно.
Надо было назвать Senior Database Developer
Что может быть приятнее, чем вернуться в рабочий ритм под голос любимого наставника?) Отличное видео, спасибо, Макс)
Спасибо)))
Респект 👍
Макс, обожаю твой канал и твои видео
Неверное описание С (Consistency - Согласованность) при раскрытии темы ACID. Здесь используется другое значение Consistency - Consistency ensures that a transaction can only bring the database from one consistent state to another, preserving database invariants: any data written to the database must be valid according to all defined rules, including constraints, cascades, triggers, and any combination thereof. This prevents database corruption by an illegal transaction. Referential integrity guarantees the primary key-foreign key relationship
Посмотрел реализацию шортенера ссылок и очень много вопросов к правильности реализации. Но за контент - спасибо!
Я бы навскидку сделала просто на хеше, а-ля sha1, но на 6-7 символов. В случае коллизии можно рехешить хеш или ещë по какому-то цилическому воспроизводимому правилу работать. Коллизию от повторной вставки отличаем, сравнивая полный юрл. В таком случае не нужно держать вторую мапу, как в реализации с рандомными символами (которые тут в видео почему-то названы хеш-функцией, что неверно, т.к. результат недетерминирован).
Спасибо, посмотрим. P.S/ Как же хорошо, когда английский C1 и никогда не думал, что буду учиться на разработчика))))
Привет, Макс! Спасибо за классный рассказ) Разреши, добавлю как бы я отвечал про ключевое слово synchronized: к выводу о том, что потоки выстраиваются в очередь можно сказать, что вообще самое важное тут - выбрать правильный "замок", на котором происходит синхронизация. Собственно, именно от корректного замка и зависит работа. И если хочется проявить полет мысли, то добавить про "собственные внутренние замки", про "скрытые итераторы" и т.д. )) Concurrency - это большая отдельная тема)
Привет))
Большой респект за твои мысли.
Отлично сказано 👍
Очень круто!
Спасибо
Спасибо за разбор собеседования. Но есть одно "но": 48:00 B-tree не есть binary search tree. Это два разных дерева поиска. Поправьте, если не прав.
Отличный вопрос!
B-tree is a self-balancing tree data structure that maintains sorted data and allows searches, sequential access, insertions, and deletions in logarithmic time. The B-tree generalizes the binary search tree, allowing for nodes with more than two children. Unlike other self-balancing binary search trees, the B-tree is well suited for storage systems that read and write relatively large blocks of data, such as databases and file systems.
По сути мы можем говорить, что B-Tree может быть случаем Binary Search Tree. Но окончательного слова (по науке) нет. Надо заглянуть в книгу Р. Лафоре по структурам данных и посмотреть что он говорит на этот счет.
Отлично, даже кажется я тоже имел дело с этой компанией :)
Отличное видео с интересными вопросами! 👍
Замечание по поводу структур данных для индексов: структура B-Tree не является бинарным, B в названии означает balanced
Замечание к моему замечанию: сейчас прочитал, что никто достоверно не знает, что означает B в B-tree
Вот и пообщались )))
@@Петр-з2с удобно устроились :)
18:25 На вопрос в формулировке "В чем проблема ключевого cлова synchronized в языке программирования Java?" Кажетcя единcтвенный адекватный ответ "Ни в чём"
Похоже в тайтле ошибка Senior ~Java~ Database Engineer
Спасибо за видео. Посмотрел исходники. В видео озвучено, что решение "упрощено" в силу ограничений по времени и, если верно понял, иллюстрирует только работу на 1 инстансе приложения без персистентности. Но даже 1 инстанс такого приложения будет обрабатывать множество запросов (будет многопоточным).
1) Возможно стоит добавить оговорку, что решение еще и не учитывает много-поточность, которая точно возникнет в реальности даже на 1 инстансе. Прошу прощения, если такая оговорка была :)
Почему решение не потоко-безопасно: использует HashMap, а не ConcurrentHashMap (или защиту локами/synchronized). Делает contains и put вместо атомарного и потоко-безопасного ConcurrentHashMap.putIfAbsent (или защиты локами/synchronized) и т.д. Т.о. текущая реализация может, например, отдать encoded, который в другом потоке был ассоциирован с другим longUrl
2) Нельзя ли было использовать DB и просто делать insert в таблицу с двумя полями (id с заполнением по sequence в базе и уникальным индексом, longUrl), а затем id корвертировать в base64 и отдавать как shortUrl? - и коллизий нет и потоко-безопасно и работает на нескольких инстансах (только для полноценного distributed high-load слабо подходит, что нормально "в силу ограничений по времени" и достаточно устно проговорить как изменяли бы архитектуру в этом случае)
Правильные мысли 👍
Данное решение действительно не предусматривает многопоточное использование. Просто так вопрос никто не ставил)))
БД для собеседования слишком жирно наверное. Времени маловато. Но по хорошему так и должно быть. Потом можем применить приемы различные (например репликация) для распределения нагрузки, повышения доступности и устойчивости
putIfAbsent - это вообще излюбленная фича 😻
Но как показывает собственная практика: часто игнорируется или забывается. Наверное шок собеседования кидает в первородные вещи 😹
B-tree это не всегда binary search tree. Аккуратнее.
Макс, спасибо за видео и ссылку на репо. Задачка на конструирование сервиса коротких ссылок, кажется, часто встречается и на секциях system design. Так что очень любопытно. Ну и вопросы по базам данных - очень актуально.
Спасибо что нас смотришь )))
Данная задача действительно из списка задач на System Design. Уже трижды слышал о ней из разных компаний
@@Jetbulb ну как не смотреть ) интересно ведь
Все вопросы из секции-2 у меня бы не вызвали затруднений. Другой вопрос, что мне думается синьору хорошо бы позадавать уже вопросы помимо таких ещё и какие-нибудь позволяющие понять насколько человек ориентируется в окружении кода. Например, где человек предпочтет юзать БД, где брокеры сообщений, где рэдис. Или как бы человек организовал систему логирования и мониторинга в с нуля пишущемся приложении. Или как бы разбил всё и вся на микросервисы. Ну и подобное...
А вот первая часть меня бы сбила с толку. При просмотре ролика сразу появились мысли в духе: "О боже, я не помню деталей реализации алгоритмов архивирования. Библиотек и классов предоставляющих такие возможности тоже ясен фиг не помню наизусть. Что вообще собеседующие хотят проверить? Навык за короткий срок хоть какое-то решение предоставить? Насколько свободно ориентируюсь в теме "жонглирования" строками/алгоритмами?" В общем когда Вы рассказали, что вариант с хэшированием был засчитан у меня возникла только одна реакция "а чо, так можно было"?
Большое спасибо за разбор
очень качественный контент
Всё отлично. Ещё было бы лучше дополнять рассказ примерами в картинках (в данном случае про ACID), на слух трудновато воспринимается.
поправочка - b-tree != Binary tree
взрыв мозга, у меня аж зуб заболел..))
По поводу перевода дененг все очень поверхностно Что там за задаа и как делать не понятно, а с блокировками в этом эе разееле, Lost Update по сути - это состоянее гонки... и решается уже первой изоляцией , так же в реальности БД уже решаеют многие проблемы на уровне Read Comitted
Посмотрел исходники. Не понятно как предложенный алгоритм будет параллелится.
Про борьбу с Read Uncommitted. К примеру, в Oracle и Postgre вообще нету этой проблемы в следствии архитектуры.
1. Никак. В видео сказано, что это быстрая реализация и она не лишена определённых проблем
2. +
хэш - случайно сгенерированный)) как так то ))
заболтался походу малясь
но, всеравно молодец! спасибо за труд!
Этот банк был Revolut? >)
Можно ли называть решение 1 задачи хэшированием, если при этой операции один и тот же адрес каждый раз генерируется по разному. Соответственно это просто генерация. Поясните если чего то не понял.
Все верно. Это не хеширование в сути своей. Данный пример (gist) всего лишь быстрая реализация с собеседования
Мне понравилось про пометку в письме "Коммерческая тайна", серьезно, с каких пор пометка где-то в письме или в присланном документе стала кого-то к чему-то обязывать? 😄
Зависит от законов конкретный страны. Если в ГК/УК страны указано, что для объявления "коммерческой тайны" достаточно этой пометки в письме - то эта фигня еще как имеет смысл. Это у нас она смысла никакого не несет в данном случае.
Спасибо за отличное видео!
Маленький вопрос только по секции "Зачем нужен Replication": в чем принципиальное отличие пунктов "High Availability" и "No Downtime" (зачем они разнесены в два пункта)?
"High Availability" - скорость доступа к данным
"No Downtime" - гарантия доступа к данным
Это абсолютно разные вещи.
Например, High Availability может зависеть от региона, который просто ближе к клиенту. В то время как, No Downtime может зависеть от количества инстансов в регионе или возможности достучаться в соседний (ближайший) регион, если текущий (ближайший) недоступен
@@Jetbulb это вы придумали, High Availability не про скорость
А в какой среде Вы рисовали представления таблиц? Очень красиво!
Это работа рук дизайнера.
Заказываем 🥹
Почему для предотвращения lost-update нужна связка из уровня изоляции Non-repeatable read и mvcc, почему не достаточно одного из этих компонентов?
Дякую за відео. Ви пояснювали їм всі ці речі на англійській мові?
Цікаво чи потрібно мати високий рівень англійської мови.
Так, все було суцільно англійською мовою. Щоб добре проходити складні інтерв’ю (де не задаються заборонні закриті та біля-закриті питання) потрібно неменш ніж intermediate, а краще upper-intermediate
Респект 👍
@@Jetbulb дуже дякую за відповідь!
@@Jetbulb жесть, конечно. Про всю эту муть с транзакциями и уровнями изоляций даже на своем родном языке объяснить и не запутаться непросто, а на английском вообще ппц...
Не совсем понятно, как оптимистическая блокировка может помочь от Phantom Read? Можете подробно объяснить. Блокируется в данном случае набор records при попытке insert?
В чистом виде оптимистическая блокировка поможет? Не ясно с каким уровнем изоляции ее использовать
Здравствуй Макс, и что в итоге? На интервью что сказали?
Привет!
Формальные отписки: «Все ок, двигаемся дальше»
Конечно, хотелось бы детальных описаний. Что было ок, а что было нок.
Спасибо за видео, скажи, пожалуйста, на каком языке был каждый из этапов?
Большое спасибо что смотришь нас)
Речь в интервью идеи про Восточную Европу и международный банк. В таком случае все интервью ведется на английском языке. От начала до конца. Исключением может быть интервью где не преследуется цель установить уровень знаний и навыков. Тогда может быть на локальном языке.
В данном же примере все было на английском от первого касания до оффера.
А про ООП и ArrayList ничего не спрашивали? Как так)))
На Senior и выше редко когда такое задают))
Уровень задач просто иной и из ответов будет ясно есть ли понимание ООП и прочего
Привет, а можно поинтересоваться почему ты из коммерцбанка ушел? Я просто планировала туда подаваться
Хороших вопрос. Если кратко: пришел, сделал проект, довел до релиза и ушел в закат.
Динамика компании для меня слишком медленная. В банках очень все душно и нет драйва. А у меня «шило в попе» 😼
Компания отличая. Просто для менее реактивных людей.
В какое отделение собираешься подаваться?
Пиши в ЛС ТГ, если не хочешь тут распространяться )))
@maksymdobrynin
Максим, очень понравилось как вы ведëте собеседования и в целом материал на канале очень интересный.
Хочу написать о главной, на мой взгляд, проблеме вашего изложения материала, может быть сочтëте полезным. Вне диалога и собеседования, на таком видео как это, в вашей речи очень сложно улавливать суть.
Причины этого точно не определю, но предположу следующее. Вам часто пишут о большом количестве лишних слов в речи. Само по себе это мб не такая проблема для лектора, помогает не экать мэкать, если не успеваешь построить фразу, а вести плавное изложение. Но у вас этот мусор как будто забивает доносимую идею. У вас хорошая, не монотонная речь с акцентами, но акценты часто стоят именно на сорных словах. Итого мозг слушателя начинает отфильтровывать сначала лишние слова, потом и акценты, а в итоге и всю мысль целиком. Как говорят "с водой выплеснули ребëнка", а тут ребëнок в воде тонет и порой даже растворяется. Было бы классно, если бы получилось этот аспект доработать.
В целом же ваша работа мне очень импонирует, спасибо за неë и за канал!
Один из самых крытых отзывов. Респект 👍
вот достаточно много посмотрел видео у данного автора. И по факту все видео говорят про одно: если ты мидл, ты должен умето говорить. Если сеньер, должен уметь делать. И вот тут как то странно происходит, делать то все это я могу, а вот говорить нет. Можно я сразу на сеньера пойду, устал мидлом сидеть... Естеты понапридумывали терминов, а по сути все всегда всеровно сводится к одному и тому же
очень улучшилось оформление и монтаж
подскажите пожалуйста где можно почитать про блокировки и изоляцию ?
Идеального источника не существует.
Но… все очень зависит от реализации БД. Потому, хорошим источником правдивой информации будет документация к конкретной БД.
Например, PostgreSQL www.postgresql.org/docs/current/transaction-iso.html
@@Jetbulb спасибо. Можете дать мне сылку где можно посмотреть базовые воросы ?
Много лишних рассуждений:
Я подумал …
Мне показалось …
Наверно он подумал …
Хочется слышать вопрос ответ
А то прошло 10 минут, по Джава сказано ноль, зато сплошные рассуждения на тему коку что показалось
Оглавление это больше похоже на кластерный индекс, а вот алфавитный указатель это некластерный.
Макс, это случайно собеседование не в Revolut было? :D
Это секретная информация))
Из уважения к компаниями не могу разглашать такую информацию
Но у меня уже было как-то раз собеседование в Revoult. Там прикольно, хотя не уверен что их вопросы соответствуют задачам
@@Jetbulb Проходил но кажется не прошёл. Если не секрет, на каком этапе срезали?
Ок, требования есть. А где же хорошие приложения? :)
Комментарий для продвижения и просто потому что умею писать
Все замечательно, но почему ж консистенция, а не консистентность?))
Пасхалка на подумать, так сказать )))
С разными блокировками на одном инстансе приложения все понятно, а как быть если инстансов несколько?
Немного широкий вопрос. Можно подумать про репликацию, у нас есть мастер-нода с правами на запись. Остальные только на чтение. Но это широкий ответ, поскольку все зависит от конкретной задачи которую мы решаем.
у меня вопрос к дисклеймеру
в отношении суверенных и независимых нельзя, а в отношении несуверенных и зависимых получается можно?
А какие требования в Дубае ? В Китае ? Сингапуре? Тошнит уже от запада
Deutsche Bank?
Nein :)
Но близко. Раскрывать подобные детали не можем
Программа - ужас.. Просто не о чем.. А почему бы содержание не написать? )
Компания Revolut
Разве только «Револют» предоставляет крутые инновации на рынке 🇪🇺 ?
тоже кажется - на западе банкинг не очень, а тут инновационный продукт))
консистэнцию
No googling, чего? Они совсем куку чтоли, короче сразу нахер таких людей можно послать. Разработчики это огромная сеть комньюнити, которая постоянно делится, той или иной информацией, иногда забываются даже самые базовые вещи, ты и сам это знаешь.
Тебе нужно им было просто сказать: "Вот видите у меня за спиной сколько наклеенных стикеров, с разными невыполненными задачами? Как думаете, можно ли удержать всю абсолютно информацию в голове? Ответ - нет! Именно поэтому я клею себе стикеры на стену". Вникнуть в код, понять четко поставленное условие - это уже немало времени, а разобраться со всем этим прибавив чтение одной лишь документации - это уже за гранью тех 45 мин.
Всегда не понимал людей, которые хотят бля все быстро, дешево и качественно. Как сказал один очень хороший человек, вот выберите 2 любых пункта из 3, тогда и будет Вам решение.
👍👍👍
Когда наконец этот синьор девелопер перестанет лить пустую воду, 15 минут я смотрю подводящие "вот так вот... Вот эт вот... "
Это и отличает мидла от синьора 😁😁😁
Не заметил воды
Сейчас такое время. Чем ты забористее тем ты прав.
А мне, как склонному к прокрастинации разработчику, наоборот заходит эта живая подача Макса. Словно увлекаешься беседой и, вместе с тем, полезные ништяки ловишь.
Очень много воды
Не забывай пожалуйста дышать.
А то на одном вдохе целый час не только говорить тяжело, но и слушать тоже.
Похоже на собес Революта
О, ну это для дяденек
Хотя тут в основном про БД и засчет того, что у нас был семестр по этой теме, суть более менее уловима
это очень простые кейсы, неужели это прям реал собес был? 😂 податься что ли в фин-тех....🤣
Нет, сейчас уже сложнее, чем больше таких видео тем сложнее собесы))
сто пудов это Револют
Хорошая попытка )))
Какой хитрый дисклеймер. Киевские власти не согласны будут с ним )
я тоже собеседовался в один банк, ING bank, прикольно было куча народа product owner, куча технических спецов, короче весело было. Несколько собесов, стресс и поведенческое собеседование и пр прелесть. Но я устроился в другой банк))
что за поведенческое собеседование?
@@Das.Kleine.Krokodil Behavioral questions. Расскажите как вы решали конфликтную ситуацию на работе.. бла бла
if statements always use braces, {}. JCC - //зануда офф
🤣 да, понимаю. Сам страдаю JCC.
Но как показывает практика, если одна строка короткая, то можно и без «курлей»
System.out.println("Top as always");
log.info(“Thanks!”)
I was excited to watch your video, you inspire me. If you want to get more fans research 'Promosm'!!