Сведения о вопросе

Solllo

10:23, 24th August, 2020

Объясните, зачем нужны документо-ориентированные БД (MongoDB)?

Просмотров: 532   Ответов: 7

Сабж. Вот не пойму я. Приведите пожалуйста побольше практических решений примения. Для Business-сектора, например.



  Сведения об ответе

VERSUION

05:58, 13th August, 2020

Смысл ряляционных баз когда то был лишь в том, чтобы дать ответ на _любой_ вопрос за _любой_ промежуток времени. Т.е. например есть какая-то бд в компании и надо сделать какой-нибудь отчёт.

В интернет-приложениях все несколько по иному. Чаще всего запросы к БД одинаковые за редким исключением (поиск). BigTable и прочие завязываются на этот принцип, создавая индекс на нужные запросы при изменении данных асинхронно.

Таким образом, после изменения данных сразу обновляются и индексы для нужных запросов. В SQL индексы тоже есть, но они на более низком уровне.

MongoDB строит индексы автоматически при первом запросе. Посему это очень похоже на схему lang <-> memcache <-> sql. Но на порядок быстрее, т.к. сам mongodb быстрее чем memcached (я сам сие не проверял ещё и верю с трудом, но все в один голос твердят что это так).

Второй бонус — более простая репликация. В частности, у того же mongodb концепция master-slave и шардов находится в самом сердце.

Третий бонус — map/reduce для обработки данных. Выполняются на встроенном языке (у mongodb это spidermonkey, т.е. яваскрипт).

В общем и целом изначально написанное на mongodb приложение будет теоретически быстрее чем SQL вариант. По крайней мере с быстрой реализацией, наподобие MongoDB.


  Сведения об ответе

prince

14:51, 19th August, 2020

Если абстрагироваться от таких «мелочей» как производительность, масштабируемость и надёжность, то Д(окументно)О(ориентированные)СУБД и О(объектно)О(ориентированные)СУБД во многих случаях позволяют разработчику отражать сущности предметной области на сущности БД без введения дополнительных сущностей :), которые приходится вводить в Р(еляционных)СУБД. Например, сколько копий переломано в спорах о том, как хранить в РСУБД объекты различных классов, унаследованных от одного базового класса (в одной таблице с кучей пустых полей, в таблицах для каждого отдельного класса, в общей таблице общие поля, ...), а тут просто храним в одной «таблице» и не думаем о таких мелочах. Отношения 1:1 и 1: М, когда сущности во второй половине отношения принадлежат одной и только одной сущности первой и не имеют смысла без неё также отображаются без дополнительных таблиц и полей для связи (вместо comments.post_id и comments.content просто храним в поле posts.comments список/массив комментов, не заботясь о целостности связей, синхронизации и т. п.). Другими словами, ДОСУБД часто облегчают жизнь разработчику, хотя иногда её усложняют (когда связи двунаправленные прежде всего, особенно M: М — для установления связи между двумя уже существующими сущностями надо производить две операции — добавление к первой ссылку на вторую, а ко второй на первую -, а не одну — добавление в таблицу связи — как в РСУБД )


  Сведения об ответе

screen

07:02, 28th August, 2020

Ну, одна из приятных возможностей mongo — не плодить таблички отношений, а иметь честные списки для many-to-many. Вторая возможность — хранить данные разного типа в качестве значения.


  Сведения об ответе

LIZA

12:02, 10th August, 2020

Такие БД достаточно востребованы там, где требуется высокая производительность, ведь производительность MongoDB на порядок выше чем у реляционных БД. Об остальных плюсах и минусах можно прочитать тут.


  Сведения об ответе

9090

00:30, 11th August, 2020

blog.wordnik.com/12-months-with-mongodb
Пример практического применения


  Сведения об ответе

ASSembler

08:40, 7th August, 2020

Чтобы хранить документы.


  Сведения об ответе

dumai

06:18, 8th August, 2020

Вчера, когда ждал пока отрабатывает реорганизация индексов в реляционных бд, тоже интересовался, но в разрезе BigTable/CouchDB

translated.by/you/scalability-worst-practices-1/into-ru/trans/
В качестве примера — типичное решение использовать базу данных для хранения пар ключ-значение. Такой выбор обычно обусловлен тем, что организация или разработчик имеют неплохую практику работы с базами данных и буквально идут по этой проторенной дорожке при решении многих задач. Проблемы возникают, когда особенности баз данных (ссылочная целостность, блокировки, объединения (joins) и схемы) начинают препятствовать расширению системы. Для приложения стоимость развития такого решения на основе базы данных, как правило, гораздо выше, чем при использовании других технологий. По мере увеличения частоты запросов к хранилищу пар ключ-значение, параллельная работа процессов базы данных снижает производительность, в то время как дополнительные возможности, которые предоставляет база данных, не используются. А ведь существует множество альтернатив традиционным базам данных, такие как: CouchDB, SimpleDB, BigTable.


Ответить на вопрос

Чтобы ответить на вопрос вам нужно войти в систему или зарегистрироваться