MongoDB: преимущества базы данных NoSQL

Cloud Server | Amber | Комментировать запись

В последние годы данные стали движущей силой технологий, поскольку современным приложениям и веб-сайтам необходимо управлять постоянно растущим объемом информации. Традиционно системы управления базами данных (СУБД) организовывают данные на основе реляционной модели. Однако по мере изменения потребностей компаний в данных был разработан ряд новых типов БД.

Новые типы часто не полагаются на традиционную структуру таблиц, предоставляемую реляционными базами данных, и поэтому могут обеспечить гораздо большую гибкость, чем жесткая структура реляционных БД. Кроме того, для определения и взаимодействия с информацией они обычно не используют язык структурированных запросов (Structured Query Language, SQL), который применяется в большинстве систем реляционных баз данных. Это привело к тому, что многие из новых нереляционных БД стали называться базами данных NoSQL.

Читайте также: 

• SQL, NoSQL и другие модели баз данных
• Модели и системы управления базами данных NoSQL

Впервые выпущенная в 2009 году, MongoDB — также известная как Mongo — документо-ориентированная NoSQL база данных, которая используется во многих современных веб-приложениях. В этой статье представлен обзор особенностей, которые отличают MongoDB от других СУБД и делают ее ценным инструментом в разных случаях использования.

Краткий обзор MongoDB

Как уже упоминалось ранее, MongoDB считается базой данных NoSQL, потому что она не зависит от реляционной модели. Каждая СУБД разрабатывается на основе определенного типа модели данных, которая определяет организованность информации в базе данных. Реляционная модель предполагает хранение информации в таблицах — более формально называемых отношения (relations) — состоящих из строк и столбцов.

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

Документ пишется на BSON, бинарном представлении JSON. Документы MongoDB, как и объекты в JSON, начинаются и заканчиваются фигурными скобками ({ и }), они содержат несколько пар “поле-значение”, которые обычно имеют форму field: value. Значение поля может быть представлено любым типом данных BSON или даже другими структурами, такими как документы и массивы.

Безопасность

MongoDB поставляется с функционалом, который может помочь предотвратить потерю информации и доступ неавторизованных пользователей. Некоторые из этих функций есть в других системах управления базами данных. Например, Mongo, как и многие современные СУБД, позволяет шифровать данные при их передаче по сети — иногда это называется “data in transit” (данные в пути). Для этого требуется, чтобы подключения к БД выполнялись с помощью криптографического протокола Transport Layer Security (TLS), наследника Secure Sockets Layer (SSL).

Также, как и другие СУБД, Mongo управляет авторизацией — устанавливает правила для пользователя или группы, чтобы определить, какие действия они могут выполнять и какие ресурсы им доступны — с помощью модели компьютерной безопасности, которая называется “управление доступом на основе ролей” (Role Based Access Control, RBAC). При создании пользователя MongoDB у вас есть возможность предоставить ему одну или несколько ролей.

Роль определяет привилегии пользователя, в том числе действия, которые он может выполнять с базой данных, коллекцией, набором коллекций или кластером. Например, вы можете назначить пользователю роль readWrite в любой БД, это значит, что он сможет читать и изменять данные в любой базе данных вашей системы. RBAC в MongoDB отличается от RBAC в других базах данных тем, что, помимо встроенных ролей, Mongo позволяет назначать пользовательские роли, что дает еще больше контроля над тем, к каким ресурсам учетные записи могут получить доступ в системе.

Начиная с версии MongoDB 4.2, на стороне клиента поддерживается шифрование на уровне полей. Это предполагает шифрование определенных полей в документе перед записью в базу данных. Любой клиент или приложение, которые позже попытаются прочитать такой документ, должны сначала предоставить правильные ключи шифрования, чтобы расшифровать данные в этих полях.

Для примера предположим, что БД содержит документ со следующими полями и значениями:

{
  "name" : "8host",
  "phone" : "555-555-1234",
  "creditcard" : "1234567890123456"
}

Хранить подобную конфиденциальную информацию — а именно номера телефонов и кредитных карт — в реальном приложении может быть опасно. Даже если вы ограничили доступ к базе данных, то любой пользователь с правами доступа к БД сможет увидеть эту информацию и использовать ее. Но при правильной настройке эти поля будут выглядеть примерно так, как если бы со стороны клиента они были записаны с помощью шифрования на уровне полей:

{
  "name" : "8host",
  "phone" : BinData6,"quas+eG4chuolau6ahq=i8ahqui0otaek7phe+Miexoo"),
  "creditcard" : BinData6,"rau0Teez=iju4As9Eeyiu+h4coht=ukae8ahFah4aRo="),
}

Гибкость

Еще одна характеристика MongoDB, которая способствовала росту ее популярности — это гибкость, которую она обеспечивает по сравнению с более традиционными СУБД. Эта гибкость обусловлена документо-ориентированным дизайном MongoDB, так как коллекции в Mongo не навязывают определенную структуру, которой должен следовать каждый документ. Это отличается от жесткой структуры таблиц в реляционной БД.

При создании таблицы в реляционной базе данных необходимо явно определить набор столбцов, которые таблица будет содержать, а также их типы данных. После этого каждая добавляемая строка данных должна соответствовать этой конкретной структуре. Но в MongoDB документы в одной и той же коллекции могут иметь разные поля, и даже если у них есть одно общее поле, оно может содержать разные типы данных в разных документах.

Жесткая структура реляционной модели не так плоха. На самом деле, она делает реляционные базы данных удобными для хранения той информации, которая четко соответствует предопределенной структуре. Но такой подход может вас ограничивать, когда вам нужно хранить неструктурированные данные — информацию, которую нелегко внести в предопределенные модели данных или которую трудно найти с помощью обычных инструментов.

Примеры неструктурированных данных включают мультимедийный контент: видео или фото, коммуникационные данные или текстовые файлы. Иногда неструктурированные данные называют качественными данными. Другими словами, это данные, которые могут быть понятны человеку, но компьютеру их анализировать трудно. Однако гибкий документо-ориентированный дизайн MongoDB делает ее отличным вариантом для хранения и анализа неструктурированных, структурированных и полуструктурированных данных.

Еще один пример гибкости Mongo — она предлагает несколько способов взаимодействия с информацией. Например, вы можете запустить оболочку mongo — интерфейс на базе JavaScript, который поставляется вместе с сервером MongoDB и позволяет работать с данными из командной строки.

Mongo также поддерживает ряд официальных драйверов, которые помогут подключить БД к приложению. В Mongo есть библиотеки для разных языков программирования: PHP, Java, JavaScript, Python и т. д. Эти драйверы обеспечивают поддержку типов данных основных языков, тем самым расширяя типы данных BSON, которые доступны по умолчанию.

Доступность

Любая компьютерная система баз данных зависит от базового оборудования для функционирования и удовлетворения потребностей приложения или клиента. Если машина, на которой она работает, по какой-либо причине выйдет из строя, то данные в БД будут недоступны до тех пор, пока машина не восстановит работу. Если СУБД может оставаться в рабочем состоянии в течение более длительного, чем обычно, периода времени, ее называют высокодоступной.

Читайте также: Что такое высокая доступность?

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

В MongoDB группа серверов, поддерживающих одинаковый набор данных через репликацию, называется набором реплик (replica set). Каждый запущенный экземпляр MongoDB, который является частью набора реплик, называется одним из его членов (узлов, или нод). Каждый набор реплик должен иметь один первичный узел и как минимум один вторичный.

Одно из преимуществ наборов реплик MongoDB по сравнению с вариантами репликации в других системах баз данных — автоматический механизм переключения в режим отказоустойчивости. В случае, если основной узел становится недоступным, среди вторичных узлов происходит автоматический процесс выбора новой первичной ноды.

Масштабируемость

База данных — один из основных компонентов современных приложений, а потому важно, чтобы она могла быстро реагировать на изменения в объеме работы: приложение может столкнуться с резким увеличением числа пользователей, появятся периоды особенно высокой нагрузки.

Масштабируемость описывает способность компьютерной системы справляться с постоянно растущим объемом работы, а увеличение этой способности называется масштабированием (scaling). Есть два способа масштабирования компьютерной системы:

• Вертикальное масштабирование (или масштабирование вверх) предполагает добавление дополнительных вычислительных ресурсов в систему, как правило, за счет увеличения емкости хранилища или памяти.
• Горизонтальное масштабирование (или масштабирование вширь) — это распределение рабочей нагрузки между несколькими вычислительными нодами, которые вместе составляют единую логическую систему.

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

Шардинг — это стратегия, которую некоторые администраторы используют для масштабирования базы данных; это процесс разбиения набора данных на основе заданного набора правил и распределение получившихся частей по нескольким отдельным нодам БД. Отдельная нода, на котором хранится часть набора данных кластера с шардингом, называется шардом.

Читайте также: Фрагментация базы данных: основные методы и случаи использования

СУБД не всегда включают встроенную функцию шардинга, поэтому часто он реализуется на уровне приложений. В MongoDB есть эта функция, она позволяет фрагментировать данные на уровне коллекции. Начиная с версии 3.6, каждый шард MongoDB должен быть развернут как набор реплик, чтобы обеспечить высокую доступность данных.

Для фрагментации данных в Mongo необходимо выбрать одно или несколько полей в документах коллекции в качестве ключа шарда. Затем MongoDB берет диапазон значений ключа и делит их на непересекающиеся диапазоны (фрагменты), каждый фрагмент присваивается определенному шарду.

После этого Mongo считывает значение ключа шарда каждого документа и определяет, к какому фрагменту относится документ, а затем распределяет документ на соответствующий шард. MongoDB мониторит количество фрагментов в каждом шарде и пытается переместить их из одного шарда в другой, чтобы обеспечить равное количество на каждом.

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

Подойдет ли MongoDB для моего приложения?

Реляционные СУБД по-прежнему используются шире, чем NoSQL. Тем не менее, MongoDB продолжает набирать популярность благодаря функциям, которые мы рассмотрели в этом гайде. В частности, она стала распространенным выбором базы данных для ряда случаев использования.

Например, ее возможности масштабирования и высокая доступность делают ее популярной для e-commerce и игр, где количество обслуживаемых пользователей может быстро и значительно увеличиваться. Также гибкая схема и способность обрабатывать большие объемы неструктурированной информации делают ее отличным вариантом для обслуживания приложений управления контентом, которым необходимо управлять постоянно меняющимся каталогом ресурсов, начиная от текста и заканчивая видео, изображениями и аудиофайлами. Она также получила широкое распространение среди разработчиков мобильных приложений, опять же благодаря мощному масштабированию и возможностям анализа данных.

При принятии решения вы должны сначала задать себе вопрос, каковы у вашего приложения потребности в данных. Если приложение будет хранить информацию, которая жестко привязана к предопределенной структуре, вы можете не получить дополнительной пользы от бессхемного дизайна Mongo и, возможно, вам лучше использовать реляционную БД.

Затем оцените, какой объем данных потребуется хранить и использовать вашему приложению. Документо-ориентированный дизайн MongoDB делает ее отличным выбором для приложений, которым необходимо хранить большие объемы неструктурированной информации. Аналогично, масштабируемость и высокая доступность MongoDB делают ее идеальным выбором для приложений, обслуживающих большое и постоянно растущее число клиентов. Однако, эти возможности могут быть просто бесполезными, если в вашем случае нет большого объема информации.

Заключение

Надеемся, вы поняли особенности, которые отличают MongoDB от других СУБД. MongoDB — мощная, гибкая и безопасная система управления базами данных, которая будет правильным выбором в определенных случаях, но это не всегда лучший вариант. Хотя документо-ориентированный и бессхемный дизайн не заменит модель реляционной базы данных в ближайшее время, быстрый рост Mongo подчеркивает ее ценность как инструмента, который стоит освоить.

Официальная документация MongoDB — ценный источник информации.