> В чем разница реляционных, NoSQL и колоночных баз данных (Go)

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

Реляционные БД (PostgreSQL, MySQL) хранят данные в таблицах с фиксированной схемой и поддерживают ACID-транзакции и SQL. NoSQL (MongoDB, Redis) - это широкий класс систем без реляционной модели: документные, key-value, графовые, они жертвуют строгой согласованностью ради горизонтального масштабирования и гибкости схемы. Колоночные БД (ClickHouse, Cassandra) - подтип NoSQL или отдельный класс, где данные хранятся по колонкам, а не по строкам, что радикально ускоряет аналитические запросы с агрегациями по узкому набору полей, но делает точечные чтения и запись отдельных строк дорогими.

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

Ключевое различие - модель данных и физическое расположение на диске.

Реляционные БД:

• схема строгая, миграции обязательны
• нормализация, foreign keys, JOIN
• транзакции с ACID, изоляция уровней
• вертикальное масштабирование (шардирование сложно)
• оптимизированы под OLTP: много коротких транзакций чтения/записи по известным ключам

NoSQL:

• нет единой модели: документные (MongoDB), key-value (Redis, DynamoDB), графовые (Neo4j), wide-column (Cassandra, HBase)
• схема flexible или отсутствует
• горизонтальное масштабирование из коробки (sharding, replication)
• обычно eventual consistency или настраиваемая согласованность
• оптимизированы под конкретные паттерны доступа, а не универсальные запросы

Колоночные БД:

• физически хранят значения одной колонки подряд (columnar storage)
• сжатие в 5-10 раз лучше за счёт однотипности данных
• читают только нужные колонки - для аналитики это orders of magnitude быстрее
• запись - append-only, update/delete дорогие
• оптимизированы под OLAP: агрегации, сканирование больших диапазонов, GROUP BY
• примеры: ClickHouse, Vertica, Redshift, BigQuery (хранение), Cassandra (гибрид, но по сути wide-column)

Важный нюанс: Cassandra часто называют колоночной, но она хранит данные по строкам с группировкой по partition key - это wide-column, а не columnar. ClickHouse - настоящая columnar.

Trade-off: реляционные дают целостность и универсальность, NoSQL - масштабируемость и гибкость, колоночные - скорость аналитики ценой записи и транзакционности.

На практике

Выбор зависит от паттерна доступа:

• OLTP с жёсткими требованиями к целостности (финансы, заказы) - PostgreSQL/MySQL
• Высоконагруженные key-value чтения (сессии, кэш) - Redis
• Гибкая схема, документо-ориентированные данные (каталоги, профили) - MongoDB
• Аналитика по большим объёмам (лог-анализ, метрики, BI) - ClickHouse
• Геораспределённая запись с высокой доступностью (события, IoT) - Cassandra

В Go-проектах часто комбинируют: PostgreSQL для транзакционных данных, ClickHouse для аналитики, Redis для кэша. Типичный паттерн - CDC (change data capture) из PostgreSQL в ClickHouse через Kafka.

Пример кода

Пример на Go: запись в PostgreSQL и чтение из ClickHouse для агрегации.

GO
// запись в PostgreSQL
func insertOrder(ctx context.Context, db *sql.DB, order Order) error {
    _, err := db.ExecContext(ctx,
        `INSERT INTO orders (id, user_id, amount, created_at) VALUES ($1, $2, $3, $4)`,
        order.ID, order.UserID, order.Amount, order.CreatedAt)
    return err
}

// чтение агрегата из ClickHouse
func dailyRevenue(ctx context.Context, ch *clickhouse.Conn, day time.Time) (float64, error) {
    rows, err := ch.Query(ctx,
        `SELECT sum(amount) FROM orders WHERE created_at >= ? AND created_at < ?`,
        day, day.Add(24*time.Hour))
    if err != nil {
        return 0, err
    }
    defer rows.Close()
    var total float64
    if rows.Next() {
        rows.Scan(&total)
    }
    return total, nil
}

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

Начни с чёткого разделения: реляционные - про целостность и универсальность, NoSQL - про масштабирование и гибкость, колоночные - про аналитику. Затем перейди к физическому хранению: строки vs колонки, и почему это влияет на производительность. Упомяни OLTP/OLAP - это покажет понимание, а не заученные определения.

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

Если спрашивают про Cassandra - уточни, что это wide-column, а не columnar, это покажет глубину.

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

• Понимание физической модели хранения, а не только терминов
• Умение связывать выбор БД с паттернами доступа и требованиями к согласованности
• Знание trade-off: что теряешь, выбирая NoSQL или колоночную
• Практический опыт: когда реально использовал, какие проблемы решал
• Способность говорить о CAP-теореме, ACID, eventual consistency без зазубривания

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

• Называть Cassandra колоночной БД в смысле columnar - это неверно, это wide-column
• Говорить "NoSQL - это MongoDB" - NoSQL это класс, MongoDB лишь один из представителей
• Утверждать, что колоночные БД "медленные на запись" без оговорки: они оптимизированы под batch-insert, а не под точечные транзакции
• Путать горизонтальное масштабирование с шардированием - это не синонимы
• Забывать про ACID: реляционные не единственные, кто поддерживает транзакции, но делают это "из коробки" и строго
• Отвечать абстрактно без примеров - интервьюер ждёт конкретики из опыта