Где хранить неструктурированные данные: СУБД MongoDB для веб-разработчиков и аналитиков

Многие базы данных относятся к реляционным и управляются с помощью языка SQL. В таких базах данные хранятся в строгих таблицах, связанных друг с другом разными способами. У них есть чёткая структура, под которую нужно подгонять все данные прежде чем внести их в базу.

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

MongoDB была разработана в 2009 году в ответ на потребность компаний в масштабируемой СУБД для хранения неструктурированных данных. С тех пор вышло множество обновлений, и MongoDB по-прежнему пользуется огромной популярностью — по рейтингу портала DB-Engines, она входит в пять самых востребованных СУБД в мире.

В MongoDB данные хранятся неструктурированно, в виде специальных документов. Они записаны в формате BSON — это бинарная версия популярного формата JSON. Все документы в базе — это набор пар «поле—значение», где в качестве значения может быть что угодно, от чисел и дат до других вложенных документов. Неважно, в каком виде и формате создан документ — он спокойно «ляжет» в базу данных MongoDB без предварительной обработки.

От SQL-баз MongoDB отличается структурой хранения данных, и это отличие принципиально. Однако существуют и другие NoSQL-СУБД: Couchbase, ArangoDB, OrientDB и т.п. Они также хранят данные в виде документов и выступают прямыми конкурентами MongoDB. Рассмотрим, чем Mongo отличается именно от них:

✅Кросс-платформенность. MongoDB написана на языке С++ и работает на всех популярных операционных системах: Windows, macOS и разных дистрибутивах Linux. Это позволяет использовать её практически на любых серверах.

✅Реплицирование. Данные в MongoDB не хранятся в одном месте — они поделены между разными серверами. Один из серверов ключевой, первичный (от англ. primery), и на нём выполняются все основные операции. Другие серверы вторичные (от англ. secondary), на них копируют записи из основного. Если с ключевым сервером что-то происходит, например его обновляют, главной становится копия. Это свойство позволяет избежать потери данных и сохраняет их доступность.

✅Шардирование. Когда все запросы идут через один сервер, это уменьшает пропускную способность. Чтобы этого избежать, MongoDB позволяет создать несколько шардов ― частей, в которых хранятся разные данные. Управляющая система знает, где какие данные лежат, и распределяет запросы по разным серверам. Это позволяет параллельно обрабатывать больше информации.

✅Ограниченный размер документов. Каждый документ в базе должен быть не больше 16 МБ. Если это значение нужно превысить, приходится прибегать к ухищрениям — создавать отдельные коллекции для метаданных и разбивать данные на небольшие файлы.

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

MongoDB лучше всего использовать там, где требуется хранить и анализировать большое количество фрагментов информации, не связанных друг с другом. Например, для:

● каталогов интернет-магазинов;
● системных логов;
● записей с датчиков и интернета вещей;
● данных из мобильных приложений;
● кэша;
● данных о пользователях сервиса или приложения.

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

Но есть ситуации, в которых использовать MongoDB не стоит:

● Данных в проекте не так уж много. Когда объёмы информации небольшие, настраивать и поддерживать MongoDB не обязательно — особенно если в команде приняты реляционные базы данных.
● Есть жесткие требования к целостности данных. Поскольку MongoDB не соответствует ACID, лучше не использовать её там, где целостность данных — важный и критичный показатель.
● Требуется сложная аналитика. MongoDB быстро обрабатывает простые аналитические запросы, но сложные ей даются с трудом и требуют множества ресурсов из-за плохой связности данных.

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

Это пример конфигурации для Linux — для Windows можете использовать аналогичную конфигурацию, но указывать другие пути к папкам, в зависимости от потребностей и настроек операционной системы. Важно изменять настройки конфигурации и подстраивать их под свои нужды. Подробнее о конфигурации можно узнать в официальной документации MongoDB.

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