> С какими эволюционными базами данных ты работал (PHP)

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

Работал с MongoDB и DynamoDB в production-проектах на PHP. MongoDB использовал как основное хранилище для каталога товаров и пользовательских сессий, DynamoDB - для event sourcing и кэширования счётчиков. Также есть опыт работы с Couchbase в pet-проектах. Основной паттерн - документо-ориентированное хранение с частичной денормализацией данных и использованием агрегационных pipeline для аналитики.

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

Эволюционные базы данных (document stores, key-value, wide-column) отличаются от реляционных отсутствием фиксированной схемы и горизонтальным масштабированием. В контексте PHP-разработки это означает:

• MongoDB - работа через официальный драйвер mongodb/mongodb и ODM Doctrine MongoDB. Использовал для данных с изменяющейся структурой: товарные атрибуты, метаданные, пользовательские профили. Ключевые фичи: $lookup для join-подобных операций, $unwind для работы с массивами, TTL-индексы для автоматической очистки.
• DynamoDB - через AWS SDK для PHP. Применял для high-throughput сценариев: логирование событий, счётчики, временные данные. Важные аспекты: partition key + sort key дизайн, conditional writes для атомарности, DynamoDB Streams для интеграции с другими сервисами.
• Couchbase - N1QL-запросы, но в PHP экосистеме меньше инструментов, поэтому использовал ограниченно.

Основной trade-off: гибкость схемы против сложности поддержки целостности данных. В PHP это особенно заметно - нет типизации на уровне БД, поэтому валидация переносится в приложение (например, через Symfony Validator или ручные проверки).

На практике

В реальных проектах использовал следующие подходы:

• Для MongoDB: гибридная модель - часть данных в документах, часть в реляционной БД. Например, заказы в PostgreSQL, а история изменений заказа - в MongoDB.
• Для DynamoDB: single-table design, когда разные сущности хранятся в одной таблице с разными partition keys. Это снижает стоимость и упрощает масштабирование.
• Миграции схемы: в отличие от SQL, не нужен ALTER TABLE. Вместо этого - версионирование документов через поле schema_version и миграция при чтении (lazy migration).
• Индексы: составные индексы в MongoDB, GSI (global secondary index) в DynamoDB - критично для производительности запросов.

Пример кода

PHP
<?php

use MongoDB\Client;
use MongoDB\Collection;

class ProductRepository
{
    private Collection $collection;

    public function __construct(Client $client)
    {
        $this->collection = $client->selectCollection('catalog', 'products');
    }

    public function findByCategory(string $category, int $limit = 20): array
    {
        $cursor = $this->collection->aggregate([
            ['$match' => ['category' => $category, 'status' => 'active']],
            ['$sort' => ['created_at' => -1]],
            ['$limit' => $limit],
            ['$project' => [
                'name' => 1,
                'price' => 1,
                'attributes' => 1,
                'stock' => ['$arrayElemAt' => ['$warehouses.stock', 0]]
            ]]
        ]);

        return $cursor->toArray();
    }

    public function updateAttributes(string $productId, array $attributes): void
    {
        $this->collection->updateOne(
            ['_id' => new \MongoDB\BSON\ObjectId($productId)],
            ['$set' => ['attributes' => $attributes, 'updated_at' => new \MongoDB\BSON\UTCDateTime()]]
        );
    }
}

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

Структурируй ответ: сначала перечисли базы, затем - конкретные сценарии использования. Обязательно упомяни:

• Почему выбрал документо-ориентированную модель для конкретной задачи, а не SQL.
• Как решал проблему целостности данных без внешних ключей.
• Как проектировал индексы и какие проблемы производительности встречал.
• Как работал с миграциями и версионированием схемы.

Приводи конкретные цифры: объём данных, RPS, latency. Например: "На MongoDB хранили 50 млн документов, средний запрос - 15 мс, p99 - 80 мс".

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

• Понимание разницы между ACID и BASE, eventual consistency.
• Умение обосновать выбор NoSQL для конкретной задачи, а не следование моде.
• Знание внутренних механизмов: как работает шардирование, репликация, индексация.
• Практический опыт: как дебажил медленные запросы, как восстанавливал данные после сбоев.
• Понимание ограничений: нет join-ов, сложные транзакции, проблема горячих ключей.

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

• Называть MongoDB "эволюционной" без пояснения - интервьюер может решить, что ты не понимаешь терминологию. Лучше говорить "документо-ориентированная".
• Хвастаться использованием без конкретных примеров. "Работал с MongoDB" - недостаточно, нужно описать задачу и решение.
• Утверждать, что NoSQL всегда быстрее SQL - это не так, зависит от сценария.
• Игнорировать вопрос о транзакциях. В MongoDB multi-document transactions есть с версии 4.0, в DynamoDB - TransactWriteItems. Если не упомянуть - покажешь незнание.
• Забывать про операционные аспекты: бэкапы, мониторинг, failover. Для senior-позиции это важно.