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

MongoDB: Плюсы и минусы

MongoDB — это популярная NoSQL база данных с документной моделью. Расскажу о её преимуществах и недостатках на основе реальной промышленной практики.

Плюсы MongoDB

1. Гибкая схема (Schema Flexibility)

from pymongo import MongoClient

client = MongoClient('mongodb://localhost:27017')
db = client['myapp']
users = db['users']

# Первый документ со своей схемой
users.insert_one({
    "_id": 1,
    "name": "Alice",
    "email": "alice@example.com"
})

# Второй документ с другим набором полей
users.insert_one({
    "_id": 2,
    "name": "Bob",
    "phone": "+1234567890",
    "address": "123 Main St",
    "tags": ["premium", "verified"]
})

# Оба документа существуют в одной коллекции
for doc in users.find():
    print(doc)

Преимущество:

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

2. JSON-подобный формат документов (JSON Documents)

document = {
    "_id": ObjectId(),
    "user": {
        "name": "Alice",
        "profile": {
            "age": 30,
            "city": "Moscow"
        }
    },
    "orders": [
        {"id": "order1", "total": 99.99},
        {"id": "order2", "total": 49.99}
    ]
}

users.insert_one(document)

# Естественное представление данных
# Нет необходимости в множественных JOIN запросах

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

# MongoDB автоматически распределяет данные
# Конфигурация шардирования

# Документ в сегменте 1
users.insert_one({"_id": 1, "name": "Alice", "region": "EU"})

# Документ в сегменте 2
users.insert_one({"_id": 2, "name": "Bob", "region": "US"})

# Документ в сегменте 3
users.insert_one({"_id": 3, "name": "Charlie", "region": "APAC"})

# Запрос автоматически идёт на нужный сегмент
user = users.find_one({"_id": 1})

Преимущество:

• Масштабирование горизонтально вместо вертикального
• Распределение нагрузки на множество узлов

4. Быстрая разработка

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()
db = client['myapp']

class UserCreate(BaseModel):
    name: str
    email: str
    phone: str = None

@app.post("/users")
async def create_user(user: UserCreate):
    # Просто вставляем документ - никаких миграций!
    result = db.users.insert_one(user.model_dump())
    return {"id": str(result.inserted_id)}

5. Индексирование и производительность запросов

# Создание индекса
db.users.create_index("email", unique=True)
db.users.create_index("created_at")  # В порядке убывания

# Сложный индекс
db.orders.create_index([
    ("user_id", 1),
    ("created_at", -1)
])

# Теперь поиск очень быстрый
user = db.users.find_one({"email": "alice@example.com"})
orders = db.orders.find({"user_id": user_id}).sort("created_at", -1)

6. Агрегационный конвейер (Aggregation Pipeline)

# Сложные аналитические запросы без кода Python
pipeline = [
    {"$match": {"status": "completed"}},
    {"$group": {
        "_id": "$user_id",
        "total_spent": {"$sum": "$amount"},
        "order_count": {"$sum": 1}
    }},
    {"$sort": {"total_spent": -1}},
    {"$limit": 10}
]

top_customers = list(db.orders.aggregate(pipeline))

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

# Автоматическая репликация для высокой доступности
config = {
    "_id": "rs0",
    "members": [
        {"_id": 0, "host": "primary:27017"},
        {"_id": 1, "host": "secondary1:27017"},
        {"_id": 2, "host": "secondary2:27017"}
    ]
}

# При отказе primary автоматически выбирается новый
# Данные синхронизируются в реальном времени

Минусы MongoDB

1. Огромное использование памяти (Memory Overhead)

# MongoDB хранит КАЖДЫЙ документ с полной информацией
users = db.users

# Документ занимает больше памяти чем в реляционной БД
user_doc = {
    "_id": ObjectId(),  # 12 байт + overhead
    "name": "Alice",    # Поле повторяется для каждого документа!
    "email": "alice@example.com"
}

# Если 1 000 000 документов:
# Реляционная БД: ~8 MB на ключи + индексы
# MongoDB: ~200+ MB на то же самое (из-за хранения имён полей)

2. Отсутствие Join операций (No Joins)

# Вместо SQL JOIN нужно делать несколько запросов
user = db.users.find_one({"_id": user_id})
orders = db.orders.find({"user_id": user_id})  # Отдельный запрос
shipping = db.shipping.find_one({"order_id": orders[0]['_id']})  # Ещё запрос

# Или денормализовать данные (дублирование)
user_with_orders = {
    "name": "Alice",
    "orders": [
        {"id": "order1", "total": 99.99},
        {"id": "order2", "total": 49.99}
    ]
}
# Проблема: обновление данных в orders требует обновления везде!

3. Проблемы консистентности (Consistency Issues)

# MongoDB по умолчанию не гарантирует ACID
# При сбое между вставками можем потерять данные

try:
    db.users.insert_one(user1)
    # Сбой сервера здесь
    db.orders.insert_one(order1)  # Этот документ может не сохраниться
except:
    pass

# Решение: Transactions (с производительностью)
session = client.start_session()
try:
    session.start_transaction()
    db.users.insert_one(user1, session=session)
    db.orders.insert_one(order1, session=session)
    session.commit_transaction()
except:
    session.abort_transaction()

4. Проблемы индексирования (Indexing Challenges)

# Нельзя использовать индекс для частичного совпадения
db.users.find({"name": {"$regex": "^Ali"}})
# Нельзя использовать индекс для $regex с флагом i (case-insensitive)

# Индексы по массивам создают много записей
db.products.insert_one({
    "name": "Laptop",
    "tags": ["electronics", "computers", "portable"]  # 3 записи индекса
})

# Сложные индексы (более 5 полей) неэффективны

5. Сложность запросов и оптимизация (Query Complexity)

# Простой запрос в SQL, сложный в MongoDB
# Найти всех пользователей с более чем 5 заказами

# MongoDB
pipeline = [
    {"$lookup": {
        "from": "orders",
        "localField": "_id",
        "foreignField": "user_id",
        "as": "user_orders"
    }},
    {"$addFields": {
        "order_count": {"$size": "$user_orders"}
    }},
    {"$match": {"order_count": {"$gte": 5}}},
    {"$project": {"user_orders": 0}}
]

# vs SQL (простой и понятный)
# SELECT * FROM users
# WHERE id IN (
#     SELECT user_id FROM orders
#     GROUP BY user_id
#     HAVING COUNT(*) > 5
# )

6. Ограничения размера документов

# Максимальный размер документа - 16 MB
# Если данные больше, нужны GridFS или другие решения

big_document = {
    "_id": 1,
    "huge_array": [1] * 10_000_000  # Может быть слишком большим
}

try:
    db.collection.insert_one(big_document)
except:
    print("Document too large")

7. Затраты на лицензирование (в MongoDB Atlas)

# MongoDB Atlas (облачная версия) имеет высокие затраты
# Рекомендуется для высоконагруженных систем

# При малых объёмах дешевле использовать PostgreSQL с JSON:
query = """
SELECT data->>'name' as name
FROM users
WHERE data->>'status' = 'active'
"""

8. Проблемы с денормализацией

# Часто приходится дублировать данные
user_doc = {
    "_id": 1,
    "name": "Alice",
    "email": "alice@example.com"
}

order_doc = {
    "_id": "order1",
    "user_id": 1,
    "user_name": "Alice",      # Дублирование!
    "user_email": "alice@example.com",  # Ещё дублирование!
    "total": 99.99
}

# Если Alice изменит email, нужно обновить ВСЕ заказы
# Это трудно отследить и легко привести к противоречиям

9. Долгосрочная поддержка и миграция

# Если позже захотите мигрировать на SQL
# Нужно написать ETL с денормализацией

from pymongo import MongoClient
import psycopg2

client = MongoClient('mongodb://localhost:27017')
db = client['myapp']

# Экспорт из MongoDB в PostgreSQL - болезненный процесс
for user_doc in db.users.find():
    # Нужно нормализовать структуру
    psycopg2.execute(
        "INSERT INTO users (id, name, email) VALUES (%s, %s, %s)",
        (user_doc['_id'], user_doc['name'], user_doc['email'])
    )

Сравнение: MongoDB vs PostgreSQL

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

✅ Хорошо для:

• Быстрая разработка с меняющейся схемой
• Большие объёмы данных (> 1 TB)
• Горизонтальное масштабирование
• Документные данные (каталоги товаров, контент)
• Кеширование и сессии

❌ Плохо для:

• Финансовые системы (нужна строгая консистентность)
• Сложные связи между сущностями
• Синтетические аналитические запросы
• Малые приложения с простой структурой

Вывод

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