Почему MongoDB?
За последние несколько лет MongoDB из нишевой NoSQL-СУБД превратилась в некий стандарт для большого количества веб-проектов. Документо-ориентированная модель, хранение данных в BSON (расширенный бинарный JSON) и встроенная масштабируемость дают разработчикам свободу, которую часто мы не можем получить, используя классические реляционные СУБД.
На Монго я смотрю не как на очередную модную технологию, а как на инструмент, который призван закрывать конкретные сценарии бизнеса – гибкое моделирование данных, быстрое прототипирование, сбор и анализ событий или больших данных, гибкий подход к работе с высокими нагрузками. Мы с коллегами выделили несколько сценариев, где MongoDB будет оправдан в разработке и с технической, и с продуктовой стороны.
Гибкие модели данных, оперативная подготовка MVP
MongoDB отлично подойдет в разработке стартапов, где схема данных меняется быстро по ходу развития проекта до стадии MVP. Так же отлично подойдет для маркетплейсов, объемных и сложных каталогов, личных кабинетов с динамическими наборами данных и т.д.
В MongoDB документы (записи) одной коллекции могут иметь разный набор полей, а схема хранения данных эволюционирует вместе с продуктом, без обязательных миграций и сложного рефакторинга.
Что дает использование MongoDB стартап-команде?
- Быстрый выход на MVP и проверку A/B гипотез. Можно быстро и практически безболезненно добавлять новые поля в документы, тестировать новые фичи на части аудитории и откатывать их, не останавливая работу разрабатываемого продукта.
- Хранение не консистентных данных – анкеты, пользовательские настройки, сложные конфигурации товаров – все это можно описывать одним документов, а не большим количеством связных таблиц.
- Объект в коде и документ в базе выглядят практически одинаково, что упрощает восприятие данных командой.
Такой подход уместен, когда собираете что-то новое, а общая архитектура проекта еще несколько туманна и требует отладки.
Логи, события и аналитика в реальном времени
Второй самый очевидный пример, где стоит использовать NoSQL-СУБД. Сбор большого объема данных: клики, просмотры, действия в интерфейсе, технические логи, метрики. Если классическая реляционная СУБД уже упрется в технические ограничения производительности и сложности администрирования при росте записей, тогда как MongoDB оптимизирована под такие объемы и активное горизонтальное масштабирование.
Как это выглядит на практике?
- Храним сырые данные в коллекциях без предварительной или с минимальной обработкой
- Используем агрегирующие пайплайны для построения срезов, сегментации и формирования дэшбордов. Либо храним предварительно собранные документы по различным фильтрам, например по дням.
- Разносим нагрузку по различным репликам: одна нода пишет, другие отдают данные, например для BI-инструментов.
С точки зрения технического директора, это удобный способ отделить операционный контур (сайт или CRM) от контуров аналитики: в MySQL продолжают жить транзакционные данные, а MongoDB уже берет на себя большие потоки телеметрии и поведенческой аналитики.
Персонализация и система рекомендаций
Индивидуально подобранные товары, статьи, умные блоки с контентом на главной и в личном кабинете – все это часто опирается на следующие данные:
- Профиль пользователя, который постоянно обрастает новыми полями, признаками, счетчиками, характеристиками и другой полезной информацией
- Историю действий и событий пользователя, которые нужно быстро сканировать и агрегировать под запрос.
Чем удобна MongoDB для построения рекомендательных систем?
- Профиль пользователя хранится как один документ с вложенными данными: интересы, сегменты, последние действия, настройки.
- Эффективное использование составных и частичных индексов по сценариям выборки, например, активные пользователи определенного сегмента с минимальным количеством просмотра определенного блока.
- Простота внедрения новых алгоритмов рекомендаций – введение новых полей в документ, генерация новых коллекций с результатами оффлайн-расчетов без того, чтобы сломать то, что уже существует.
Таким образом умные составляющие сайта на уровне архитектуры MongoDB позволяет вынести в отдельные сервисы, которые взаимодействуют с основным приложением на уровне API не затрагивая и перегружая основную базу данных.
Микросервисы и высоконагруженные модули
Микросервисная архитектура, где отдельные сервисы отвечают за узкие задачи: каталог, корзина, уведомления, интеграция с внешними системами.
Что важно для микросервисов?
- Независимый жизненный цикл
- Удобное горизонтальное масштабирование
- Простое реплицирование данных
И в данном случае MongoDB как нельзя лучше подходит под данные задачи.
- Репликации и автоматический файловер – кластер может продолжать работу даже при падении одной из нод архитектуры.
- Шардинг – коллекции можно физически разделять по шард-ключу, например по региону или диапазону идентификаторов, что позволяет масштабировать сервис по мере роста нагрузки.
- Гибкий уровень консистенции и настройки записи/чтения, что позволяет балансировать между скоростью отклика и требованиями надежности для разных модулей.
На практике же это означает, что высоконагруженные части системы, такие как поиск по каталогу, трекинг статусов заказов в реальном времени, нотификаци, можно вынести на отдельные сервисы с MongoDB, а критичные контуры, к примеру оставить на реляционной БД.
Гибридные решения
MongoDB берет на себя сложные и новые задачи, когда уже стандартный стек перестает удовлетворять бизнес, а с него сложно слезть, например какие-нибудь типовые связки 1С-Битрикс или Laravel с классической реляционной БД.
Что же умеет MongoDB лучше других?
- Хранение сложны, вариативных, не консистентных и быстро меняющихся данных: фильтров, атрибутов, логов, поведенческих профилей и многих других данных.
- Ускорение тяжелых выборок и поисковых сценариев за счет специализированных коллекций и индексов.
- Обмен данными между сервисами, где MongoDB используется, как центр сбора событий и интеграционный слой для внешних API.
С архитектурной точки зрения это позволяет:
- Сохранить проверенный временем стек и компетенции команды.
- Резко снизить стоимость изменений в зоне, где бизнес постоянно экспериментирует – маркетинг, персонализация, аналитика
- Постепенно эволюционировать архитектуру от монолита к набору сервисов, не переписывая систему с нуля.
Когда MongoDB не к месту?
Тут стоит понимать, что MongoDB не какое-то волшебное решение на все случаи жизни. Монго уступает классическим СУБД там, где требуется строгая транзакционная консистентность на уровне сложны связей и финансовых операций, а также в сценариях, где модель данных четко определена и практически не меняется.
В целом MongoDB нужно рассматривать, как часть гибридной архитектуры рядом с проверенными реляционными системами, а не вместо них.