Спасибо большое. Единственная просьба, уберите музыкальную подложку. Ведущий говорит достаточно тихо, а музыка иногда заглушает звук. Третий вид БД я так и не расслышал.
"Ведущий говорит достаточно тихо" - это главная проблема, звук пришлось вытягивать, поэтому появился фоновый шум, который замаскировали музыкой... Тут все непросто :)
Если речь про MongoDB: 1) мы можем использовать атомарные операции обновления, но да, они используют блокировку на уровне документа одной ноды кластера. Никто не мешает читать с других нод, всего-то secondaryPreffered в строке соединения. 2) мы можем запрашивать определенные поля, а не весь документ, если данные поля попадают в индекс - запрос вообще не лезет в хранилище данных, а берет результат прямо из индекса. Блокировки на чтение данных нет. 3) есть валидатор схемы и им глупо не пользоваться, это как раз и нормализует данные. 4) используя постоянное соединение с СУБД множество запросов выполняется не дольше чем один. Точнее так, разницу вы не увидите вообще никогда. Естественно при правильно построенных идентификаторах и индексах. 5) aggregation framework в сотку раз быстрее map reduce. 6) с кластера можно даже дамп снимать на горячую, без вывода из боевого режима одной из нод. Ну а обобщая, стоило бы упомянуть, что фишка noSQL в нормальном горизонтальном масштабировании (и map reduce тут ни при чем). Да, еще про то что в noSQL используется не SQL, а нормальный ЯП со всеми вытекающими плюсами.
@@pmak6074 ну если прямо для каждого поля, то у вас индексов будет больше чем данных. Смысла в этом нет. + Индексы тормозят запись в базу. Если нужна скорость чтения/поиска то в определенных пределах можно держать один из осколков кластера (без шардинга) в in-memory состоянии. Из минусов - очень долгий старт кластера до консистентного состояния при падении или необходимости перезапуска, ну и то что это все руками настраивается. Т.е. условно у вас может быть 2 осколка кластера, один в обычном режиме как primary, а второй в in-memory как secondary. При этом вы можете в драйвере подключения к монге добавить настройку, чтобы читало принудительно из secondary. Но лучше все таки поискать менее костыльные инструменты.
Смотришь вот так вот ролик, готовясь к первому собеседованию на тестировщика, и понимаешь, как все-таки круто быть профессионалом и уметь на 3 пальцах объяснить сложные вещи. Спасибо за труд! Действительно полезно.
Спасибо большое. У меня просьба. Хотелось бы видео где проводится не чистое описание одной их баз, а сравнение. Например какие нибудь примеры и в этом случае лучше бы подошел этот тип базы, а в этом случае вот этот. Просто к концу видео получается еще больше путаница, так где же использовать, а где нет. Еще хотелось бы услышать про семейства столбцов (cassandra) и key-value, в сравнениии. Вся беда в том что в интернете есть куча инфы как выглядит та или иная база, но очень мало инфы где их сравнивают между собой. Спасибо большое. В любом случае видео интересное.
А простого ответа просто нет. Слишком много переменных: на каком железе, какая реализация, с какими настройками, какие операции и т.д... Как правило, чем проще - тем уже функционал и быстрее (и понятнее)... key-value с персистансом на основе лога, типа bitcask - похоже что самые быстрые... Пока оперативки на индекс хватает :)
Хотелось услышать про CAP теорему. Ведь именно Partition Tolerance это то из-за чего мы любим и ненавидим NoSQL. Кстати NoSql базы не только документ-ориентированные. Например, Cassandra содержит внутри таблицы.
Одно замечание: как я понимаю, на стадии reduce тоже можно параллелить, если операция обладает ассоциативностью. А так, неплохой обзор. Спасибо! Ну и чашка там возможно стоит - оптимистичная стратегия в этом случае лучше ;)
Да, свертку тоже можно распараллелить, но ключей все же гораздо меньше, чем документов. Тут акцент был на то, что она должна дождаться выполнения Map на документах, которых может быть очень много... Как правило, основной профит делается на распараллеливании чтения документов и выполнения Map. А вообще MapReduce неисчерпаем как атом, а у меня бюджет в 15 мин на все :)
Только не понял почему автор сказал что нормализация это отношение "один ко многим" и "многие ко многим " ? Ведь нормализация это же создание таблиц и отношений . То есть на стадии создания БД, а не на стадии выполнении запросов)
Что-то не совсем понятно преимущество "локальность" над реляционной моделью. В реляционной модели тоже можно сделать аналогичную "локальность", просто писав не ссылки, а значения в поля таблицы.
O преимуществах локальности вообще имеет смысл говорить, если размер документа больше сектора на диске. В случае крупных документов использование больших записей в реляционной базе нам локальности не гарантирует: реляционки как правило используют страничную организацию памяти, и не факт, что страницы, содержащие одну большую запись таблицы, будут на диске рядом.
Не сложнее, к тому же многие noSQL используют нормальный ЯП, а не SQL. Но... Если лень разбираться с архитектурой, в продакшн такие базы лучше не ставить, т.к. косяки архитектурных решений выплывут не сразу.
Материал подается четко и понятно, но мне не нравиться манера разговора автора. Сначала начинает говорить, потом затухает и договаривает предложения шопотом. И это волнообразное шептание раздражает. Желаю автору прокачать голос) А то получается убаюкивание и засыпаю.
Очень доступно! размеренная подача, без лишних слов.Примеры очень информативны и коротки.
Крутой формат)) По возможности давайте больше таких видео
крутой - это мягко сказано. Формат охуенен.
Классная вводная, побольше бы таких. Спасибо!
Спасибо большое. Единственная просьба, уберите музыкальную подложку. Ведущий говорит достаточно тихо, а музыка иногда заглушает звук. Третий вид БД я так и не расслышал.
"Ведущий говорит достаточно тихо" - это главная проблема, звук пришлось вытягивать, поэтому появился фоновый шум, который замаскировали музыкой... Тут все непросто :)
третий вид - основанные на графах
Все правильно делает ведущий, что бы его услышать, надо прислушаться, что положительно сказывается на запоминании.
Спасибо тебе, ты навёл меня на мысль о том, что именно я не понимал, чтобы воспользоваться MongoDB.
Молодец парень. С задачей "не отпугнуть, чтобы подписчик полюбил БД" справился.
Если речь про MongoDB:
1) мы можем использовать атомарные операции обновления, но да, они используют блокировку на уровне документа одной ноды кластера. Никто не мешает читать с других нод, всего-то secondaryPreffered в строке соединения.
2) мы можем запрашивать определенные поля, а не весь документ, если данные поля попадают в индекс - запрос вообще не лезет в хранилище данных, а берет результат прямо из индекса. Блокировки на чтение данных нет.
3) есть валидатор схемы и им глупо не пользоваться, это как раз и нормализует данные.
4) используя постоянное соединение с СУБД множество запросов выполняется не дольше чем один. Точнее так, разницу вы не увидите вообще никогда. Естественно при правильно построенных идентификаторах и индексах.
5) aggregation framework в сотку раз быстрее map reduce.
6) с кластера можно даже дамп снимать на горячую, без вывода из боевого режима одной из нод.
Ну а обобщая, стоило бы упомянуть, что фишка noSQL в нормальном горизонтальном масштабировании (и map reduce тут ни при чем).
Да, еще про то что в noSQL используется не SQL, а нормальный ЯП со всеми вытекающими плюсами.
Мы вообще можем принудительно создавать пары индекс-значение, для каждого поля документа? Я понимаю, что объем данных вырастает при этом, но всё-же.
@@pmak6074 ну если прямо для каждого поля, то у вас индексов будет больше чем данных. Смысла в этом нет. + Индексы тормозят запись в базу. Если нужна скорость чтения/поиска то в определенных пределах можно держать один из осколков кластера (без шардинга) в in-memory состоянии. Из минусов - очень долгий старт кластера до консистентного состояния при падении или необходимости перезапуска, ну и то что это все руками настраивается. Т.е. условно у вас может быть 2 осколка кластера, один в обычном режиме как primary, а второй в in-memory как secondary. При этом вы можете в драйвере подключения к монге добавить настройку, чтобы читало принудительно из secondary. Но лучше все таки поискать менее костыльные инструменты.
Смотришь вот так вот ролик, готовясь к первому собеседованию на тестировщика, и понимаешь, как все-таки круто быть профессионалом и уметь на 3 пальцах объяснить сложные вещи. Спасибо за труд! Действительно полезно.
Чувак ты бог компуктеров! 😁👍🏻
Хороший урок, продолжайте делать такие видео.
Привет, Сергей! Обязательно передай Владимиру спасибо и респект! Толковый у тебя товарищ, прям как Ты)))!
Большое спасибо за ликбез!
Крутейший формат - готов смотреть такое.
Сергей, спасибо за информацию!
Спасибо за видео и объяснение! Очень интересно.
PS: Музыка лишняя, это правда.
Большое спасибо за ролик, все понятно и по полочкам!)
Очень приятно Вас слушать, информация легко воспринимается.
Очень классное видео. Спасибо большое!
пожалуйста)
Супер! Кратко и по делу. :)
Огромное спасибо, все прекрасно и конструктивно объяснил, побольше таких видео)
Хорошая лекция. Мне вначале показалось что это Гарик Харламов.
Коротко и очень понятно. Огромное спасибо!!!
Воу! Очень круто!
Ахах, голос огонь в этом видео, спокойный, плавный, будто познавательный ASMR посмотрел.
Шикарно!
Лайк однозначно.
Ништяк, с удовольствием послушал.
Я бы потом дизайн паттерны бы предложил рассмотреть или Java или Restful API. Спасибо, что делитесь знаниями ;) Или какие фреймворка реализуют JPA.
спасибо, очень доходчиво
Спасибо большое. У меня просьба. Хотелось бы видео где проводится не чистое описание одной их баз, а сравнение. Например какие нибудь примеры и в этом случае лучше бы подошел этот тип базы, а в этом случае вот этот. Просто к концу видео получается еще больше путаница, так где же использовать, а где нет.
Еще хотелось бы услышать про семейства столбцов (cassandra) и key-value, в сравнениии. Вся беда в том что в интернете есть куча инфы как выглядит та или иная база, но очень мало инфы где их сравнивают между собой. Спасибо большое. В любом случае видео интересное.
А простого ответа просто нет. Слишком много переменных: на каком железе, какая реализация, с какими настройками, какие операции и т.д... Как правило, чем проще - тем уже функционал и быстрее (и понятнее)... key-value с персистансом на основе лога, типа bitcask - похоже что самые быстрые... Пока оперативки на индекс хватает :)
Уважуха.
Спасибо
Очень интересно!
Легко понятно доступно
Полезный урок, но хотелось бы более чёткого произношения
О супер!
В описании к видео представляйте рассказчика, пожалуйста. (Имя-фамилия). Спасибо.
Хотелось услышать про CAP теорему. Ведь именно Partition Tolerance это то из-за чего мы любим и ненавидим NoSQL. Кстати NoSql базы не только документ-ориентированные. Например, Cassandra содержит внутри таблицы.
тема распределенных систем будет раскрыта, и даже еще не знаю, сколько роликов на эту тему будет...
Одно замечание: как я понимаю, на стадии reduce тоже можно параллелить, если операция обладает ассоциативностью. А так, неплохой обзор. Спасибо! Ну и чашка там возможно стоит - оптимистичная стратегия в этом случае лучше ;)
На reduce только ассициотивных операций такое можно или если неважен порядок вообще.
Да, свертку тоже можно распараллелить, но ключей все же гораздо меньше, чем документов. Тут акцент был на то, что она должна дождаться выполнения Map на документах, которых может быть очень много... Как правило, основной профит делается на распараллеливании чтения документов и выполнения Map. А вообще MapReduce неисчерпаем как атом, а у меня бюджет в 15 мин на все :)
Это круто.
Подскажите Mapreduce Это ведь частный случай mapping ?
Только не понял почему автор сказал что нормализация это отношение "один ко многим" и "многие ко многим " ? Ведь нормализация это же создание таблиц и отношений . То есть на стадии создания БД, а не на стадии выполнении запросов)
Можно очень быстро запилить магазин или склад с большим количеством товаров с разными свойствами.
Я чуть не сдох когда ты говорил
За документно-ориентированными субд будущее?
вопрос? какие риски могут быть если я перенсу бузу с мрины дб на могну ?
Походу президент канала реализует план "Преемник".
@@SergeyNemchinskiy спасибо, Сергей, что не взращиваете на канале культ личности. Ваших друзей и коллег тоже интересно послушать.
😂😂😂😂😂
Т.е. получается создаётся ещё одна база данных, но уже для компьютера а не человека.
шум на фоне мешает немного :(
Что-то не совсем понятно преимущество "локальность" над реляционной моделью. В реляционной модели тоже можно сделать аналогичную "локальность", просто писав не ссылки, а значения в поля таблицы.
O преимуществах локальности вообще имеет смысл говорить, если размер документа больше сектора на диске. В случае крупных документов использование больших записей в реляционной базе нам локальности не гарантирует: реляционки как правило используют страничную организацию памяти, и не факт, что страницы, содержащие одну большую запись таблицы, будут на диске рядом.
Материал ценный и полезный, но качество изложения скучно и однообразно, тяжело слушать.
Я искренне думал (и думаю всё ещё), что поиск в документ-ориентированной модели - это тоже её слабое место. Разве нет?
Там тоже есть индексы
Нихрена не понятно о map-reduce.
Видео интересное, но так много склейки, в результате очень дерганный ведущий
Ничего не понял.
Сложнее, чем реляционная база, а значит не нужно.
Не сложнее, к тому же многие noSQL используют нормальный ЯП, а не SQL.
Но... Если лень разбираться с архитектурой, в продакшн такие базы лучше не ставить, т.к. косяки архитектурных решений выплывут не сразу.
Такие нужны поддерживаю, но голос у автора сильно уставший
ЗЫ слишком много нарезал кадров
а чего так вкрадчиво, не уверено?
Шепчет чего-то
Либо говори четче и громче, либо музыку делай тише.
И вот зачем тут музыка?...
Что за музЫка боевая? Глушит конкретно.
Хоть бы чашку на полку сзади поставили
это хромакей
Да я предлагал постер с голой бабой повесить, но идею не поддержали... :)
музыку потише надо делать
Материал подается четко и понятно, но мне не нравиться манера разговора автора. Сначала начинает говорить, потом затухает и договаривает предложения шопотом. И это волнообразное шептание раздражает. Желаю автору прокачать голос) А то получается убаюкивание и засыпаю.
Звук отвратительный. То чувство когда человек хочет чего-то рассказать, а нормального звука не завезли.
ни о чем
Ля-ля-ля ля-ля-ля, 15 минут говорил, а пользы 2 строки
Чувак, я заснул, почему ты так скучно говоришь?
На самом деле совсем не скучно, а очень медленно. На скорости 1.5 было очень интересно слушать.
Очень интересно! Спасибо!