Greenplum

Что такое Greenplum

Greenplum — массивно-параллельная (MPP, Massively Parallel Processing) СУБД для аналитики, построенная на форке PostgreSQL. Задача — обрабатывать объёмы, которые не помещаются на один сервер: данные и вычисления распределяются по десяткам узлов, каждый работает со своей частью, результаты собираются вместе.

Наследство PostgreSQL даёт практическое преимущество: знакомый SQL, совместимые драйверы и клиенты, psql для подключения. Аналитик, умеющий писать запросы к Postgres, работает с Greenplum почти без переучивания — а под капотом это распределённая система на кластер серверов.

Применяется как ядро корпоративного хранилища данных, где хранится история за годы и по ней считают отчёты.

Архитектура

                  Клиент (psql, BI)
                         │
                  ┌──────────────┐
                  │ Master (координатор) │  ← метаданные, план запроса
                  └──────────────┘
                         │  раздаёт план всем сегментам
     ┌───────────┬───────┴───────┬───────────┐
     ▼           ▼               ▼           ▼
 Segment 1   Segment 2       Segment 3   Segment 4   ← свои диски, свои данные

• Master (координатор) — принимает запрос, строит план, раздаёт его сегментам, собирает результат. Пользовательских данных не хранит.
• Segment — отдельный экземпляр PostgreSQL со своей частью данных. Каждый обрабатывает только свои строки.
• Interconnect — сеть между узлами. Часто становится узким местом, поэтому под неё выделяют быстрые каналы.
• Standby master и зеркала сегментов — репликация для отказоустойчивости; отказ сегмента без зеркала останавливает весь кластер.

Запрос SELECT count(*) FROM events выполняется всеми сегментами одновременно, каждым по своим данным, а master складывает частичные суммы. Отсюда линейный рост скорости с числом узлов.

Ключ распределения

Главное решение при проектировании таблицы — как разложить строки по сегментам:

CREATE TABLE orders (
    id bigint, user_id bigint, created_at date, total numeric(10,2)
)
DISTRIBUTED BY (user_id);      -- по хешу user_id

CREATE TABLE currency_rates (code text, rate numeric)
DISTRIBUTED REPLICATED;        -- маленький справочник копируется на все сегменты

Два правила, определяющие производительность:

• Равномерность. Плохой ключ собирает данные на одном сегменте, и он работает за всех, пока остальные простаивают. Ключ с малым числом значений (status, region) или с большой долей NULL — типичная ошибка.
• Совпадение ключей у соединяемых таблиц. Если orders и order_items распределены по одному ключу, JOIN идёт локально внутри сегмента. Если нет — сегменты вынуждены пересылать строки друг другу по сети (motion), и это самая дорогая операция в MPP.

-- Проверить перекос: сколько строк на каждом сегменте
SELECT gp_segment_id, count(*) FROM orders GROUP BY 1 ORDER BY 2 DESC;

Разница цифр в разы означает, что ключ выбран неудачно.

Партиционирование и хранение

Распределение и партиционирование — разные вещи и работают вместе: DISTRIBUTED BY раскладывает данные между сегментами, PARTITION BY режет данные внутри каждого сегмента.

CREATE TABLE events (ts timestamptz, user_id bigint, payload text)
WITH (appendoptimized=true, orientation=column, compresstype=zstd)
DISTRIBUTED BY (user_id)
PARTITION BY RANGE (ts)
  (START ('2026-01-01'::date) END ('2027-01-01'::date) EVERY (INTERVAL '1 month'));

Append-optimized таблицы с колоночной ориентацией и сжатием — стандарт для больших фактов: читаются только нужные колонки, место экономится в разы. Обычные heap-таблицы из PostgreSQL оставляют для небольших изменяемых справочников.

Чего не ждать

Greenplum — аналитическая система, и попытка использовать её как обычную базу приложения обречена:

• Не OLTP. Точечные SELECT по ключу и одиночные INSERT идут через координатор и медленны. Тысячи мелких транзакций в секунду — не сюда.
• Master — узкое место и точка отказа. Через него проходит каждый запрос; standby master обязателен.
• Дорогая эксплуатация. Кластер из десятков узлов требует администрирования, а перекос данных и лишние motion — постоянный предмет тюнинга.

Greenplum или ClickHouse

Обе системы решают аналитические задачи, но по-разному:

Грубо: ClickHouse быстрее на «посчитать метрики по потоку событий», Greenplum сильнее там, где нужны сложные многотабличные модели, полноценный SQL и ETL внутри хранилища.

Про лицензию: открытая версия Greenplum развивалась как Apache 2.0, но в 2024 году VMware закрыла публичный репозиторий, после чего сообщество продолжило работу в форках. Проверяйте текущий статус проекта, прежде чем закладывать его в новую систему.

Связанные термины

• PostgreSQL — основа, на которой построен Greenplum
• DWH / хранилища данных — где применяется MPP
• ClickHouse — основной конкурент в аналитике
• OLAP — класс задач Greenplum
• Шардирование — тот же принцип, что и распределение по сегментам
• Кластер — форма, в которой Greenplum существует