> Был ли опыт работы с MongoDB или аналогичными документно-ориентированными базами данных (Python)

Короткий ответ

Да, есть опыт работы с MongoDB и другими документно-ориентированными БД (например, Couchbase, Firestore). Использовал MongoDB как основное хранилище в нескольких продакшн-проектах на Python: проектирование схем, агрегационные пайплайны, индексы, replica sets, sharding, миграции данных. Понимаю сильные стороны документных БД (гибкая схема, горизонтальное масштабирование) и их ограничения (отсутствие join, транзакции с ограничениями, проблемы с консистентностью при шардировании).

Подробное объяснение

Документно-ориентированные БД хранят данные в виде JSON-подобных документов, что хорошо ложится на объектную модель Python. Ключевые аспекты работы:

• Моделирование данных: в отличие от SQL, здесь проектирование начинается с вопросов "как данные читаются", а не "как они нормализованы". Часто применяется денормализация, встраивание вложенных документов или ссылки (DBRef) - выбор зависит от паттернов доступа.
• Агрегационный пайплайн - аналог сложных SQL-запросов: $match, $group, $lookup (аналог left join), $unwind, $project. Важно понимать порядок стадий и влияние на производительность.
• Индексы: составные, partial, TTL, text, geospatial. Критично для производительности - без правильных индексов MongoDB сканирует коллекцию.
• Транзакции: с версии 4.0 поддерживаются multi-document транзакции, но с ограничениями (например, нельзя использовать в sharded кластерах до 4.2, ограничение на время выполнения - 60 секунд по умолчанию).
• Масштабирование: replica sets для отказоустойчивости, sharding для горизонтального масштабирования. Ключевой момент - выбор shard key, от которого зависит равномерность распределения данных.
• Миграции: инструменты вроде mongo-migrate или собственные скрипты, так как схема не фиксирована, но изменения всё равно нужно контролировать.

В Python обычно работаю через pymongo или motor (async), реже через ODM - mongoengine или beanie (для FastAPI). Для продакшна предпочитаю pymongo с тонким слоем репозиториев, чтобы держать запросы под контролем.

На практике

Из реальных проектов:

• Каталог товаров: документ содержал всю информацию о товаре (характеристики, цены, остатки по складам) - это позволило отдавать данные одним запросом без join. Проблема возникла с обновлением цен: при массовых изменениях приходилось обновлять тысячи документов, что решалось bulk-операциями.
• Логирование событий: использовали TTL-индексы для автоматического удаления старых записей, шардировали по event_time - но столкнулись с проблемой горячих шардов, пришлось менять shard key на хэш от user_id.
• Аналитика: агрегационные пайплайны для подсчёта метрик по пользователям. Здесь важна оптимизация: $match как можно раньше, использование $project для уменьшения объёма данных между стадиями.
• Миграции: при изменении структуры документов писали скрипты, которые итерировались по коллекции батчами и обновляли документы. Важно учитывать, что во время миграции приложение должно работать со старой и новой схемой одновременно.

Пример кода

PYTHON
from pymongo import MongoClient, ASCENDING, DESCENDING
from pymongo.errors import BulkWriteError
from datetime import datetime, timedelta

client = MongoClient("mongodb://localhost:27017")
db = client["shop"]
products = db["products"]

# Создание составного индекса: category + price
products.create_index([("category", ASCENDING), ("price", DESCENDING)])

# Агрегация: топ-5 категорий по сумме продаж за последний день
pipeline = [
    {"$match": {"created_at": {"$gte": datetime.utcnow() - timedelta(days=1)}}},
    {"$group": {"_id": "$category", "total": {"$sum": "$price"}}},
    {"$sort": {"total": -1}},
    {"$limit": 5},
    {"$project": {"_id": 0, "category": "$_id", "total": 1}}
]
top_categories = list(products.aggregate(pipeline))

# Bulk-обновление: повысить цену на 10% для категории "electronics"
bulk_ops = [
    {"updateOne": {
        "filter": {"category": "electronics"},
        "update": {"$mul": {"price": 1.1}}
    }}
]
try:
    result = products.bulk_write(bulk_ops)
    print(f"Updated: {result.modified_count}")
except BulkWriteError as e:
    print(f"Errors: {e.details}")

# Транзакция (только для replica set)
with client.start_session() as session:
    with session.start_transaction():
        products.update_one(
            {"_id": "product_1"},
            {"$inc": {"stock": -1}},
            session=session
        )
        orders.insert_one(
            {"product_id": "product_1", "qty": 1, "created_at": datetime.utcnow()},
            session=session
        )
        # commit происходит автоматически при выходе из контекста

Как отвечать на собеседовании

Структурируй ответ так:

1. Опыт: кратко перечисли проекты, где использовал MongoDB, и какую роль она играла (основное хранилище, кэш, аналитика).
2. Глубина: покажи понимание не только синтаксиса, но и внутренних механизмов - как работает WiredTiger storage engine, как выбирается план запроса, что такое oplog.
3. Trade-off: обязательно упомяни, когда MongoDB - плохой выбор (сложные отчётные запросы с множеством join, строгая консистентность, много транзакций между разными сущностями).
4. Инструменты: расскажи про ODM, миграции, мониторинг (например, mongostat, explain() для анализа запросов).
5. Проблемы: поделись реальными кейсами - как решал проблемы производительности, конфликты при конкурентной записи, восстановление после сбоя.

Если интервьюер спрашивает про альтернативы - сравни с PostgreSQL (когда нужны сложные запросы и транзакции) и с Cassandra (когда нужна максимальная запись и горизонтальное масштабирование без сложных запросов).

Что проверяет интервьюер

• Практический опыт: не просто "читал документацию", а реально работал с продакшн-нагрузкой.
• Понимание модели данных: умеет ли кандидат проектировать документы под паттерны доступа, а не просто переносить SQL-схему.
• Знание ограничений: понимает ли, когда MongoDB не подходит, и может аргументировать выбор.
• Производительность: знает ли про индексы, explain, мониторинг, узкие места.
• Масштабирование: понимает ли разницу между replica set и sharding, как выбирать shard key.
• Актуальность: знает ли про транзакции, change streams, aggregation pipeline - современные фичи.

Типичные ошибки

• "MongoDB - это просто JSON-хранилище": не упоминает про индексы, агрегации, транзакции - выглядит как поверхностный опыт.
• Проектирование как в SQL: пытается нормализовать всё, делает много ссылок вместо встраивания - показывает непонимание документной модели.
• Игнорирование ограничений: утверждает, что MongoDB подходит для всего, не упоминает проблемы с join, консистентностью, сложными транзакциями.
• Незнание внутренностей: не может объяснить, как работает WiredTiger, что такое oplog, как выбирается shard key.
• Ошибки в агрегациях: не знает порядок стадий, не использует $match раньше других стадий - показывает слабое владение пайплайнами.
• Нет опыта с реальными проблемами: не может рассказать про деградацию производительности, конфликты записи, миграции в проде.