Заявка на услуги DST
Наш специалист свяжется с вами, обсудит оптимальную стратегию сотрудничества,
поможет сформировать бизнес требования и рассчитает стоимость услуг.
Преимущества базы данных MongoDB
В обычных базах данные хранятся в структурированном формате. Если же требуется хранить неструктурированные данные, на помощь приходят специальные БД, например MongoDB.
Что такое MongoDB
Многие базы данных относятся к реляционным и управляются с помощью языка SQL. В таких базах данные хранятся в строгих таблицах, связанных друг с другом разными способами. У них есть чёткая структура, под которую нужно подгонять все данные прежде чем внести их в базу.
В противовес им существуют нереляционные NoSQL базы, в которых данные хранятся в документах, связанных между собой ключами и более гибкой структурой. Для работы с такими базами нужны специальные СУБД, и MongoDB как раз из таких.
MongoDB была разработана в 2009 году в ответ на потребность компаний в масштабируемой СУБД для хранения неструктурированных данных. С тех пор вышло множество обновлений, и MongoDB по-прежнему пользуется огромной популярностью — по рейтингу портала DB-Engines, она входит в пять самых востребованных СУБД в мире.
В MongoDB данные хранятся неструктурированно, в виде специальных документов. Они записаны в формате BSON — это бинарная версия популярного формата JSON. Все документы в базе — это набор пар «поле—значение», где в качестве значения может быть что угодно, от чисел и дат до других вложенных документов. Неважно, в каком виде и формате создан документ — он спокойно «ляжет» в базу данных MongoDB без предварительной обработки.
Документы вместо строк
Если реляционные базы данных хранят строки, то MongoDB хранит документы. В отличие от строк документы могут хранить сложную по структуре информацию. Документ можно представить как хранилище ключей и значений.
Ключ представляет простую метку, с которым ассоциировано определенный кусок данных.
Однако при всех различиях есть одна особенность, которая сближает MongoDB и реляционные базы данных. В реляционных СУБД встречается такое понятие как первичный ключ. Это понятие описывает некий столбец, который имеет уникальные значения. В MongoDB для каждого документа имеется уникальный идентификатор, который называется _id. И если явным образом не указать его значение, то MongoDB автоматически сгенерирует для него значение.
Каждому ключу сопоставляется определенное значение. Но здесь также надо учитывать одну особенность: если в реляционных базах есть четко очерченная структура, где есть поля, и если какое-то поле не имеет значение, ему (в зависимости от настроек конкретной бд) можно присвоить значение NULL. В MongoDB все иначе. Если какому-то ключу не сопоставлено значение, то этот ключ просто опускается в документе и не употребляется.
Коллекции
Если в традиционном мире SQL есть таблицы, то в мире MongoDB есть коллекции. И если в реляционных БД таблицы хранят однотипные жестко структурированные объекты, то в коллекции могут содержать самые разные объекты, имеющие различную структуру и различный набор свойств.
Репликация
Вся система MongoDB может представлять не только одну базу данных, которая располагается на одном физическом сервере. Функциональность MongoDB позволяет расположить несколько баз данных на нескольких физических серверах, и эти базы данных смогут легко обмениваться данными и сохранять целостность.
Система хранения данных в MongoDB представляет набор реплик. В этом наборе есть основной узел, а также может быть набор вторичных узлов. Все вторичные узлы сохраняют целостность и автоматически обновляются вместе с обновлением главного узла. И если основной узел по каким-то причинам выходит из строя, то один из вторичных узлов становится главным.
Формат данных в MongoDB
Одним из популярных стандартов обмена данными и их хранения является JSON (JavaScript Object Notation). JSON эффективно описывает сложные по структуре данные.
BSON позволяет работать с данными быстрее: быстрее выполняется поиск и обработка. Хотя надо отметить, что BSON в отличие от хранения данных в формате JSON имеет небольшой недостаток: в целом данные в JSON-формате занимают меньше места, чем в формате BSON, с другой стороны, данный недостаток с лихвой окупается скоростью.
Кроссплатформенность
MongoDB написана на C++, поэтому ее легко портировать на самые разные платформы. MongoDB может быть развернута на платформах Windows, Linux, MacOS, Solaris. Можно также загрузить исходный код и самому скомпилировать MongoDB, но рекомендуется использовать библиотеки с официального сайта.
Простота в использовании
Отсутствие жесткой схемы базы данных и в связи с этим потребности при малейшем изменении концепции хранения данных пересоздавать эту схему значительно облегчают работу с базами данных MongoDB и дальнейшим их масштабированием. Кроме того, экономится время разработчиков. Им больше не надо думать о пересоздании базы данных и тратить время на построение сложных запросов.
Но, даже учитывая все недостатки традиционных баз данных и достоинства MongoDB, важно понимать, что задачи бывают разные и методы их решения бывают разные. В какой-то ситуации MongoDB действительно улучшит производительность вашего приложения, например, если надо хранить сложные по структуре данные. В другой же ситуации лучше будет использовать традиционные реляционные базы данных. Кроме того, можно использовать смешенный подход: хранить один тип данных в MongoDB, а другой тип данных - в традиционных БД.
GridFS
Одной из проблем при работе с любыми системами баз данных является сохранение данных большого размера. Можно сохранять данные в файлах, используя различные языки программирования. Некоторые СУБД предлагают специальные типы данных для хранения бинарных данных в БД (например, BLOB в MySQL).
В отличие от реляционных СУБД MongoDB позволяет сохранять различные документы с различным набором данных, однако при этом размер документа ограничивается 16 мб. Но MongoDB предлагает решение - специальную технологию GridFS, которая позволяет хранить данные по размеру больше, чем 16 мб.
Система GridFS состоит из двух коллекций. В первой коллекции, которая называется files, хранятся имена файлов, а также их метаданные, например, размер. А в другой коллекции, которая называется chunks, в виде небольших сегментов хранятся данные файлов, обычно сегментами по 256 кб.
Для тестирования GridFS можно использовать специальную утилиту mongofiles, которая идет в пакете mongodb.
Преимущества MongoDB
- Это простая в установке, использовании и без схемы базы данных.
- Благодаря возможности базы данных без схемы, код, который мы создаем, определяет схему.
- Данные хранятся в двоичном формате JSON, который представляет собой пару ключ-значение, сложность соединений не требуется.
- Он использует оперативную память для хранения данных, это делает более быстрый доступ к данным.
- Может использоваться для балансировки нагрузки.
- Он поддерживает свойство ACID (атомарность, согласованность, изоляция и долговечность) для транзакции базы данных.
- Он поддерживает репликацию, если основной сервер отключается во время транзакции, тогда вторичный сервер обрабатывает транзакцию без участия человека.
- Это экономически выгодно, поскольку снижает стоимость оборудования и хранилища.
- Это может сохранить много данных, которые помогут в более быстрой обработке запросов.
- Данные хранятся в узлах кластера, поэтому на сервере базы данных не будет единой точки отказа.
- Благодаря динамической схеме вы можете попробовать новые вещи с меньшими затратами. Вам не нужно беспокоиться о подготовке данных, прежде чем экспериментировать с ними.
Почему мы используем MongoDB?
- MongoDB - это база данных NoSQL, она может хранить данные в формате документа. Эта база данных является гибкой в использовании, когда требуется обработка больших объемов данных, поскольку она обеспечивает высокопроизводительное решение для хранения данных.
- Он хранит данные в формате документа, поэтому мы можем изменить любое количество записей, добавить или удалить существующие поля в таблице. Он может легко хранить сложные структуры, получать данные более точно.
- Индексация выполняется для повышения производительности запросов или поисков в базе данных.
- Он может хранить любые данные любого размера.
- Используется схема динамической базы данных, которая называется BSON.
- Он поддерживает репликацию там, где работает ведущий-ведомый. Мастер читает и пишет, подчиненный копирует данные с мастера, и он будет использоваться только для чтения.
- Авто-шардинг присутствует и будет использоваться, если у нас большие данные распределены по нескольким серверам и если сервер не может обрабатывать данные. Это не приведет к сбою.
- Он поддерживает горизонтальное масштабирование, что приведет к распределению больших данных на несколько машин.
Где мы используем MongoDB?
- Если вы собираетесь создать проект базы данных с небольшим бюджетом, MongoDB - лучшая база данных NoSQL для настройки, управления и работы с ней.
- MongoDB имеет мощную обработку запросов, поэтому она поможет выяснить, откуда поступают данные, и извлечь данные из определенного места.
- Если у вас есть сервис облачного хостинга, то вам следует настроить MongoDB с рекомендациями по безопасности, потому что сервисы облачного хостинга являются интернет-доступными серверами.
- Мы можем использовать MongoDB, не беспокоясь о мелких деталях, таких как обеспечение целостности, хотим создать базу данных с кучей документов.
- The New York Times, Agraroom, портал Российские Технологии используют MongoDB в приложениях для построения форм. Например, фото представлений.
- Используется для внутреннего хранения. Например, сайт sourceforge.net использует его.
- Shutterfly использует MongoDB различные постоянные требования к хранению данных.
- Он используется в сайтах социальных сетей, таких как Facebook, Рутвит, Pagelook, Instagram, потому что этот сайт социальной сети генерирует терабайт данных каждую минуту.
- Он используется для обсуждения вопросов и ответов на форуме, например Quora.
Вывод - преимущества MongoDB
MongoDB - это надежная база данных, которая рекомендуется при разработке веб-приложения, которое масштабируется и требует большой базы данных для хранения огромного количества неструктурированных данных. Если пользователь ищет наилучшую доступность, быструю обработку, хорошее резервное копирование, нулевую потерю информации, тогда MongoDB - лучшее решение для использования.
Преимущества базы данных MongoDB
Напишите нам прямо сейчас, наши специалисты расскажут об услугах и ответят на все ваши вопросы.
Комментарии и отзывы экспертов
Вам может быть интересно
В этой статье разработчики компании DST Global обсудят ускорение и масштаб в СУБД, две фундаментальные концепции из параллельной обработки для баз данных, которые используются для настройки баз дан...
Тестирование — это сквозная проблема; Как и базы данныхОчень важно последо...
Двоичное квантование в векторных базах данных повы...
В этой статье вы узнаете от разработчиков компании...
Узнайте о преимуществах от разработчиков компании ...
Oracle — самая популярная база данных в мире...
Повысьте производительность и масштабируемость, ис...
В этом комплексном сравнении от разработчиков комп...
: создание эффективных практик разработки и обслуж...
В этой статье рассматривается, что такое потоковая...
Базы данных (БД) — способ хранения и организ...
Новые комментарии
Сегодня специалисты разных сфер внедряют LLM в свои повседневные задачи. С их по...
Параметры LLM можно сравнить с нейронными связями: чем их больше, тем “умнее” мо...
Насколько понимаю самые популярные опенсорсные модели сегодня: — GPT-J: ра...
Если MongoDB такая классная, почему ее не используют все и всегда?
Выбор СУБД зависит в том числе и от того, что за приложение планируется создать. То есть базу данных выбирают не разработчики, а сам продукт, убежден Дандала. Он приводит пример, подтверждающий этот тезис.
При создании приложения, концепция которого подразумевает работу с документами, MongoDB будет хорошим выбором. К такому типу приложений можно отнести, к примеру, движок блог-платформы, где каждый автор сможет иметь по несколько блогов, и каждый из них будет содержать множество комментариев. База данных для обслуживания такого приложения должна быть легко расширяемой, и здесь MongoDB подойдет как нельзя лучше.
Однако, необходимо отметить, что у MongoDB нет связей между документами и “коллекциями” (частично это компенсируется Database Reference — ссылками в СУБД, но это не полностью решает проблему). В итоге, возникает ситуация, при которой имеется некий набор данных, который никак не связан с другой информацией в базе, и не существует никакого способа объединить данные из различных документов. В SQL-системах это было бы элементарной задачей.
Здесь возникает другой вопрос — если в MongoDB нет связей и возможностей по объединению двух таблиц, то зачем ее тогда вообще использовать? Ответ — потому что эта СУБД отлично масштабируется, и по сравнению с традиционными SQL-системами, гораздо быстрее осуществляет чтение и запись.MongoDB прекрасно подходит для приложений, в которых практически не используются данные с зависимостями и необходима масштабируемость базы данных.
Многие разработчики применяют MongoDB и для хранения связанных данных, реализуя объединения вручную в коде — этого достаточно в сценариях «одноуровневого» объединения или малого количества связей. То есть данный метод далеко не универсален.
Так какую СУБД выбрать?
Существует огромное количество различных СУБД, и каждая из них соответствует определённому набору требований, которые разработчики предъявляют к своему приложению:
— Документоориентированные СУБД (к примеру, MongoDB): Как уже сказано выше, документоориентированные СУБД используются для хранения JSON-документов в “коллекциях” и осуществления запросов по нужным полям. Можно использовать эту базу данных для создания приложений, в которых не будет содержаться слишком большого количества связей. Хорошим примером такого приложения является движок для блог-платформы или хранения каталога продуктов.
— Графовые СУБД (например Neo4j): Графовая СУБД используется для хранения между субъектами, где узлы являются субъектами, а грани — связями. Например, если разработчики создают социальную сеть, и один пользователь подписывается на другого, то пользователи являются узлами, а их “подписка” — связью. Такие СУБД прекрасно справляются с образованием связей, даже если глубина таких связей более ста уровней. Этот инструмент столь эффективен, что может даже позволяет выявлять мошенничество в сфере электронной коммерции.
— Кэш (например Redis): Такие СУБД используются, когда требуется крайне быстрый доступ к данным. Если создается приложение для интернет-торговли, в котором есть подгружаемые на каждой страницы категории, то вместо обращения к базе данных при каждом чтении, что крайне затратно, можно хранить данные в кэше. Он позволяет быстро осуществлять операции чтения/записи. Дандала советует применять СУБД, использующие кэш, в качестве оболочки для обработки часто запрашиваемых данных, избавляющей от необходимости совершения частых запросов к самой базе.
— Поисковые СУБД (например ElasticSearch): В случае необходимости осуществления полнотекстового поиска по базе данных (например поиск продукции в ecommerce-приложении), то хорошей идее будет использование поисковой СУБД вроде ElasticSearch. Эта система способна искать по огромному массиву данных и обладает обширной функциональностью — например, СУБД умеет осуществлять поиск по именованным категориям.
— Строковые СУБД (например Cassandra): СУБД Cassandra используется для хранения последовательных данных, логов, или огромного объема информации, который может генерироваться автоматически — к примеру, каким-нибудь датчиками. Если разработчики собираются использовать СУБД для записи больших массивов данных и при этом планируется, что будет намного меньше обращений для чтения и данные не будут иметь связи и объединения, тогда Cassandra будет хорошим выбором, уверен Дандала.
Существуют и ситуации, в которых может понадобиться использование сразу нескольких различных СУБД.
Например, если в приложении есть функция поиска, то его можно реализовать с помощью ElasticSearch, а уже для хранения данных без связей лучше подойдет MongoDB. Если речь иет о проекте в сфере «интернета вещей», где огромное количество всевозможных устройств и датчиков генерируют гигантские объёмы данных, вполне разумно будет использовать Cassandra.
Принцип, при котором используются несколько СУБД для работы в одном приложении, называется “Polyglot Persistence”. В этой статье можно почитать о плюсах и минусах такого подхода.
Наш опыт
Наша биллинговая система использует для учета первичных данных и хранения финансовой информации реляционную СУБД. Она идеально подходит для этих целей. Но некоторые модули Гидры, например, RADIUS-сервер, работают под высокой нагрузкой и могут получать тысячи запросов в секунду с жесткими ограничениями на время обработки запроса. Кроме того, в БД нашего автономного RADIUS-сервера данные хранятся в виде набора AVP (attribute/value pair). В таком сценарии реляционная СУБД уже не выглядит лучшим решением, и тут на помощь приходит MongoDB с ее хранилищем документов произвольной структуры, быстрой выдачей ответа и горизонтальной масштабируемостью.
При эксплуатации более чем на 100 инсталляциях Гидры на протяжении последних 5 лет серьезных проблем с Mongo мы не обнаружили. Но пара нюансов все же есть. Во-первых, после внезапного отключения сервера БД хоть и восстанавливается благодаря журналу, но происходит это медленно. К счастью, необходимость в этом возникает нечасто. Во-вторых, даже при небольшом размере БД редко используемые данные сбрасываются на диск и когда запрос к ним все же приходит, их извлечение занимает много времени. В результате нарушаются ограничения на время выполнения запроса.
Все это относится к движку MMAPv1, который применяется в Mongo по умолчанию. С другими (WiredTiger и InMemory) мы пока не экспериментировали — проблемы не настолько серьезны.
Так это как раз плохой пример. У монги же лок на запись на уровне документа. Причём как я понял из доков, лок на уровне документа доступен на движке WiredTiger, по-умолчанию лок на базу до сих пор (или я не там читал?)
Что если сразу куча народу захочет написать или подредактировать комменты? А если кто-то начнёт удалять свой коммент, а ему в этот момент начнут отвечать?
Вот и вышло, что мы снова вернулись к плоским таблицам и связям между ними. Ну а зачем на монге (у которой нет нормальных транзакций и джойнов) пытаться эмулировать реляционные БД, если можно взять просто реляционную БД сразу.
Вы привели самый простой способ организации хранения данных в данном случае, на самом деле их больше.
Обычно выбирают родительский пост и плоский список комментариев, затем их превращают в дерево уже на уровне языка программирования. Обычно комментариев немного, случаи вроде этого — исключения, но и они решаемы. В любом варианте, отдача десятков тысяч комментариев на странице просто убьет браузер, особенно на телефоне.
MongoDB используется на доске объявлений Craigslist, как вы понимаете, там особых связей не нужно. Плоская структура для сайта с гигантской посещаемостью и огромным количеством данных.
MongoDB подойдет там, где база растет, документы не требуют связности и их структура варьируется достаточно сильно. Представьте, что вам нужно добавить новое поле для 10 записей в таблице MySQL с триллионом записей. При этом у вас 100 обращений в секунду на чтение к этой таблице. Как вы будете решать такую задачу без блокировок? Предполагаю, что будет некоторый простой в работе сервиса.
Кроме того, если вам не нужны предикаты и агрегации по новым полям, то поля можно и не добавлять, а воспользоваться полем типа json или xml.