Архитектура MongoDB: структура, терминология, требования и преимущества

Опубликовано: 2020-12-28

Оглавление

Обзор

Нет сомнений в том, что Интернет является основой современной мировой экономики. Сегодня почти 4,7 миллиарда человек в мире используют виртуальную платформу каждый день, используя интернет-приложения для получения новостей, покупки одежды, заказа еды, прослушивания музыки, поездок в офис и обратно и многого другого.

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

Это вызвало острую потребность в новой парадигме базы данных, которая может хранить, обслуживать и поддерживать приложения «больших данных» (как они стали известны) круглосуточно и без выходных.

Введите NoSQL.

Расцвет баз данных NoSQL

NoSQL, широко известный как «Не только SQL», представляет собой альтернативу базам данных SQL, ограниченным их фиксированными схемами таблиц. Обладая высокой гибкостью, NoSQL преодолевает этот структурный недостаток баз данных SQL и поддерживает горизонтальное масштабирование. Базы данных NoSQL были разработаны для повышения производительности труда разработчиков, предоставляя им простую и элегантную модель данных для сложных операций обработки данных и управления ими.

В целом эти модели хранения данных были четырех типов: документ, ключ-значение, широкий столбец и график. В этом блоге мы сосредоточимся на базах данных документов и архитектуре MongoDB (ведущая база данных NoSQL).

Структура MongoDB

Источник: документация MongoDB .

Архитектура MongoDB следует гибкой модели данных. В отличие от РСУБД, которая требует объявления схемы перед вставкой данных, MongoDB не применяет фиксированную структуру документа.

Терминология

Поля

Пара ключ-значение в документе, аналог столбца в реляционных базах данных.

Документ

Это эквивалент записи в РСУБД

Коллекции

Группа документов называется коллекцией. Это аналог таблицы РСУБД

Различия между RDBMS и архитектурой MongoDB

Присоединяется

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

Нормализация

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

Структура

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

Необходимость и преимущества архитектуры MongoDB

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

Ниже приведены некоторые из его основных преимуществ.

на основе документов

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

Специальные запросы — мощный язык запросов, который может возвращать указанные поля. Это также позволяет использовать возможности высокодетализированного поиска. (по полям, по диапазонам, общие выражения и т. д.)

Индексация

Вы можете проиндексировать любое поле в документе, чтобы ускорить процесс поиска данных.

Давайте теперь углубимся в архитектуру MongoDB .

Но прежде чем мы это сделаем, нам нужно понять теорему CAP.

Теорема CAP

CAP обозначает тройственность: согласованность, доступность и устойчивость к разделам.

Давайте посмотрим, что означает каждый термин в этом контексте.

Последовательность

Если вы записываете данные в распределенную базу данных, вы должны иметь возможность доступа к одним и тем же данным с любого узла в системе в любой момент времени. Речь идет о сохранении целостности записанных данных.

Доступность

Речь идет о минимизации времени простоя системы. Операции чтения/записи должны выполняться на любой машине в кластере в обязательном порядке.

Устойчивость к разделам или отказоустойчивость

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

Теорема CAP утверждает, что распределенная система ДОЛЖНА быть устойчивой к разделению. Любые сетевые разделы не могут привести к краху всей системы.

Другими словами, вы можете гарантировать только один параметр из «Непротиворечивости» и «Доступности» в распределенной системе, а другой — «Допуск на разделы».

Получается вот такой треугольник:

Источник: Педиатр по науке о данных .

MongoDB всегда выбирает согласованность, а не доступность , когда в системе есть раздел (CP). Он блокирует все операции записи до тех пор, пока не сможет обеспечить точное выполнение этих операций записи.

Архитектура MongoDB

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

В основном это резервные копии основного сервера в качестве защиты от сбоя основного сервера.

Все эти серверы сгруппированы в наборы реплик. У вас может быть несколько наборов реплик, каждый из которых имеет свои первичный и вторичный серверы.

Источник: документация MongoDB.

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

Если вы не хотите тратить деньги на три сервера, вы можете назначить узел «Арбитр», единственной задачей которого является голосование при выборе основного.

Разделение

Разделение в MongoDB позволяет распределять большие данные по нескольким базам данных.

Источник: документация MongoDB .

У вас есть приложение с миллионами пользователей. Разделение позволяет разделить этих пользователей (на основе уникального индекса, такого как идентификатор пользователя) на разные наборы реплик. Используя процесс под названием mongoS, сервер приложений взаимодействует с серверами конфигурации (а точнее с тремя), чтобы понять, какой «осколок» содержит данные, которые он ищет. mongoS запускает процесс Load Balancer в фоновом режиме, чтобы автоматически распределять нагрузку (в данном случае количество пользователей) равномерно между всеми осколками.

Заключение

Если вы хотите узнать больше о MongoDB и операциях с базой данных, ознакомьтесь с идеями проекта MongoDB. Вы можете изучить диплом PG в области науки о данных от upGrad. 12-месячный курс, предназначенный для работающих профессионалов, вы получаете всесторонние консультации по вопросам карьеры и возможности трудоустройства, а также престижный статус выпускника IIIT Bangalore.

Мы надеемся, что эта статья помогла вам понять, как работает архитектура MongoDB и как работает система. Чтобы узнать больше, посмотрите другие наши блоги.

Изучайте онлайн-курсы по разработке программного обеспечения в лучших университетах мира. Участвуйте в программах Executive PG, Advanced Certificate Programs или Master Programs, чтобы ускорить свою карьеру.

Повышай свою квалификацию и будь готов к будущему

Расширенная программа сертификации в области больших данных от IIIT Bangalore