Зачем переносить данные в MongoDB, вместо реляционных базах данных

MongoDB vs реляционные БД: Когда мигрировать?

MongoDB (NoSQL документная БД) и реляционные БД (PostgreSQL, MySQL) решают разные задачи. Вопрос не в том, "что лучше", а в том, "что подходит для конкретной задачи".

Когда MongoDB имеет преимущества

1. Гибкая схема данных (Schema-less)

// В реляционной БД: нужно заранее определить все поля
CREATE TABLE users (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    email VARCHAR(100),
    phone VARCHAR(20)
);
// Если нужно добавить новое поле — требуется ALTER TABLE миграция

// В MongoDB: можно сохранять документы с разной структурой
db.users.insertOne({
    _id: ObjectId(),
    name: "John",
    email: "john@example.com",
    phone: "+1234567890",
    address: {
        city: "New York",
        zip: "10001"
    },
    tags: ["vip", "premium"]
});

db.users.insertOne({
    _id: ObjectId(),
    name: "Jane",
    email: "jane@example.com"
    // Нет поля phone — это нормально для MongoDB!
});

Пример на Java:

// Класс пользователя в Java
public class User {
    private String id;
    private String name;
    private String email;
    private String phone;           // У одного пользователя есть
    private Address address;        // У другого нет
    private List<String> tags;      // Структура может варьироваться
}

// MongoDB сохранит это как есть
// Реляционная БД потребует UPDATE схемы

Когда это полезно:

• Стартапы с быстро меняющимися требованиями
• Разнородные данные от разных источников
• Миграция данных из разных систем

2. Вложенные структуры (Embedded documents)

// Реляционная БД: много таблиц и JOIN'ов
SELECT u.*, a.*, p.* FROM users u
JOIN addresses a ON u.id = a.user_id
JOIN phones p ON u.id = p.user_id
WHERE u.id = 1;

// MongoDB: всё в одном документе
db.users.findOne({ _id: 1 });
// Результат:
{
    _id: 1,
    name: "John",
    addresses: [
        { street: "123 Main St", city: "NYC" },
        { street: "456 Oak Ave", city: "LA" }
    ],
    phone: { country: "+1", number: "2125555555" }
}

В Java с MongoDB:

@Data
public class User {
    @Id
    private String id;
    private String name;
    private List<Address> addresses;  // Вложенный список
    private Phone phone;              // Вложенный объект
}

// Результат из БД — готовый объект, никаких JOIN'ов!
User user = mongoTemplate.findById(1, User.class);
System.out.println(user.getAddresses().get(0).getCity());  // Просто и удобно

Когда это полезно:

• Древовидные и иерархические данные
• Меньше кода для работы со связанными сущностями
• Лучше производительность на чтение (один запрос вместо многих JOIN'ов)

3. Горизонтальная масштабируемость (Sharding)

// MongoDB встроенно поддерживает sharding
// Данные автоматически распределяются по серверам

db.adminCommand({
    enableSharding: "myapp",
    shardKey: { userId: 1 }  // Разделяем по userId
});

// Все запросы по userId автоматически идут в правильный shard
db.users.find({ userId: 12345 });  // Быстро!

// Реляционные БД требуют сложного паттерна sharding на уровне приложения
// или дорогих решений типа Citus (PostgreSQL) или MySQL Cluster

Когда это полезно:

• Big Data и массивные нагрузки
• Системы с миллиардами записей
• Распределённые системы

4. Агрегирование данных (Aggregation Pipeline)

// MongoDB: встроенный конвейер обработки данных
db.orders.aggregate([
    { $match: { status: "completed" } },
    { $group: { _id: "$customerId", total: { $sum: "$amount" } } },
    { $sort: { total: -1 } },
    { $limit: 10 }
]);

// Результат: топ-10 клиентов по сумме заказов

// Реляционная БД требует сложного SQL
SELECT customer_id, SUM(amount) as total
FROM orders
WHERE status = 'completed'
GROUP BY customer_id
ORDER BY total DESC
LIMIT 10;

Когда НЕ нужна MongoDB

1. Сложные транзакции

// Банковская система: переводы между счётами
// Реляционная БД (ACID транзакции):
BEGIN TRANSACTION;
    UPDATE accounts SET balance = balance - 100 WHERE id = 1;
    UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;
// Гарантировано: либо оба UPDATE, либо ни один

Когда это критично:

• Банки, платёжные системы
• Системы с финансовыми расчётами
• Где требуется ACID гарантия

2. Сложные связи (Many-to-many relationships)

// Студенты и курсы (many-to-many)
Students --*--* Courses

// Реляционная БД: нормализация, 3 таблицы
CREATE TABLE students (id INT, name VARCHAR);
CREATE TABLE courses (id INT, title VARCHAR);
CREATE TABLE enrollments (student_id INT, course_id INT);

Сравнительная таблица

Когда мигрировать на MongoDB?

1. Схема быстро меняется — новые поля часто появляются
2. Много вложенных данных — экономия на JOIN'ах
3. Big Data с high throughput — встроенный sharding
4. Временные/NoSQL данные — кэши, логи, события
5. Слабо связанные сущности — нет complex many-to-many

Когда остаться в реляционной БД?

1. Финансовые системы — нужна ACID
2. Много связей между сущностями — complex normalization
3. Строгие требования к целостности — constraints и foreign keys
4. Сложные запросы — SQL проще, чем pipeline
5. Долгоживущие проекты — SQL изучен годами

Итог

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