Определение документной базы данных
Документная база данных – это тип нереляционных баз данных, предназначенный для хранения и запроса данных в виде документов в формате, подобном JSON. Документные базы данных позволяют разработчикам хранить и запрашивать данные в БД с помощью той же документной модели, которую они используют в коде приложения. Гибкий, полуструктурированный, иерархический характер документов и документных баз данных позволяет им развиваться в соответствии с потребностями приложений. Документная модель хорошо работает в таких примерах использования, как каталоги, пользовательские профили и системы управления контентом, где каждый документ уникален и изменяется со временем. Документные базы данных обеспечивают гибкость индексации, производительность выполнения стандартных запросов и аналитику наборов документов.
В следующем примере документ в формате, подобном JSON, описывает книгу.
Code snippet copied
Примеры использования
Управление контентом
Документная база данных – отличный выбор для приложений управления контентом, таких как платформы для блогов и размещения видео. При использовании документной базы данных каждая сущность, отслеживаемая приложением, может храниться как отдельный документ. Документная база данных позволяет разработчику с удобством обновлять приложение при изменении требований. Кроме того, если необходимо изменить модель данных, то требуется обновление только затронутых этим изменением документов. Для внесения изменений нет необходимости обновлять схему и прерывать работу базы данных.
Каталоги
Документные базы данных эффективны для хранения каталожной информации. Например, в приложениях для интернет‑коммерции разные товары обычно имеют различное количество атрибутов. Управление тысячами атрибутов в реляционных базах данных неэффективно. Кроме того, количество атрибутов влияет на производительность чтения. При использовании документной базы данных атрибуты каждого товара можно описать в одном документе, что упрощает управление и повышает скорость чтения. Изменение атрибутов одного товара не повлияет на другие товары.
Документные базы данных на AWS
Amazon DocumentDB (совместима с MongoDB)
Amazon DocumentDB (совместима с MongoDB) — это быстрая, масштабируемая, высокодоступная и полностью управляемая документная база данных, которая поддерживает рабочие нагрузки MongoDB. Разработчики могут использовать в Amazon DocumentDB такой же код приложения, драйверы и инструменты для запуска, управления и масштабирования рабочей нагрузки, что и в MongoDB, при этом получая высокопроизводительную, масштабируемую и готовую к работе базу данных и не тратя время на управление базовой инфраструктурой.
MongoDB — документо-ориентированная база данных (NoSQL)
MongoDB — это NoSQL хранилище данных, крайне удобное для хранения информации, которая не может быть нормально структурирована в рамках реляционных баз данных.
MongoDB — это СУБД с открытым исходным кодом, не требующая описания схемы таблиц и написанная на языке C++. Благодаря специализации базы данных удалось отойти от принципа «один размер подо всё», а за счёт минимизации методов работы с транзакциями появилась возможность решения целого ряда проблем, связанных с недостатком производительности, что также способствовало улучшению горизонтального масштабирования.
Документы в MongoDB хранятся в JSON или BSON, работа с такой моделью проще кодируется и проще управляется, а внутренняя группировка релевантных данных обеспечивает дополнительный выигрыш в быстродействии. MongoDB, по мнению разработчиков, должна заполнить разрыв между простейшими NoSQL‑СУБД, хранящими данные в виде «ключ — значение» (простыми и легко масштабируемыми, но обладающими минимальными функциональными возможностями, такими как Memcached, например) и большими реляционными СУБД (со структурными схемами и мощными запросами).
Что есть в MongoDB:
- гибкий язык для формирования запросов
- динамические запросы
- индексация коллекций
- профилирование запросов
- журналирование операций записи
- отказоустойчивость и масштабируемость
- асинхронная репликация и шардинг
- MapReduce
- полнотекстовый поиск с поддержкой морфологии
Работа с MongoDB реализована на языках программирования Java, C++, C#, PHP, Python, Perl, Ruby и других, а соответствующие компоненты есть во многих фреймворках (в Ruby on Rails и в Yii, например).
Статья опубликована в 2019 году
Тематические статьи
Реляционные базы данных и NoSQL‑хранилища
Базы данных служат для хранения и обработки данных. Бывают реляционные (SQL) и нереляционные (NoSQL) системы управления базами данных.
Реляционные системы управления базами данных (SQL) хранят данные в табличных структурах и чаще всего используются в качестве основного хранилища для веб‑приложений. Они очень стабильны и их надёжность проверена временем. Нереляционные СУБД (NoSQL) заметно моложе реляционных баз данных, а также заметно от них отличаются по структуре хранения данных и работе с ними. Большинство нереляционных хранилищ превосходят классические SQL СУБД по скорости доступа или при работе со специфическими типами данных, но обычно эта скорость достигается за счёт снижения надёжности хранения. На практике NoSQL‑решения обычно применяются не для хранения всех данных приложения, а для решения специфических задач — для кэширования, хранения логов, управления очередями, для распределённого хранения данных, ускорения поиска и фильтрации.
хранение данных
серверное ПО
Статья опубликована в 2019 году
Быстрый поиск на сайте, используя ElasticSearch или Sphinx
Sphinx и ElasticSearch — это поисковые «движки», которые обеспечивают более быстрый поиск и фильтрацию по сравнению с реляционными базами данных, а также обеспечивают возможность использования многих полезных функций поиска, например, учитывают морфологию языка, осуществляют фасеточный поиск, работают со стоп‑словами, обеспечивают выборочную индексацию и позволяют производить настройку формулы определения релевантности документов.
Объясните, зачем нужны документо-ориентированные БД (MongoDB)?
Сабж. Вот не пойму я. Приведите пожалуйста побольше практических решений примения. Для Business-сектора, например.
- Вопрос задан более трёх лет назад
- 19945 просмотров
2 комментария
Оценить 2 комментария
Павел @region23 Автор вопроса
Спасибо, почитаю!
Решения вопроса 0
Ответы на вопрос 6
Смысл ряляционных баз когда то был лишь в том, чтобы дать ответ на _любой_ вопрос за _любой_ промежуток времени. Т.е. например есть какая-то бд в компании и надо сделать какой-нибудь отчёт.
В интернет-приложениях все несколько по иному. Чаще всего запросы к БД одинаковые за редким исключением (поиск). BigTable и прочие завязываются на этот принцип, создавая индекс на нужные запросы при изменении данных асинхронно.
Таким образом, после изменения данных сразу обновляются и индексы для нужных запросов. В SQL индексы тоже есть, но они на более низком уровне.
MongoDB строит индексы автоматически при первом запросе. Посему это очень похоже на схему lang memcache sql. Но на порядок быстрее, т.к. сам mongodb быстрее чем memcached (я сам сие не проверял ещё и верю с трудом, но все в один голос твердят что это так).
Второй бонус — более простая репликация. В частности, у того же mongodb концепция master-slave и шардов находится в самом сердце.
Третий бонус — map/reduce для обработки данных. Выполняются на встроенном языке (у mongodb это spidermonkey, т.е. яваскрипт).
В общем и целом изначально написанное на mongodb приложение будет теоретически быстрее чем SQL вариант. По крайней мере с быстрой реализацией, наподобие MongoDB.
Ответ написан более трёх лет назад
Нравится 8 2 комментария
// В общем и целом изначально написанное на mongodb приложение будет теоретически быстрее чем SQL вариант.
Но думать нужно будет больше. Это важно.
//Но думать нужно будет больше. Это важно.
Думать надо и там и там, иначе факап будет неожиданным. Мне сложные решения на mongodb кажутся проще, чем сложные на PostgreSQL.
Если абстрагироваться от таких «мелочей» как производительность, масштабируемость и надёжность, то Д(окументно)О(ориентированные)СУБД и О(объектно)О(ориентированные)СУБД во многих случаях позволяют разработчику отражать сущности предметной области на сущности БД без введения дополнительных сущностей :), которые приходится вводить в Р(еляционных)СУБД. Например, сколько копий переломано в спорах о том, как хранить в РСУБД объекты различных классов, унаследованных от одного базового класса (в одной таблице с кучей пустых полей, в таблицах для каждого отдельного класса, в общей таблице общие поля, . ), а тут просто храним в одной «таблице» и не думаем о таких мелочах. Отношения 1:1 и 1: М, когда сущности во второй половине отношения принадлежат одной и только одной сущности первой и не имеют смысла без неё также отображаются без дополнительных таблиц и полей для связи (вместо comments.post_id и comments.content просто храним в поле posts.comments список/массив комментов, не заботясь о целостности связей, синхронизации и т. п.). Другими словами, ДОСУБД часто облегчают жизнь разработчику, хотя иногда её усложняют (когда связи двунаправленные прежде всего, особенно M: М — для установления связи между двумя уже существующими сущностями надо производить две операции — добавление к первой ссылку на вторую, а ко второй на первую -, а не одну — добавление в таблицу связи — как в РСУБД )
Ответ написан более трёх лет назад
Комментировать
Нравится 5 Комментировать
Ну, одна из приятных возможностей mongo — не плодить таблички отношений, а иметь честные списки для many-to-many. Вторая возможность — хранить данные разного типа в качестве значения.
Ответ написан более трёх лет назад
Комментировать
Нравится 3 Комментировать
Такие БД достаточно востребованы там, где требуется высокая производительность, ведь производительность MongoDB на порядок выше чем у реляционных БД. Об остальных плюсах и минусах можно прочитать тут.
Ответ написан более трёх лет назад
Нравится 2 1 комментарий
//производительность, ведь производительность MongoDB на порядок выше чем у реляционных БД
Не нужно холиварить. Если бы то, что вы говорите было правдой, mysql бы перестал быть необходимым. Любое обсуждение подобных СУБД сводится к вопросу- «а куда бы его сунуть» и ответу «для разных ситуаций разные СУБД». ДОСУБД здорово помогают при работе с большими деревьями, с даннными, имеющими большую динамичность, избавляют от необходимости плодить множество таблиц для похожих сущностей, но они упираются в мозг человека, который проектирует БД. Рескну сказать, что спроектировать БД в mysql в сто раз проще, чем в MongoDB.
blog.wordnik.com/12-months-with-mongodb
Пример практического применения
Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать
Чтобы хранить документы.
Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать
Ваш ответ на вопрос
Войдите, чтобы написать ответ
- Программирование
- +2 ещё
Какой инструмент может превратить схему БД в панель управления или админку?
- 2 подписчика
- час назад
- 59 просмотров
V Международная студенческая научная конференция Студенческий научный форум — 2013
Когда-то давно у всех в мире все было одинаковое. Но со временем люди начали изобретать новые вещи, новые формы и цвета. И таким образом у нас появился выбор. С появлением компьютером и сотовых телефонов развитие бытовой электроники заставило нас узнавать этот новый мир программ, интернета. И чем больше появлялось программ, тем больше становился выбор пользователя – чем же пользоваться? Каким брендом? Все начинающие пользователи спрашивают совета у более опытных друзей, многие ищут ответ в Интернете. А вот сами опытные друзья, сисадмины, программисты уже знают, что не все так просто, они начинают придираться и подбирать программы «под себя».
В нашей статье мы расскажем Вам о достоинствах и недостатках современных подходов к управлению базами данных, перечислим существующие СУБД и расскажем, в каких случаях какой подход обычно рекомендуется использовать. Это должно немного облегчить Вам выбор подхода и СУБД.
Итак, основные подходы к управлению базами данных:
1. Реляционный подход.
2. Объектно-ориентированный подход.
3. Документо-ориентированный подход.
Расскажем кратко о каждом из подходов.
Реляционный подход является наиболее распространённым подходом к организации баз данных в наше время. Именно на нем основано подавляющее большинство современных коммерческих системах управления базами данных. В реляционных системах информация представляются пользователю в виде таблиц. Такое представление является весьма удобным и достаточно понятным для любого человека. Возможно, именно благодаря этому реляционный подход и снискал такую популярность. Однако, хотелось бы отметить, что в современных СУБД зачастую нарушается классические принципы реляционного подхода в угоду расширения функциональности.
Объектно-ориентированная база данных (ООБД) — база данных, в которой данные моделируются в виде объектов, их атрибутов, методов и классов (как в объектно-ориентированном программировании). Объектно-ориентированный подход поддерживает все принципы объектно-ориентированного программирования – инкапсуляцию, наследование, полиморфизм. В БД содержатся классы, созданные пользователем. В объектно-ориентированной модели данных любая сущность реального мира представляется всего одним понятием — объектом. С объектом ассоциируется состояние и поведение. Состояние объекта определяется значениями его свойств — атрибутов.
Документо-ориентированные базы данных предназначены для хранения и управления документо-ориентированной или полу-структурированной информации. В отличие от реляционных баз данных с их понятиями «отношений», эти системы построены вокруг абстрактного понятия «документа». Документ содержит произвольное число свойств. Документы в ДОБД похожи на записи в РБД, но к ним не такие строгие требования. Они не обязаны иметь одинаковую структуры и количество атрибутов. [4]
Основные достоинства и недостатки перечисленных подходов
1. Реляционный подход
1. Модель данных отображает информацию в наиболее простой для пользователя форме.
2. Основан на развитом математическом аппарате, который позволяет достаточно лаконично описать основные операции над данными.
1.Относительно низкая скорость доступа и большой объем внешней памяти.
2.Трудность понимания структуры данных из-за появления большого кол-ва таблиц в результате логического проектирования.
3.Предметную область не всегда можно представить в виде совокупности таблиц.
4. Практически не позволяет хранить большие объемы данных.
1. Позволяют пользователям определять абстракции;
2. Облегчают проектирование некоторых связей;
3. Устраняют потребность в определяемых пользователями ключах;
4. В некоторых ситуациях обеспечивают более высокую производительность, нежели системы, основанные на реляционной модели;
1.Отсутствие интероперабельности между РБД и ООБД;
2.Отсутствие стандартной алгебры запросов;
3.Отсутствие средств обеспечения запросов;
4.Проблемы с безопасностью;
5.Недостаточная поддержка сложных объектов;
1. В сравнении с реляционными базами данных лучшая производительность при индексировании больших объёмов данных и большим количестве запросов на чтение.
2. Легче масштабируются в сравнении с SQL решениями
3. Легко менять «схему» данных: не нужно выполнять никаких операций обновления для добавления новых полей.
4. Нет проблем с хранением неструктурированных данных.
5. Единое место хранения всей информации об объекте: меньше операций вида «join».
6. Простой интерфейс общения с БД
1. Отсутствие транзакционной логики и контроля целостности в большинстве реализаций: необходимо реализовывать её в логике приложения. (Хотя специализированная логика может оказаться эффективнее, общих алгоритмов реляционных ДБ)
2. Для обработки данных необходимо использование дополнительного языка программирования.
3.Система MongoDB допускает максимальный размер БД всего 2 Гб на 32-битных системах.
Какой же подход следует использовать?
Данные легко представить в виде таблиц, они составляют несколько отдельных сущностей. Вам требуются в большей степени нетривиальные выборки. Вам не особо важна зависимость скорости работы программы от количества данных и сложности запроса, не нужно много онлайн-транзакций.
Вы работаете с данными, среди которых одни данные наследуют свойства от других или обладают строго индивидуальными свойствами.
Основными данными являются документы, Вам важна скорость работы программы и очень тяжело отсортировать данные по таблицам и сущностям. Вам нужны быстрые онлайн-транзакции. Вам нужны связи один-к-одному или многие-ко-многим и Вы не хотите их убирать.
Примеры использования:
Документо-ориентированные БД чаще используются в работе с Web-приложениями и сайтами, н. их использует Facebook, Twitter, ebay. Эти сайты хранят очень много информации, и пользователи очень часто просматривают ленту или входящие сообщения. Из-за того, что все данные о пользователе не хранятся в разных таблицах, а хранятся просто массивами в ДОБД, мы просматриваем наши сообщения за доли секунды. [5]
Объектно-ориентированные БД чаще используются, когда существует несколько сущностей с одинаковыми свойствами (компонент наследования) и когда у одной сущности есть свойства, которые должны обязательно присутствовать (компонент инкапсуляции). В РБД, если две сущности имеют одинаковые свойства, обычно приходится либо жертвовать нормализацией отношений, либо создавать отдельную таблицу с общими свойствами и две таблицы с отдельными свойствами, а если их должны определять еще и одинаковые первичные ключи? К тому же такая ситуация существенно увеличивает количество JOIN-ов при создании запросов.[7]
Классические РБД используются большинством обычных пользователей, не профессионалов. Т.к. работать с другими подходами намного сложнее вследствие новизны подходов и сложности компоновки информации (ведь принцип создания таблиц намного проще и известнее нам, чем создание классов). РБД используются, если при работе с конечным продуктом будут требоваться сложные выборки, запросы о каких-то конкретных частях данных (а не как в ДОБД – весь массив сообщений). Они используются, если у вас не возникает проблем с избыточностью информации и множеством связей один-к-одному или многие-ко-многим.
Современный рынок СУБД
Анализ распределения наиболее распространенных платформ позволяет выявить тройку лидеров, которые занимают в совокупности 78 % рынка: Btrieve/Pervasive (34 %), Microsoft (MS) SQL (24 %), Oracle (20 %). Остальные программные платформы существенно отстают от лидеров, рейтинг их популярности колеблется от 7 % до 1 %.
Согласно данным «Магического квадранта» Gartner на 2012 г., лидерами на рынке СУБД для хранилищ данных являются Teradata, Oracle, IBM, EMC/Greenplum, Sybase и Microsoft.
Заключение
Итак, мы рассказали Вам о трех основных подходах к созданию и управлению базами данных. На самом деле таких подходов очень много, все они имеют свои достоинства и недостатки. Многие из подходов не имеют широкого применения, но вполне возможно, что для какой-то конкретной БД Вам подойдет именно нестандартный метод.
На данное время не существует такого способа управления данными, который удовлетворил бы все требования программистов. Всегда приходится чем-то жертвовать: быстродействием, памятью, простотой. Вообще вряд ли когда-нибудь появится такая совершенная вещь, т.к. требования растут пропорционально улучшениям.
В нашей статье мы описали основные достоинства и недостатки трех популярных методов. К сожалению, посоветовать, что именно нужно использовать, мы не можем. Поэтому при создании любой БД вспомните все плюсы и минусы каждого подхода и решайте проблему для конкретно Вашей базы данных.
Список использованной литературы
1. Презентация MongoDB vs CouchDB Сравнение нереляционных баз данных. Автор — Антон Колесов.
2.ГОСТ Р ИСО МЭК ТО 10032-2007: Эталонная модель управления данными (идентичен ISO/IEC TR 10032:2003 Information technology — Reference model of data management).
3. ISO/IEC 2382-1:1993. Information technology — Vocabulary — Part 1: Fundamental terms.