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