Технология · База данных
Разработка на MongoDB
Пять платформ, одна система публикации, данные в форме кампаний: MongoDB — наш выбор, когда модель данных должна соответствовать тому, как контент-агентства реально организуют работу, а не втискивать её в жёсткие таблицы.
платформ публикации, отслеживаемых по каждой кампании в одной системе автоматизации на MongoDB
MPSS организует каждый ассет, расписание и список контента по кампаниям — так же, как агентство-клиент уже управляет аккаунтами, — и отслеживает статус публикации независимо на YouTube, Instagram, Threads, Reddit и Telegram, у каждой из которых своя форма метаданных, лимиты подписей и состояние OAuth-токенов. Жёсткая реляционная схема означала бы миграцию каждый раз при добавлении новой платформы с другими полями; документная модель этого избежала.
Когда нужен MongoDB
Мы выбираем MongoDB, когда форма данных настолько варьируется по типу, что иначе пришлось бы делать широкую таблицу, полную nullable-колонок, или лабиринт из join-таблиц, чтобы представить то, что по своей природе является одним документом.
MPSS — самый наглядный пример: пост в YouTube Shorts, Reels в Instagram, пост в Threads, публикация в Reddit и сообщение в Telegram имеют реально разные метаданные — лимиты подписей, обязательные поля, форматы ответов API — но все они принадлежат одной кампании и одному элементу контента. Моделирование этого как документов кампании, содержащих записи публикации по каждой платформе, позволило добавить Threads, Reddit и Telegram уже после запуска первой версии, не перестраивая то, что уже работало для YouTube и Instagram.
Та же гибкость делает управляемым состояние OAuth для пяти разных форматов токенов и циклов обновления в рамках одной системы, без жёсткой схемы, которая заставляла бы данные авторизации каждой платформы влезать в один и тот же фиксированный набор колонок.
Что мы строим на MongoDB
Модели данных в форме кампаний
Документы, организованные так, как бизнес реально думает о работе — по кампании или клиенту — а не втиснутые в универсальную реляционную структуру, которая сопротивляется предметной области.
Отслеживание публикаций на разных платформах
Статус публикации, метаданные и состояние ошибок по каждой платформе отслеживаются независимо в рамках общей записи контента, так что сбой на одной платформе не скрывает успех на другой.
Управление состоянием OAuth-токенов
Гибкое хранение учётных данных подключённых аккаунтов для сервисов с разными форматами токенов, циклами обновления и поведением истечения срока — без миграции схемы при добавлении каждой новой платформы.
Постепенное расширение функциональности
Новые типы контента или платформы добавляются без перестройки существующих коллекций — именно это позволило MPSS вырасти с двух платформ до пяти без переделки основного слоя данных.
Частые вопросы
- Потому что данные публикации на каждой платформе реально имеют разную форму — разные поля метаданных, разные лимиты, разные форматы ответов. Моделирование этого реляционно означало бы либо очень широкую таблицу, полную null-значений, либо большой набор join-таблиц. Документная модель MongoDB позволяет данным каждой платформы выглядеть так, как им положено.
- Может, без дисциплины — поэтому мы всё равно определяем и обеспечиваем схему на уровне приложения, обычно через интерфейсы TypeScript, даже если сама MongoDB этого не требует. Гибкость нужна для работы с реально разными формами документов, а не как повод отказаться от структуры.
- Да — именно это и требовалось от MPSS. Система запустилась с YouTube и Instagram, затем позже добавила Threads, Reddit и Telegram без переделки основной платформы, потому что новые платформы означали лишь новые формы документов в существующей коллекции, а не новые таблицы и миграции.
- Она хорошо подходит везде, где данные естественно группируются в самодостаточные записи с некоторой вариацией формы — пользовательский контент, логи событий, конфигурационные данные. Она хуже подходит для данных с тяжёлой реляционной структурой и строгими требованиями к согласованности между множеством связанных записей, где обычно лучше выбрать реляционную базу.
Нужна модель данных, которая соответствует тому, как реально работает ваша команда?
Мы строим системы на MongoDB для команд, чьи данные не укладываются аккуратно в жёсткие таблицы — кампании, мультиплатформенный контент, вариации по клиентам. Опишите систему — оценим объём работы.