В чем особенности MongoDB и когда эта база данных вам подходит: руководство для новичков
Подготовили небольшой гайд по СУБД MongoDB: вы узнаете, в чем ее особенности, плюсы и недостатки, для каких проектов она подходит, а когда лучше выбрать реляционную базу данных.
Что такое база данных MongoDB и в чем ее особенности
MongoDB — документоориентированная система управления базами данных с открытым исходным кодом. Для хранения данных используется JSON-подобный формат. Эта СУБД отличается высокой доступностью, масштабируемостью и безопасностью.
Главные особенности MongoDB:
- Это кроссплатформенная документоориентированная база данных NoSQL с открытым исходным кодом.
- Она не требует описания схемы таблиц, как в реляционных БД. Данные хранятся в виде коллекций и документов.
- Между коллекциями нет сложных соединений типа JOIN, как между таблицами реляционных БД. Обычно соединение производится при сохранении данных путем объединения документов.
- Данные хранятся в формате BSON (бинарные JSON-подобные документы).
- У коллекций не обязательно должна быть схожая структура. У одного документа может быть один набор полей, в то время как у другого документа — совершенно другой (как тип, так и количество полей).
В одном документе могут быть поля разных типов данных, данные не нужно приводить к одному типу. Основное преимущество MongoDB заключается в том, что она может хранить любые данные, но эти данные должны быть в формате JSON.
Пример документа в MongoDB
На схеме показано, как выглядит документ в MongoDB:
MongoDB добавляет поле _id с уникальным значением для идентификации документа в коллекции. Это поле обязательно для заполнения в каждом документе. Оно похоже на первичный ключ документа. Если вы создаете новый документ без поля _id, то MongoDB автоматически создаст его и добавит 24-значный уникальный идентификатор к каждому документу в коллекции.
Обратите внимание: сами данные заказа (OrderID, Product и Quantity) в MongoDB фактически хранятся как встроенный документ в самой коллекции, а в реляционных СУБД они обычно хранятся в отдельной таблице. Это одно из ключевых особенностей модели данных MongoDB.
Структура хранилища MongoDB
СУБД MongoDB полагается на концепции базы данных, коллекций и документов. Рассмотрим основные термины, а для лучшего понимания сравним их с терминами из языка структурированных запросов (SQL):
- База данных — это физический контейнер для коллекций.
- Коллекция — группа документов MongoDB. В терминологии SQL это соответствует таблице.
- Документ — запись в коллекции MongoDB, набор пар ключ-значение. В терминологии SQL это похоже на строку в таблице базы данных.
- Поле — ключ в документе. В терминологии SQL похоже на столбец в таблице.
- Встроенный документ — в терминологии SQL похоже на создание связей между несколькими таблицами, по которым разбросаны данные, что делается операциями JOIN.
Зачем использовать MongoDB: преимущества этой СУБД
Ниже приведены несколько причин, по которым стоит использовать MongoDB:
- Документоориентированная база — сохранение данных в формате документов вместо формата реляционного типа, это делает MongoDB очень гибкой и адаптируемой к бизнес-требованиям. Возможность хранения разных типов данных особенно важна при работе с большими данными, которые собираются из разных источников и не ложатся в одну структуру.
- Специальные запросы — MongoDB поддерживает поиск по полям, диапазонные запросы и поиск по регулярным выражениям. Могут быть сделаны запросы для возврата определенных полей в документах.
- Индексация — можно создать индексы для улучшения производительности поиска в MongoDB. Любое поле в документе может быть проиндексировано. Это обеспечивает высокую скорость работы СУБД.
- Репликация — эта СУБД может обеспечить высокую доступность с помощью наборов реплик. Набор реплик состоит из двух или более экземпляров MongoDB. Каждая реплика набора может выступать в роли первичной или вторичной. Первичная реплика — главный сервер, который взаимодействует с клиентом и выполняет все операции чтения/записи. Вторичные реплики сохраняют копию данных первичной реплики с помощью встроенной репликации. Если с первичной репликой что-то случилось, происходит автоматическое переключение на вторичную реплику, затем она становится основным сервером.
- Балансировка нагрузки — MongoDB использует концепцию шардинга для горизонтального масштабирования с помощью разделения данных между несколькими экземплярами БД. Она может работать на нескольких серверах, балансируя нагрузку и/или дублируя данные, чтобы поддерживать работоспособность системы в случае аппаратного сбоя.
- Возможность развернуть в облаке — вы получаете готовую к работе, оптимально сконфигурированную, масштабируемую и управляемую базу данных по запросу за две минуты.
- Доступность — MongoDB поддерживает все популярные языки программирования, ее можно использовать бесплатно как open source решение.
Недостатки MongoDB
Вот основные минусы MongoDB:
- Эта база данных не настолько соответствует требованиям ACID (атомарность, согласованность, изолированность и устойчивость), как реляционные базы данных.
- Транзакции с использованием MongoDB являются сложными
- В MongoDB нет положений о хранимых процедурах или функциях, поэтому не получится реализовать какую-либо бизнес-логику на уровне базы данных, что можно сделать в реляционных БД.
Когда стоит и не стоит использовать MongoDB
MongoDB часто выбирают, когда нужна масштабируемая база данных, в настоящее время ее используют в качестве хранилища внутренних данных многие организации, такие как IBM, Twitter, Zendesk, Forbes, Facebook, Google и другие.
Примеры, когда MongoDB подходит для проекта:
- Каталог товаров в электронной коммерции.
- Блоги и системы управления контентом, особенно те, где много контента, в том числе видео и изображений.
- Аналитика в реальном времени и высокоскоростное журналирование, кэширование данных и кейсов, когда важна высокая масштабируемость системы.
- Хранение данных датчиков и устройств.
- Работа с большими данными для машинного обучения и исследований в ритейле и других отраслях.
- Ведение данных на основе местоположения, то есть геопространственных данных.
- Социальные сети, новостные форумы и другие похожие сценарии.
- Слабосвязанные данные без четкой схемы хранения.
- Стартапы и развертывание новых проектов, где структура данных пока неизвестна.
MongoDB
MongoDB — это документоориентированная система управления базами данных, которая не требует описания схемы таблиц. Считается одним из классических примеров NoSQL-систем, использует JSON-подобные документы и схему базы данных. Написана на языке C++.
Освойте профессию
«Fullstack-разработчик на Python»
MongoDB имеет открытый исходный код, она бесплатная и доступна любому разработчику. СУБД подходит для операционных систем семейства Linux, Windows и macOS. Ей можно пользоваться в облаке. Название читается как «Монго-ДБ».
Кто пользуется MongoDB
- Бэкенд-разработчики веб-приложений и сайтов. В основном СУБД MongoDB используется в веб-программировании.
- Специалисты в области Big Data и аналитики, которые работают с большим количеством не связанной друг с другом информации.
- Разработчики в стартапах, где четко не определена структура хранения данных — в любой момент может потребоваться ее изменение.
- DevOps-инженеры — иногда знание MongoDB может быть необходимо при работе с инфраструктурой проекта.
Профессия / 8 месяцев
IT-специалист с нуля
Попробуйте 9 профессий за 2 месяца и выберите подходящую вам
Для чего нужна MongoDB
- Хранение данных, которые не жестко связаны между собой.
- Управление данными: создание новых записей, их редактирование, удаление, контроль версий.
- Получение данных с помощью запросов без использования SQL.
- Отправка транзакций — последовательностей из нескольких запросов, которые выполняются один за другим.
- Быстрый, удобный и простой доступ к данным.
- Контроль доступа и поддержки безопасности данных.
- Выдача прав разным категориям пользователей.
- Поддержка базы в актуальном состоянии, в том числе при одновременном доступе с нескольких клиентов.
Отличие от реляционных баз данных
В реляционной базе данных информация представлена как набор связанных между собой таблиц. Доступ к данным осуществляется с помощью запросов на языке SQL. Реляционная модель — традиционная, ее используют чаще всего. Но для многих задач она неоптимальна, например, если связи между разными данными не жесткие.
В MongoDB реализована система, при которой данные хранятся в «табличных» документах форматов, близких к JSON. Информация записывается в виде пар из ключей и значений — как в таблице, в которой есть идентификаторы и соответствующие им данные. Благодаря такому формату в MongoDB можно разместить очень разнообразную и сложно структурированную информацию: документ — более гибкая структура.
При работе с такими базами SQL не используется, отсюда название NoSQL. Вместо него применяют языки программирования. В случае с MongoDB это JavaScript. Существуют драйверы для поддержки других популярных языков: Python, Java, C/C++, Go, PHP, Ruby и прочих.
Как устроено хранение данных в MongoDB
Вместо традиционных понятий таблиц и полей в MongoDB используются свои сущности. Они отличаются от принятых в реляционных базах данных, но во многом схожи.
_id. Это идентификатор, который должен быть в каждом документе. Он помогает обращаться к тем или иным данным, по нему записи отличают друг от друга. Идентификатор создается автоматически, если его не задает программист при создании нового документа. В реляционных базах тоже есть идентификатор, но он называется иначе — первичный ключ.
Поле. Это одна запись в документе, если точнее, один ключ, метка, которой соответствует определенный набор данных. Понятие можно сравнить со столбцом в таблице реляционной базы. Например, если документ описывает данные о нескольких собаках, то в нем могут быть поля «Порода», «Кличка», «Возраст» и другие.
Описанный выше идентификатор — одно из полей, которые есть в документе, причем обязательное.
Документ. Один документ — это файл в формате BSON: название расшифровывается как binary JSON, или бинарный JSON. Отличие от стандартного JSON в том, что формат работает еще быстрее, но файлы в нем занимают меньше места.
В документе хранятся однотипные строго структурированные записи: ключи и значения. Выше мы привели пример с собаками: если документ посвящен им, то в нем будет только определенная информация о собаках и ничего другого. Его можно сравнить со строкой в таблице реляционной базы данных. Но в отличие от строки документ может хранить сложную по структуре информацию, а еще он более гибкий — для отдельных записей можно, например, опускать те или иные поля.
Максимальный размер документа — 16 Мб. Для сохранения данных большего размера используется технология GridFS, о которой мы поговорим ниже.
Коллекция. Вместо таблиц в MongoDB используются коллекции. Это наборы из документов. В одном наборе могут храниться документы с разнообразными данными — это главное отличие от таблиц. Коллекция разнородна, документы внутри нее могут различаться структурой, размером, значениями и связями. Поэтому MongoDB считается отличным выбором для хранения слабо структурированной информации.
Встроенный документ. В базах данных, которые управляются SQL, есть операция JOIN, объединяющая между собой сведения из разных таблиц. В MongoDB другая структура: обычно все находится внутри одной коллекции, а операции JOIN не предусмотрено. Для связей и разделений используются встроенные документы — структуры встраиваются друг в друга.
База данных. Так называется общее хранилище, где находятся коллекции, в которых, соответственно, расположены документы. У баз в MongoDB есть интересная особенность: когда база создана, но в нее ничего не записано, она де-факто не существует. Это отличает ее от пустых реляционных баз, которые существуют, даже если в них ничего нет.
Станьте дата-сайентистом и решайте амбициозные задачи с помощью нейросетей
Особенности MongoDB
Индексация. Данные внутри базы можно индексировать — так система быстрее найдет к ним доступ. Для данных создаются индексы, специальные объекты, которые хранят указатели на ту или иную информацию: обычно это конкретные значения и ссылки на них. Благодаря индексам можно реализовать поиск по базе, он не будет выглядеть как простой перебор всех данных. Это ускоряет работу системы.
Репликация. Так называется возможность работы с репликами — копиями базы данных. Можно иметь несколько связанных друг с другом копий БД на разных серверах, и одна из них будет главной, а остальные — вспомогательными. Изменения сначала будут вноситься в главную базу, а потом передаваться другим. В итоге, если с основной копией что-то случится, любая существующая реплика сможет ее заменить — так в системе поддерживается стабильность. Замена происходит автоматически.
Сегментирование. Репликация — не единственный способ хранить базу MongoDB на разных серверах. Система поддерживает сегментирование, то есть разделение базы данных на отдельные сегменты и их распределение по разным серверам. Это позволяет балансировать нагрузку на мощности. Принцип разбиения определяет администратор, поэтому распределение по разным частям серверного кластера тоже можно спланировать.
Запросы ad hoc. Латинские слова означают «специально для этого», поэтому такие запросы еще называют специальными. Одна из особенностей MongoDB — гибкая поддержка разнообразных запросов. СУБД принимает запросы на поиск по разным полям, работает с функциями JavaScript и может возвращать пользовательские функции в ответ на запрос. Она поддерживает регулярные выражения. MongoDB позволяет получить в качестве ответа диапазон или случайное значение — запросы могут быть в том числе очень сложными.
Grid File System. Сокращенно эта технология называется GridFS, мы упоминали ее выше. Речь шла о том, что максимальный размер документа в MongoDB — 16 Мб, а технология применяется, если нужно сохранить в базу более объемные данные. По сути, это то же сегментирование, но в рамках документа. Массивные данные хранятся в двух коллекциях: files и chunks:
- files — коллекция, в которой находятся сведения о файлах. Это их имена и метаданные, содержащие информацию об объеме и других параметрах;
- chunks — коллекция, где хранятся сами файлы, но не целиком, а разбитые на небольшие сегменты. Размер каждого сегмента обычно 256 Кб, но эта цифра может меняться.
Благодаря такому разделению на маленькие составные части в базе можно хранить даже очень большие файлы. Это позволяет обойти максимальный размер документа в 16 Мб.
Преимущества MongoDB
Быстрая работа. Благодаря структуре документов, поддержке индексации и другим особенностям MongoDB работает быстро, без задержек. База производительна, часто используется во внутренних системах, на сайтах — там, где скорость имеет значение.
Гибкость. MongoDB позволяет хранить разнородные данные, поэтому она гибкая и легко адаптируется под разнообразные задачи. Например, если информация не укладывается в общую структуру или собирается разными способами и сильно различается, MongoDB все равно позволит успешно хранить ее и получать доступ.
Легкая масштабируемость. Причина, по которой MongoDB пользуются стартапы и небольшие компании, — возможность быстро и легко масштабировать систему. Если информация в базе должна измениться, например, планируется добавить новое поле, не нужно радикально перекраивать структуру всей БД. Это возможно благодаря документно-ориентированной модели и особому формату данных.
Отсутствие сложных соединений. В MongoDB не нужно описывать схему таблиц. Конструкции вроде JOIN не используются. В реляционных базах JOIN соединяет между собой данные из разных таблиц, но при документно-ориентированной модели необходимость в таких соединениях отсутствует.
Возможность работы на нескольких серверах. Это возможно благодаря механизмам репликации и сегментирования. Первый позволяет создавать работающие копии базы, которым в любой момент можно передать управление; второй помогает грамотно распределять нагрузку. Такие возможности делают работу системы стабильнее и снижают риск отказа базы в важный момент.
Недостатки MongoDB
Отсутствие хранимых процедур и функций. Хранимые процедуры — это возможность реляционных баз данных: разработчик один раз пишет набор команд на языке SQL, сохраняет его, а потом может вызвать в любой момент. Получается подобие скрипта, который выполняется по команде. Поддержка хранимых процедур в MongoDB не предусмотрена, и это не дает в полной мере автоматизировать работу с БД.
Пользовательские функции, или UDF, похожи на хранимые процедуры, но различаются особенностями сохранения и вызова. Их можно реализовать самостоятельно — функции, написанные на JavaScript, сохраняются с помощью специальной команды и позднее используются снова. Правда, это сложнее, чем возможность работать с ними «из коробки».
Неполное соответствие ACID. ACID — это набор принципов для баз данных, соответствие которым делает систему стабильной и предсказуемой. Принципов всего четыре: атомарность, согласованность, изолированность, устойчивость. MongoDB, в отличие от распространенных реляционных СУБД, соответствует им не полностью. До версии 4.0 система не отвечала требованиям атомарности — они требуют, чтобы никакая транзакция не «зависала» в системе завершенной не до конца. В более поздних версиях это исправили.
Сложности с транзакциями. Документно-ориентированный подход дает много плюсов, но из-за него сначала было затруднительно работать с транзакциями. В старых версиях их ACID-реализации не было, поэтому многие считали, что при NoSQL-подходе транзакции отсутствуют в принципе. Позже они появились, но работа по-прежнему имеет специфику.
Трудности при работе с жестко связанными данными. У разных документов внутри коллекции может быть совершенно различная структура, и сами коллекции не обязаны походить друг на друга. Это упрощает хранение слабо связанной информации, но если данные имеют жесткие связи между собой, подход перестает быть удобным. В этих ситуациях лучше отдавать предпочтение традиционным СУБД, которые работают с SQL.
Как начать работу с MongoDB
- Скачать MongoDB на официальном сайте проекта, где компания представляет СУБД и другие решения, в том числе коммерческие. Можно воспользоваться официальным репозиторием MongoDB на GitHub или пакетным менеджером. В macOS это brew, в Linux — apt-get и другие.
- Скачать MongoShell — шелл-оболочку, которая позволяет отдавать команды. Она скачивается отдельно и тоже есть на официальном сайте.
- Установить MongoDB и шелл-оболочку на сервер, где будет храниться база. В реальных проектах обычно это арендованные на хостингах мощности. Создать тестовую базу данных для тренировки можно и на собственном устройстве.
Взаимодействие с базой обычно происходит через терминал. Можно подключить модули для поддержки разных языков программирования, но по умолчанию язык запросов для MongoDB — это JavaScript. Операторы, с помощью которых управляют базой данных MongoDB, основаны на нем.
Fullstack-разработчик на Python
Fullstack-разработчики могут в одиночку сделать IT-проект от архитектуры до интерфейса. Их навыки востребованы у работодателей, особенно в стартапах. Научитесь программировать на Python и JavaScript и создавайте сервисы с нуля.
Статьи по теме:
За и против: Когда стоит и не стоит использовать MongoDB
Разработчик и сотрудник проекта CouldBoost.io Наваз Дандала (Nawaz Dhandala) написал материал о том, почему в некоторых случаях не стоит использовать MongoDB. Мы в «Латере» развиваем биллинг для операторов связи «Гидра» и уже много лет работаем с этой СУБД, поэтому решили представить и свое мнение по данному вопросу.
Дандала сразу оговаривается, что работал со многими СУБД (как SQL, так и NoSQL) и считает MongoDB отличным инструментом, однако существуют сценарии, в которых его применение нецелесообразно.
Документоориентированные СУБД такие, как MongoDB, прекрасно справляются с хранением JSON-данных, сгруппированных в «коллекции». В таком формате можно хранить любые JSON-документы и удобно категоризировать и по коллекциям. Содержащийся в MongoDB JSON-документ называется двоичным JSON или BSON и, как любой другой документ этого формата, является неструктурированным. Поэтому, в отличии от традиционных СУБД, в коллекциях можно сохранять любые виды данных, и эта гибкость сочетается с горизонтальной масштабируемостью базы данных. Эта возможность нравится многим разработчикам, однако «не все так однозначно».
Если 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) мы пока не экспериментировали — проблемы не настолько серьезны.
В чем разница между MongoDB и MySQL?
MongoDB и MySQL – это две системы управления базами данных, которые можно использовать для хранения данных и управления ими. MySQL – это реляционная база данных, в которой данные хранятся в структурированном табличном формате. В отличие от нее, MongoDB хранит данные в виде документов JSON в более гибком формате. Оба типа баз данных обеспечивают эффективность и масштабируемость, но наилучшие показатели их работы соответствуют различным вариантам использования.
В чем сходство между MongoDB и MySQL?
И MySQL, и MongoDB являются системами управления базами данных. Они хранят данные и имеют встроенный пользовательский интерфейс и язык запросов, что позволяет добавлять, редактировать, изменять и анализировать данные.
Лицензии с открытым исходным кодом
MySQL и ранние версии MongoDB имеют лицензии с открытым исходным кодом. Версии с открытым исходным кодом можно скачать бесплатно. Затем вы можете изменить код в зависимости от того, что вам нужно с ним делать.
На MySQL распространяется лицензия General Public License GNU. Все версии MongoDB, выпущенные до 16 октября 2018 г., доступны под лицензией GNU Affero General Public License.
Поддержка индексирования
MySQL и MongoDB используют индексацию для повышения скорости и производительности запросов. Индексы – это структуры баз данных, которые связываются с часто используемыми данными. Индекс помогает очень быстро находить и извлекать данные.
Платформы баз данных MySQL и MongoDB используют хэш-индексы, индексы B-дерева и ряд других.
Удобные интерфейсы
MongoDB и MySQL просты в использовании. Они предлагают язык запросов на основе естественного языка для обновления и чтения данных. Они также предлагают графический пользовательский интерфейс (GUI) для более визуального управления данными и их анализа.
Языки программирования
MySQL и MongoDB совместимы с несколькими одинаковыми языками программирования. Можно использовать Java, Python, Node.js, PHP на стороне сервера, Ruby и C# как с MongoDB, так и с MySQL.
Безопасность
MySQL и MongoDB используют аутентификацию, контроль доступа и шифрование для гарантии безопасности своих баз данных. Они используют шифрование TLS/SSL для защиты данных в движении и в местах хранения. Они также позволяют определять различные уровни доступа пользователей.
Документация и поддержка сообщества
MySQL и MongoDB содержат подробную официальную документацию на своих сайтах. Их пособия, руководства и справочники предлагают полные инструкции по установке, настройке и выполнению оперативных задач.
У MongoDB и MySQL также есть активное сообщество разработчиков, в котором вам ответят на вопросы и помогут в устранении неполадок. Оба решения также предлагают корпоративные версии со специальной поддержкой, отвечающей вашим конкретным требованиям.
Ключевые отличия MongoDB и MySQL
MySQL – это система управления реляционными базами данных, а MongoDB – это система баз данных NoSQL. Подробнее об этом можно прочитать в разделах Что такое реляционная база данных? и Что такое NoSQL?.
MySQL использует SQL, с которым большинство разработчиков знакомы. И наоборот, MongoDB использует язык запросов MongoDB (MQL). Хотя между MQL и SQL есть сходство, для изучения языка MQL обычно требуется дополнительные усилия.
Далее мы рассмотрим некоторые другие ключевые отличия.
Модель данных
MySQL – это реляционная система баз данных, которая хранит данные в столбцах, строках и таблицах. Данные хранятся в строках, причем каждый столбец представляет разные типы данных. Затем вы определяете отношения между данными с помощью внешних и первичных ключей. Каждая таблица содержит первичный ключ, который используется для ее идентификации, а внешний ключ создает связь.
MongoDB – это документно-ориентированная база данных, в которой все данные хранятся в виде двоичных документов JSON (BSON). BSON позволяет сериализовать множество форм данных. Использование документов BSON позволяет хранить неструктурированные, полуструктурированные и структурированные данные. Вместо схемы базы данных MongoDB использует гибкий подход, сохраняя документы в коллекциях.
Масштабируемость
В системе баз данных MySQL доступные варианты масштабирования ограничены. Вы можете выбрать один из следующих вариантов:
- Вертикальная масштабируемость за счет добавления дополнительных ресурсов к текущему серверу баз данных
- Репликация чтения путем создания копий базы данных, доступных только для чтения, на других серверах
Репликация чтения ограничена максимум пятью копиями. Реплики также могут отставать от основной копии, что приводит к масштабным проблемам с производительностью. Вертикальная масштабируемость также ограничена используемой инфраструктурой.
Напротив, конструкция MongoDB дает значительное преимущество с точки зрения масштабируемости. Решение имеет две ключевые функции для масштабирования:
- Наборы реплик – группы серверов MongoDB, содержащие идентичные данные
- Сегментирование – разные части данных, распределенные по разным серверам
MongoDB позволяет создавать сегментированные кластеры, поэтому части ваших данных реплицируются на нескольких серверах. Например, если у вас есть большое количество записей о клиентах, вы можете распределить их так, чтобы имена от A до J и имена от K до Z находились в собственном наборе реплик. Таким образом, MongoDB может масштабироваться по горизонтали для оптимизации производительности чтения и записи в нужном масштабе.
Производительность
Решение MySQL предназначено для высокопроизводительных объединений нескольких таблиц, которые надлежащим образом проиндексированы. Однако требуется вставлять данные по строкам, поэтому скорость записи снижается.
Документы MongoDB следуют иерархической модели данных и хранят большую часть данных в одном документе, что снижает необходимость объединения нескольких документов. Соединения поддерживаются операцией $lookup, но они не оптимизированы для повышения производительности. Однако MongoDB предлагает API insertMany() для быстрой вставки данных с приоритетным вниманием производительности записи.
Гибкость
Как система управления реляционными базами данных, MySQL имеет более жесткую структуру, чем MongoDB. MySQL использует фиксированную схему и организует данные в строку и таблицу. Чтобы использовать MySQL, необходимо структурировать данные и поместить их в табличную систему.
Сохраняя данные в виде документов JSON, MongoDB позволяет создавать сложные приложения с различными типами данных. Например, вы можете создавать новые поля, обновляя поля вложенного массива. Можно также использовать конвейер агрегирования – функцию MongoDB, которая позволяет преобразовывать данные, объединяя несколько операций в один рабочий процесс.
Контроль доступа
В MongoDB вы можете управлять доступом на уровне операции, коллекции или базы данных. Для аутентификации пользователей используются сертификаты Kerberos, X.509 и LDAP. Напротив, MySQL позволяет ограничить доступ пользователей на уровне пользователя, базы данных и таблицы. MySQL использует собственную систему аутентификации. Она представляет собой дополнительную уязвимость безопасности при атаках с внедрением SQL-кода, которой позволяет избежать подход MongoDB без схем.
Когда использовать MongoDB и MySQL
Формат хранения данных в MySQL делает его пригодным для хранения данных и аналитической обработки в режиме онлайн. Он совместим с ACID, что означает, что транзакции атомарны, последовательны, изолированы и долговечны. Поэтому решение MySQL полезно при работе со сложными транзакциями, например в электронной коммерции, транзакциях и финансах.
Высокоструктурированные данные и индексация MySQL также подходят для специальных запросов. Специальные запросы обычно выполняются конечными пользователями или аналитиками данных, которым требуется быстрый доступ к данным, недоступным в стандартных отчетах или запросах.
С другой стороны, MongoDB – это база данных NoSQL. Это более удобно при работе с неструктурированными данными в таких случаях использования, как социальные сети, СМИ или Интернет вещей (IoT). Поскольку у MongoDB нет схемы, это хороший выбор для работы с постоянно меняющимися и расширяющимися данными.