Практика на кластере Greenplum

Эта практика предназначена для подготовленного учебного кластера Greenplum 7. Нужны подключение через psql или SQL-клиент, право создавать временные таблицы и несколько primary segments. Выполняй команды в одной сессии: временные таблицы принадлежат ей и исчезнут при отключении. Здесь используются только собственные небольшие наборы; административные изменения не нужны.

Создать распределённый набор

Проверь версию командой SELECT version();. Затем создай временную hash-таблицу и заполни её двадцатью тысячами строк. Каждая строка имеет отдельный record_id, а group_key повторяется у нескольких строк.

CREATE TEMP TABLE mpp_sample (
    record_id integer,
    group_key integer,
    value integer
) DISTRIBUTED BY (record_id);
 
INSERT INTO mpp_sample
SELECT n, n % 100, 1
FROM generate_series(1, 20000) AS t(n);
 
ANALYZE mpp_sample;

Остаток от деления здесь создаёт повторяющиеся значения group_key. Он не вычисляет номер сегмента и не моделирует хеш-функцию Greenplum. Фактическое размещение посмотри через системную колонку:

SELECT gp_segment_id, count(*) AS row_count
FROM mpp_sample
GROUP BY gp_segment_id
ORDER BY gp_segment_id;

Ожидается несколько строк результата: по одной на сегмент, где есть данные. Сумма row_count должна равняться 20000. Числа не обязаны быть абсолютно равны, а конкретные номера и соответствие ключей зависят от кластера. Для таблицы с replicated distribution такой запрос к gp_segment_id использовать нельзя.

Увидеть сбор и перераспределение

Сначала посмотри общую сумму. EXPLAIN ANALYZE выполнит SELECT и покажет фактические показатели:

EXPLAIN ANALYZE
SELECT sum(value) FROM mpp_sample;

Найди чтение, агрегацию и сбор результата в одном месте. В типичном распределённом плане будет Gather Motion, а локальная агрегация уменьшит число передаваемых строк. Итог обычного SELECT равен 20000. Названия и расположение узлов зависят от выбранного оптимизатора.

Теперь измени ключ группировки:

EXPLAIN ANALYZE
SELECT group_key, sum(value)
FROM mpp_sample
GROUP BY group_key;

Таблица размещена по record_id, поэтому строки одной group_key могут находиться на разных сегментах. В типичном плане ищи Redistribute Motion по ключу группы и этапы агрегации. Оптимизатор может выбрать другую форму обмена для небольшого набора: задача — объяснить реальный план, а не добиться заранее заданного текста. Обычный SELECT должен вернуть 100 групп по 200.

Сравнить JOIN и оценки

Создай вторую небольшую таблицу с тем же типом и ключом распределения. В ней будет одна строка для каждого record_id.

CREATE TEMP TABLE mpp_lookup (record_id integer)
DISTRIBUTED BY (record_id);
 
INSERT INTO mpp_lookup
SELECT n FROM generate_series(1, 20000) AS t(n);
 
ANALYZE mpp_lookup;
 
EXPLAIN
SELECT count(*)
FROM mpp_sample s
JOIN mpp_lookup l USING (record_id);

Проверь, требуется ли перемещение между сканированиями и JOIN. Совместимое размещение допускает локальное соединение; Gather для итогового count может остаться. Планировщик вправе выбрать другой вариант по стоимости, поэтому отличай возможность локальности от обещания конкретного плана. Само соединение должно дать 20000 строк до агрегации.

Чтобы увидеть роль статистики, добавь в mpp_sample ещё 20000 строк с новыми record_id, но одной group_key равной 0. Сравни EXPLAIN для фильтра по этой группе до и после ANALYZE. Оценка может измениться; совпадение с точным числом не гарантируется, поскольку статистика использует выборку. Фактических строк этой группы станет 20200.

Что зафиксировать

Запиши версию, число участвующих сегментов, распределение строк и по одному выводу для Gather, группировки и JOIN. Для каждого Motion укажи входной поток и цель передачи. Если ожидаемого оператора нет, объясни выбранную альтернативу по плану.

Это наблюдения именно на твоём кластере, а не универсальные времена Greenplum. Размеры наборов специально невелики, поэтому по ним нельзя выбирать производственное распределение или измерять предел пропускной способности. После работы закрой сессию; её временные таблицы будут удалены.