region23
@region23
веб-разработчик

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

Сабж. Вот не пойму я. Приведите пожалуйста побольше практических решений примения. Для Business-сектора, например.
  • Вопрос задан
  • 20203 просмотра
Пригласить эксперта
Ответы на вопрос 6
mocksoul
@mocksoul
Смысл ряляционных баз когда то был лишь в том, чтобы дать ответ на _любой_ вопрос за _любой_ промежуток времени. Т.е. например есть какая-то бд в компании и надо сделать какой-нибудь отчёт.

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

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

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

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

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

В общем и целом изначально написанное на mongodb приложение будет теоретически быстрее чем SQL вариант. По крайней мере с быстрой реализацией, наподобие MongoDB.
Ответ написан
Если абстрагироваться от таких «мелочей» как производительность, масштабируемость и надёжность, то Д(окументно)О(ориентированные)СУБД и О(объектно)О(ориентированные)СУБД во многих случаях позволяют разработчику отражать сущности предметной области на сущности БД без введения дополнительных сущностей :), которые приходится вводить в Р(еляционных)СУБД. Например, сколько копий переломано в спорах о том, как хранить в РСУБД объекты различных классов, унаследованных от одного базового класса (в одной таблице с кучей пустых полей, в таблицах для каждого отдельного класса, в общей таблице общие поля, ...), а тут просто храним в одной «таблице» и не думаем о таких мелочах. Отношения 1:1 и 1: М, когда сущности во второй половине отношения принадлежат одной и только одной сущности первой и не имеют смысла без неё также отображаются без дополнительных таблиц и полей для связи (вместо comments.post_id и comments.content просто храним в поле posts.comments список/массив комментов, не заботясь о целостности связей, синхронизации и т. п.). Другими словами, ДОСУБД часто облегчают жизнь разработчику, хотя иногда её усложняют (когда связи двунаправленные прежде всего, особенно M: М — для установления связи между двумя уже существующими сущностями надо производить две операции — добавление к первой ссылку на вторую, а ко второй на первую -, а не одну — добавление в таблицу связи — как в РСУБД )
Ответ написан
Комментировать
amarao
@amarao
Ну, одна из приятных возможностей mongo — не плодить таблички отношений, а иметь честные списки для many-to-many. Вторая возможность — хранить данные разного типа в качестве значения.
Ответ написан
Комментировать
@Alwake
Такие БД достаточно востребованы там, где требуется высокая производительность, ведь производительность MongoDB на порядок выше чем у реляционных БД. Об остальных плюсах и минусах можно прочитать тут.
Ответ написан
Shedar
@Shedar
blog.wordnik.com/12-months-with-mongodb
Пример практического применения
Ответ написан
Комментировать
andoriyu
@andoriyu
Чтобы хранить документы.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы