Какие плюсы и минусы MongoDB?

# MongoDB: плюсы и минусы

Что такое MongoDB

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

// Пример документа MongoDB
{
  _id: ObjectId("507f1f77bcf86cd799439011"),
  username: "alice",
  email: "alice@example.com",
  profile: {
    bio: "Software engineer",
    avatar: "https://...",
    followers: 150
  },
  tags: ["javascript", "nodejs", "mongodb"],
  created_at: ISODate("2025-03-29T10:30:00Z")
}

Плюсы MongoDB

1. Гибкая схема

MongoDB не требует строгой схемы. Разные документы в одной коллекции могут иметь разные структуры:

// Один документ
db.users.insertOne({
  username: "alice",
  email: "alice@example.com"
});

// Другой документ с дополнительными полями
db.users.insertOne({
  username: "bob",
  email: "bob@example.com",
  phone: "+1234567890",
  address: {
    street: "123 Main St",
    city: "NYC"
  }
});

// Оба документа в одной коллекции — это нормально!

Плюсы:

• Быстрое добавление новых полей без миграций
• Адаптивность к изменениям требований
• Легко работать с разнородными данными

2. Естественное представление данных

JSON-подобная структура близка к JavaScript объектам:

// MongoDB документ — это почти то же самое, что JS объект!
const user = {
  username: "alice",
  profile: {
    bio: "Engineer",
    social: {
      twitter: "@alice",
      github: "alice-dev"
    }
  },
  tags: ["nodejs", "react"]
};

db.users.insertOne(user);

// Получить вложенное поле просто
db.users.findOne({ "profile.social.twitter": "@alice" });

3. Встроенные документы (Embedded Documents)

Можно сохранять связанные данные в одном документе, без JOIN'ов:

// ❌ SQL (3 таблицы + 2 JOIN'а)
SELECT u.*, p.*, a.*
FROM users u
JOIN profiles p ON u.id = p.user_id
JOIN addresses a ON p.id = a.profile_id;

// ✅ MongoDB (один запрос, один документ)
db.users.findOne({ username: "alice" });
// Результат:
{
  username: "alice",
  profile: { bio: "...", avatar: "..." },
  address: { street: "...", city: "..." }
}

4. Горизонтальное масштабирование (Sharding)

MongoDB поддерживает шардирование — разделение данных между несколькими серверами:

// MongoDB автоматически распределяет документы
sh.shardCollection("mydb.users", { username: 1 });

// Данные распределяются по нескольким серверам
// Server 1: users A-M
// Server 2: users N-Z
// Запросы автоматически идут на правильный сервер

5. Агрегация (Aggregation Pipeline)

Мощный инструмент для обработки данных:

// Получить топ 10 пользователей по количеству постов
db.posts.aggregate([
  { $group: { _id: "$user_id", count: { $sum: 1 } } },
  { $sort: { count: -1 } },
  { $limit: 10 },
  { $lookup: {
      from: "users",
      localField: "_id",
      foreignField: "_id",
      as: "user"
    }
  }
]);

6. Индексы

Поддерживает различные типы индексов для оптимизации:

// Простой индекс
db.users.createIndex({ username: 1 });

// Составной индекс
db.users.createIndex({ status: 1, created_at: -1 });

// Уникальный индекс
db.users.createIndex({ email: 1 }, { unique: true });

// Текстовый индекс для поиска
db.posts.createIndex({ title: "text", content: "text" });
db.posts.find({ $text: { $search: "mongodb" } });

7. Встроенная репликация

Обеспечивает надежность и отказоустойчивость:

// Replica Set — несколько копий БД
// Если primary упадет, secondary автоматически станет primary
// Нет потери данных, нет downtime

Минусы MongoDB

1. Отсутствие транзакций (до версии 4.0)

Проблема: если нужно обновить несколько документов атомарно:

// ❌ Плохо: может быть несогласованность
db.users.updateOne({ _id: alice_id }, { $inc: { balance: -100 } });
db.users.updateOne({ _id: bob_id }, { $inc: { balance: +100 } });
// Если между операциями сервер упадет, деньги потеряются!

// ✅ Хорошо (MongoDB 4.0+): транзакция
const session = db.getMongo().startSession();
session.startTransaction();
try {
  db.users.updateOne({ _id: alice_id }, { $inc: { balance: -100 } }, { session });
  db.users.updateOne({ _id: bob_id }, { $inc: { balance: +100 } }, { session });
  session.commitTransaction();
} catch (error) {
  session.abortTransaction();
}

2. Нет JOIN'ов (до MongoDB 3.2)

Проблема: получить данные с нескольких коллекций сложнее:

// ❌ Медленный способ (N+1 problem)
const users = db.users.find().toArray();
const result = users.map(user => {
  user.posts = db.posts.find({ user_id: user._id }).toArray();
  return user;
}); // N запросов к БД!

// ✅ Быстрый способ (Lookup, как JOIN)
db.users.aggregate([
  { $lookup: {
      from: "posts",
      localField: "_id",
      foreignField: "user_id",
      as: "posts"
    }
  }
]);

3. Потребление памяти

MongoDB хранит всё в памяти для быстрого доступа, что требует много RAM:

// 1M документов по 1KB каждый = 1GB RAM
// А если есть индексы — еще +500MB
// PostgreSQL в аналогичном случае займет только 300MB

4. Менее подходит для связанных данных

Если у вас много связей между данными (как в CRM или ERP), реляционная БД лучше:

// Пример: сложная структура
// Пользователь → Заказы → Товары → Категории → Производители
// Каждый товар может быть в нескольких категориях
// Каждая категория может быть в нескольких заказах

// В MongoDB: нужно дублировать данные или делать сложные запросы
// В PostgreSQL: простые JOIN'ы

5. Большой размер документов

Documents хранят больше метаинформации, чем таблицы SQL:

// MongoDB
{
  _id: ObjectId("507f1f77bcf86cd799439011"), // +12 bytes
  username: "alice",
  email: "alice@example.com"
}
// ~ 150 bytes

// SQL (та же информация)
id | username | email
1  | alice    | alice@example.com
-- ~ 80 bytes

6. Дублирование данных

Best practice MongoDB — дублировать часто используемые данные:

// БД хранит данные пользователя ДВА раза:
db.posts.insertOne({
  _id: ObjectId(...),
  title: "My Post",
  user_id: ObjectId(...),  // Ссылка
  username: "alice",       // Дублирование!
  user_avatar: "https://...", // Дублирование!
  created_at: ISODate(...)
});

// Плюс: быстрые запросы (не нужен JOIN)
// Минус: при обновлении профиля нужно обновить везде

7. Нет встроенной консистентности

MongoDB — Eventually Consistent, а не Strongly Consistent (как SQL):

// Пример: перевод денег
db.users.updateOne({ _id: alice }, { $inc: { balance: -100 } });
db.users.updateOne({ _id: bob }, { $inc: { balance: +100 } });

// На миллисекунду между обновлениями:
// alice потеряла 100, bob еще не получил
// Итого: -100 в системе (баланс не совпадает)

// В SQL: ACID гарантирует, что либо оба обновления, либо ни одного

Сравнение MongoDB vs SQL

Когда использовать MongoDB

// ✅ MongoDB — хороший выбор

// 1. Быстро развивающиеся приложения (стартапы)
const user = {
  username: "alice",
  email: "alice@example.com"
  // Завтра добавим phone, а через неделю address
  // Без миграций!
};

// 2. Большие объемы данных
// Нужно масштабировать на 100 серверов — MongoDB Sharding

// 3. Документо-центричные приложения
// Content Management System, Blog
// Каждый документ может иметь свою структуру

// 4. Real-time приложения
// Не нужны сложные JOIN'ы, данные быстро считываются

Когда использовать SQL

-- ✅ SQL — хороший выбор

-- 1. Много связей между данными
-- ERP, CRM, Финансовые системы

-- 2. Критична консистентность данных
-- Банки, платежные системы, медицина

-- 3. Сложные запросы
-- Аналитика, отчеты
SELECT d.name, COUNT(e.id) as employee_count
FROM departments d
LEFT JOIN employees e ON d.id = e.department_id
GROUP BY d.id, d.name;

-- 4. Большие объемы связанных данных
-- SQL с правильными индексами очень эффективен

Вывод

MongoDB — это отличный выбор, когда:

• Гибкость важнее консистентности
• Нет сложных связей между данными
• Нужно быстро масштабировать
• Схема данных еще не определена

SQL лучше, когда:

• Требуется ACID и консистентность
• Много связей между сущностями
• Нужны сложные запросы и аналитика
• Данные хорошо структурированы

В 2025 году лучший подход — полиглотная архитектура: SQL для основных данных, MongoDB для документов и логов, Redis для кэша.