Почему ClickHouse лучше подходит под аналитические запросы и агрегации?

Почему ClickHouse оптимален для аналитических запросов и агрегаций

ClickHouse — это специализированная колоночная СУБД, разработанная Яндексом специально для аналитики. Её архитектура кардинально отличается от традиционных реляционных БД, что делает её идеальной для аналитических рабочих нагрузок.

1. Колоночное хранилище данных (Column-Oriented Storage)

Это фундаментальное отличие ClickHouse от транзакционных БД типа PostgreSQL.

Строчное хранилище (Row-oriented) — PostgreSQL, MySQL:

row_id | user_id | name     | age | city    | salary
   1   |  101    | Иван     |  28 | Москва  | 100000
   2   |  102    | Мария    |  32 | СПб     | 120000
   3   |  103    | Петр     |  25 | Казань  | 90000

Данные хранятся рядом по строкам. Если запросить только зарплаты всех пользователей, нужно прочитать ВСЕ данные каждой строки.

Колоночное хранилище (Column-oriented) — ClickHouse:

user_id:    [101, 102, 103, ...]
name:       ["Иван", "Мария", "Петр", ...]
age:        [28, 32, 25, ...]
city:       ["Москва", "СПб", "Казань", ...]
salary:     [100000, 120000, 90000, ...]

Каждый столбец хранится отдельно. Для запроса зарплат нужно прочитать только столбец salary.

Преимущество: Аналитические запросы часто обращаются к 5-10% столбцов таблицы, а не ко всем. ClickHouse читает только нужные столбцы.

# Пример запроса в ClickHouse
SELECT sum(salary) FROM users WHERE age > 25

# ClickHouse прочитает только: age (для фильтра) и salary (для агрегации)
# PostgreSQL прочитает все строки целиком

2. Превосходная компрессия данных

Колоночное хранилище позволяет ClickHouse применять специализированные алгоритмы сжатия для каждого столбца.

Столбец age: [28, 32, 25, 28, 30, 29, ...]
Выглядит как последовательность чисел → легко сжимается дельта-кодированием

Столбец city: ["Москва", "СПб", "Казань", "Москва", "СПб", ...]
Частые повторения → идеально для словарного сжатия

Результат: Одна и та же таблица в ClickHouse занимает в 10-100 раз меньше места, чем в PostgreSQL.

3. Векторизованная обработка запросов (SIMD)

ClickHouse обрабатывает данные блоками, что позволяет использовать процессорные инструкции SIMD (Single Instruction Multiple Data).

# Обработка зарплат в PostgreSQL (строка за строкой)
for row in rows:
    if row["age"] > 25:
        total += row["salary"]

# Обработка в ClickHouse (целый блок за раз)
salaries = [100000, 120000, 90000, 110000, ...]
ages = [28, 32, 25, 35, ...]

# SIMD инструкция обрабатывает 8-16 элементов одновременно
total = sum(salaries[ages > 25])

Результат: Скорость обработки в 10-100 раз выше для аналитических запросов.

4. Оптимизация для агрегирующих операций

ClickHouse специально оптимизирован именно для агрегаций, которые типичны для аналитики.

# Такие запросы ClickHouse обрабатывает молниеносно

# Подсчёт уникальных пользователей по дням
SELECT 
    toDate(timestamp) as day,
    uniq(user_id) as unique_users
FROM events
GROUP BY day

# Подсчёт средней стоимости заказа по категориям
SELECT 
    category,
    avg(price) as avg_price,
    sum(quantity) as total_quantity
FROM orders
GROUP BY category

# Процентили доставки по регионам
SELECT 
    region,
    quantile(0.5)(delivery_time) as median,
    quantile(0.95)(delivery_time) as p95
FROM shipments
GROUP BY region

5. Встроенные функции для аналитики

ClickHouse имеет богатую библиотеку функций специально для аналитических задач.

# Функции для временных рядов
SELECT 
    timestamp,
    user_id,
    revenue,
    sum(revenue) OVER (PARTITION BY user_id ORDER BY timestamp) as cumulative_revenue
FROM events

# Функции для когортного анализа
SELECT 
    toMonth(registration_date) as cohort,
    daysFromEvent(today(), registration_date) / 30 as months_active,
    count(*) as user_count
FROM users
GROUP BY cohort, months_active

# Расчёт retention метрик
SELECT 
    toDate(first_purchase_date) as cohort_date,
    countIf(last_purchase_date >= first_purchase_date + interval 7 day) as week_retention
FROM customers
GROUP BY cohort_date

6. Параллельная обработка на разных серверах

ClickHouse распределённый и может обрабатывать данные, размещённые на разных серверах.

# Распределённая таблица автоматически обрабатывает запросы параллельно
CREATE TABLE events_distributed AS events
ENGINE = Distributed(cluster_name, current_database, events, rand())

# Запрос выполняется на всех серверах кластера одновременно
SELECT 
    toDate(timestamp) as day,
    count(*) as events_count,
    uniq(user_id) as unique_users
FROM events_distributed
GROUP BY day
ORDER BY day DESC
LIMIT 30

7. Сравнение производительности

Сценарий: Аналитический запрос к таблице с 1 млрд событий

Запрос: SELECT toDate(timestamp) as day, count(*), uniq(user_id) FROM events GROUP BY day

PostgreSQL:
- Память: 500 GB
- Время: 30-60 секунд
- CPU: ~80%

ClickHouse:
- Память: 5-10 GB (благодаря компрессии)
- Время: 100-500 мс
- CPU: ~95% (но работает эффективнее)

8. Когда ClickHouse не подходит

ClickHouse НЕ подходит для:

• OLTP (Online Transaction Processing) — много мелких insert/update/delete
• Транзакции — нет ACID гарантий
• Случайный доступ — медленнее, чем PostgreSQL для точечных запросов
• Обновление строк — дорогая операция

# ❌ ClickHouse подходит ПЛОХО
for i in range(1000000):
    db.insert_one("events", {"user_id": i, "value": random()})

# ✅ ClickHouse подходит отлично
db.bulk_insert("events", million_events_at_once)

Заключение

ClickHouse оптимален для аналитики благодаря:

• Колоночному хранилищу — читает только нужные данные
• Компрессии — занимает минимум памяти
• Векторизации (SIMD) — молниеносная обработка блоков
• Специализированным функциям — готовые инструменты для аналитики
• Параллельной обработке — масштабируется на кластеры

Для OLAP (Online Analytical Processing) ClickHouse в 100-1000 раз быстрее традиционных реляционных БД на тех же данных.