> Работал ли ты с Cassandra, MongoDB, Redis, ElasticSearch, ClickHouse (Go)

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

Да, работал со всеми перечисленными системами, но с разной глубиной. MongoDB и Redis - основные инструменты в текущем стеке, использую их ежедневно. Cassandra и ClickHouse - в предыдущих проектах, где были требования к горизонтальному масштабированию и аналитике. ElasticSearch - в задачах полнотекстового поиска и observability. Глубина владения: MongoDB и Redis - уверенный senior, Cassandra и ClickHouse - junior-middle, ElasticSearch - middle.

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

Распишу по каждой системе, чтобы было понятно, что именно делал.

MongoDB - основной документоориентированный стор в текущем проекте. Проектировал схемы с учётом паттернов доступа, использовал aggregation pipeline для сложных выборок, настраивал индексы (compound, partial, TTL). Работал с replica set, понимаю как устроен oplog и как выбирается primary. Сталкивался с проблемами долгих операций, когда не хватало индексов, и решал их через анализ explain().

Redis - использую как cache-aside, rate limiter, distributed lock (Redlock), очереди через Streams. Понимаю разницу между persistence режимами RDB и AOF, trade-off между ними. Работал с cluster mode, знаю про hash slots и проблемы с multi-key операциями в кластере. Настраивал eviction policy (allkeys-lru, volatile-ttl) под конкретные сценарии.

Cassandra - в проекте, где была высокая нагрузка на запись и нужна была отказоустойчивость. Проектировал таблицы по принципу query-first design, использовал partition key и clustering columns. Понимаю, как работает compaction, tombstones, и почему важно избегать широких партиций. Но не настраивал кластер с нуля - это делал DevOps, я работал на уровне модели данных и запросов.

ElasticSearch - использовал для полнотекстового поиска по товарам и для логов (ELK). Настраивал mapping, анализаторы, делал запросы через bool query, filters, aggregations. Понимаю, как работает inverted index и почему важно правильно выбирать типы данных. Но не занимался глубокой оптимизацией кластера, шардированием под нагрузку.

ClickHouse - в задаче аналитики по событиям. Строил таблицы с MergeTree, использовал materialized views для агрегатов. Понимаю, почему ClickHouse быстрый на чтении - columnar storage, sparse index. Но это был короткий проект, так что глубина средняя.

На практике

В текущем проекте основной паттерн - MongoDB как система записи, Redis как кэш для горячих данных. Например, профиль пользователя хранится в MongoDB, но при запросе сначала проверяем Redis, и только при miss идём в базу. Инвалидация кэша - через TTL и явное удаление при обновлении данных.

С Cassandra был кейс с хранением событий IoT-устройств. Ключевая особенность - моделирование таблиц под конкретные запросы. Например, для запроса "все события устройства за последний час" делал partition key = device_id, clustering column = timestamp. Это давало быстрый доступ к данным без full scan.

С ElasticSearch - поиск по каталогу. Использовал ngram-анализатор для частичного совпадения, фильтры по категориям и агрегации для фасетов. Важно было не тащить все данные в ES, а хранить только поисковые поля, а полный документ доставать из MongoDB по id.

С ClickHouse - аналитика по действиям пользователей. Строил таблицу событий с партиционированием по дням, агрегаты через materialized view. Это позволяло отвечать на вопросы типа "сколько пользователей совершили покупку за неделю" за миллисекунды.

Пример кода

Пример работы с MongoDB и Redis в Go - паттерн cache-aside:

GO
type UserService struct {
    mongo *mongo.Collection
    redis *redis.Client
}

func (s *UserService) GetUser(ctx context.Context, id string) (*User, error) {
    // 1. Проверяем кэш
    cached, err := s.redis.Get(ctx, "user:"+id).Result()
    if err == nil {
        var user User
        if json.Unmarshal([]byte(cached), &user) == nil {
            return &user, nil
        }
    }

    // 2. Кэш пуст - идём в MongoDB
    var user User
    err = s.mongo.FindOne(ctx, bson.M{"_id": id}).Decode(&user)
    if err != nil {
        return nil, err
    }

    // 3. Пишем в кэш с TTL
    data, _ := json.Marshal(user)
    s.redis.Set(ctx, "user:"+id, data, 10*time.Minute)

    return &user, nil
}

Пример запроса в Cassandra через gocql:

GO
query := `SELECT event_type, payload FROM events 
          WHERE device_id = ? AND ts >= ? AND ts < ?`
iter := session.Query(query, deviceID, start, end).Iter()

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

Структурируй ответ по каждой системе отдельно: что делал, какие задачи решал, с какими проблемами сталкивался. Не говори просто "да, работал" - это ничего не даёт. Интервьюер хочет услышать конкретику: как проектировал схему, какие trade-off выбирал, как дебажил проблемы.

Если по какой-то системе опыта мало - честно скажи об этом и объясни, что знаешь теоретически. Например: "С ClickHouse работал только в одном проекте, но понимаю принципы columnar storage и когда его стоит применять". Это лучше, чем пытаться изобразить глубокое знание.

Подчеркни, что понимаешь, когда какую систему использовать. Например: "Redis не для хранения данных, а для кэша и синхронизации; MongoDB - для документоориентированных данных; ClickHouse - только для аналитики, не для OLTP". Это показывает системное мышление.

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

Интервьюер оценивает:

• реальный опыт, а не теоретические знания - поэтому важны конкретные детали из практики;
• понимание trade-off каждой системы: когда использовать, а когда нет;
• умение проектировать схемы под нагрузку, а не просто выполнять CRUD;
• знание внутренних механизмов: индексы, партиционирование, репликация, консистентность;
• способность объяснить, почему выбрал ту или иную систему для конкретной задачи.

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

• Отвечать общими фразами: "да, использовал, там всё просто". Это сразу снижает уровень.
• Путать назначение систем: например, говорить, что ClickHouse подходит для OLTP или что Redis - основное хранилище.
• Не упоминать проблемы, с которыми сталкивался. Если кандидат говорит, что всё работало идеально, это выглядит подозрительно.
• Не знать базовых терминов: sharding, replication, consistency levels, TTL, eviction policy.
• Утверждать, что знаешь систему, но не мочь ответить на уточняющий вопрос про внутреннее устройство. Например, не знать, что такое oplog в MongoDB или hash slot в Redis cluster.