Greenplum Flashcards
Расскажи про Greenplum. Что это? #wildberries
Greenplum это распределённая (шардированная) база данных на основе PostgreSQL. Ггринплам версии 6.х создан на основе Postgres 9.4.x, и сильно отстаёт по функционалу от Postgres 16 (latest на сен. 2024). 7я версия пока ещё не используется в продакшене в России (на сен. 2024, насколько мне известно).
Распределённость даёт возможность обрабатывать кратно больший объём данных за счёт горизонтального масштабирования (в обработке участвуют несколько машин, каждая из которых хранит свой кусок каждой таблицы). Также гринплам оптимизирован под OLAP нагрузку.
Что такое дистрибуция в GP? #x5
- Определение: Дистрибуция (distribution) — это механизм распределения строк таблицы по сегментам (data nodes) кластера Greenplum. Каждый сегмент — фактически «мини-база», и при INSERT данные записываются в один из сегментов в зависимости от выбранного ключа.
- Distribution key (ключ дистрибуции) — столбец (или набор столбцов), по которому Greenplum «хеширует» каждую строку, чтобы понять, на какой сегмент она попадёт.
- Зачем это нужно: Основная идея — разделить большие объёмы данных на части, чтобы все узлы (сегменты) могли работать параллельно, обрабатывая свою часть таблицы. Это повышает производительность чтения и записи в режиме MPP (Massively Parallel Processing).
- Как выбрать ключ: Обычно ключ дистрибуции подбирается так, чтобы:
1. Данные более-менее равномерно распределялись по сегментам (не было «горячего сегмента»).
2. Учитывать частые JOIN-ы: если вы регулярно джойните две таблицы по одному и тому же столбцу, имеет смысл выбрать похожие distribution keys, чтобы уменьшить сетевой перекид данных (redistribution). - Ошибки при выборе: если ключ дистрибуции имеет низкую кардинальность (например, статус «active/inactive»), то все «active»-строки окажутся в одном сегменте, создавая сильный дисбаланс.
Рекомендуется ли использовать ключ партиции как ключ дистрибуции? #x5
- Партиционирование (partitioning) и дистрибуция (distribution) — это два разных механизма в Greenplum (и PostgreSQL), хотя порой могут пересекаться.
- Партиционирование разбивает таблицу на отдельные логические/физические «партиции» (обычно по дате или другому признаку), что упрощает управление данными и может ускорять запросы, которые отсеивают ненужные партиции.
- Дистрибуция управляет тем, на какой сегмент попадут строки.
- Когда ключи совпадают:
- Иногда это удобно, чтобы при запросах, использующих и партицию, и дистрибуционный столбец, «движение данных» между сегментами снижалось.
- Если всё «ложится» ровно по одному полю (например, по date), и почти все запросы группируют/фильтруют данные по date, может быть целесообразно сделать их одинаковыми.
- Когда не рекомендуется:
- Если партиционируете таблицу по «грубому» признаку (например, по месяцу), а ваш дистрибуционный ключ (для равномерного распределения) совсем другой (например, user_id), тогда их совпадение не даст пользы.
- Может случиться «горячая партиция» на одном сегменте, если число партиций мало, а данные внутри каждой партиции сильно скошены.
- Итог: Всё зависит от того, какие поля чаще всего участвуют в JOIN и фильтрации. Использование одного и того же ключа партиции и дистрибуции — лишь один из вариантов, который иногда помогает, но не является универсальным решением.
join elimination #x5
Суть: Join elimination — это оптимизация на уровне планировщика запросов (optimizer), при которой база данных «выбрасывает» из плана выполнения лишнее соединение (JOIN), если оно не влияет на итоговые колонки или результаты.
- Пример:
SELECT t1.id
FROM t1
JOIN t2 ON t1.id = t2.id; - Если в столбце t2.id нет уникальных ограничений, и нигде в запросе не используется столбец из t2, оптимизатор может решить, что результат будет идентичен просто SELECT id FROM t1.
- Преимущество: Устраняет ненужную работу при выполнении JOIN, экономит ресурсы (CPU, память, сетевой трафик).
- В Greenplum: Используется часть механизма, унаследованного от PostgreSQL, вместе с собственными расширениями оптимизатора. На практике join elimination помогает особенно в случаях, когда у вас сложные запросы с несколькими JOIN, но часть таблиц только «присоединена» формально и не влияет на набор выходных данных.
Какие есть недостатки у гринпалма? #Ярослав
. масштабирование упирается в единственный мастер
. сильно лучше работает с серией относительно коротких запросов, в сравнении с длинными цепочками CTE
. в 6й версии не работает predicate pushdown для функций - сначала рассчитается датасет целиком, а уже потом будет фильтроваться
AOco, heap. Что это? Что используем для OLAP а что для OLTP #Ярослав
ак я понял AOco - OLAP , heap - OLTP
- Heap таблицы
Heap таблицы представляют собой традиционный способ хранения данных в PostgreSQL и, соответственно, в Greenplum.
Структура: Данные хранятся в строках без какой-либо специфической структуры для оптимизации хранения.
Характеристики:
Производительность: Heap таблицы хорошо подходят для транзакционных нагрузок, где важно быстрое выполнение операций вставки и обновления.
Индексы: Часто используются вместе с индексами для ускорения доступа к данным, особенно при поиске и фильтрации.
Фрагментация: Из-за частых операций вставки и удаления может возникнуть фрагментация, что ухудшает производительность чтения.
Сценарии использования: Heap таблицы идеальны для OLTP (онлайн-транзакционной обработки) и сценариев, где важна высокая скорость обработки транзакций. - AOCO (Append-Optimized Columnar)
AOCO — это специальный формат хранения данных, разработанный для аналитических задач в Greenplum.
Структура: Данные хранятся в колонках, что оптимизирует производительность при выполнении аналитических запросов, которые часто обращаются к определённым столбцам.
Характеристики:
Производительность: AOCO оптимизирован для операций вставки и чтения, обеспечивая быстрый доступ к данным.
Сжатие: Позволяет эффективно сжимать данные, что уменьшает объем хранимых данных и ускоряет чтение.
Минимизация фрагментации: Обеспечивает минимальную фрагментацию за счет использования механизма добавления данных, что особенно важно для аналитических запросов.
Сценарии использования: AOCO таблицы отлично подходят для OLAP (онлайн аналитической обработки) и аналитических приложений, где важна скорость выполнения запросов и возможность эффективного анализа данных.
что- есть merge join #x5
- Merge Join — один из классических алгоритмов соединения в базах данных (наряду с Nested Loop и Hash Join).
- Как работает:
1. Оба набора данных (две таблицы или результаты промежуточных подзапросов) предварительно отсортированы по ключу соединения.
2. Алгоритм идёт «параллельно» по обеим отсортированным наборам, «сливая» их (похож на операцию merge в сортировке «merge sort»). - Плюсы:
o Если данные уже физически отсортированы по ключу (или есть индекс, позволяющий быстро получить отсортированный результат), Merge Join может быть очень быстрым.
o Подходит для больших наборов данных, если сравнивать с Nested Loop (который может быть дорогим при больших таблицах). - Минусы:
o Требует предварительной сортировки, если наборы данных не отсортированы — это тоже расходы.
o Может проигрывать Hash Join, когда ключи соединения разнообразны, а сортировка слишком дорога или мы можем быстро построить хеш-таблицу. - В Greenplum: При MPP-архитектуре часто используется Hash Join (так как распределённые узлы могут быстро «разливать» данные и строить хеш-таблицы). Но Merge Join бывает полезен, если таблицы уже отсортированы или мы хотим минимизировать использование памяти под хеш.
Что такое сжатие и доступ? #Ярослав
Сжатие (Compression)
Сжатие позволяет уменьшить объем хранимых данных, что особенно полезно для колонных таблиц, таких как AOCO. В Greenplum доступны различные алгоритмы сжатия, такие как:
PGLZ: Эффективное сжатие для текстовых данных.
LZ4: Быстрое сжатие с хорошим уровнем компрессии.
Zlib: Хороший компромисс между скоростью и уровнем сжатия.
- Доступ (Distribution)
Параметр DISTRIBUTED BY определяет, как данные будут распределяться по сегментам. Это важно для оптимизации выполнения запросов.
HASH: Данные распределяются на основе хеш-функции по указанным столбцам.
RANDOM: Данные распределяются случайным образом, что может быть полезно в некоторых сценариях.
ROUND ROBIN: Данные равномерно распределяются по всем сегментам
В Greenplum, как и в других системах управления базами данных, DDL (Data Definition Language) команды позволяют создавать и изменять объекты базы данных, такие как таблицы, индексы и схемы. Важно учитывать различные параметры при создании объектов, чтобы оптимизировать производительность и управление данными. Ниже представлены некоторые полезные DDL параметры, которые можно использовать в Greenplum - Партиционирование (Partitioning)
Партиционирование помогает управлять большими таблицами, разбивая их на более мелкие части, что улучшает производительность.
Можно использовать диапазон (RANGE), список (LIST) или хеш (HASH) для создания партиций. - Ограничения (Constraints)
При создании таблиц полезно задавать ограничения, такие как PRIMARY KEY, FOREIGN KEY, UNIQUE, чтобы обеспечить целостность данных. - Колонки с именами по умолчанию (Default Values)
Задайте значения по умолчанию для колонок, чтобы упростить ввод данных и избежать ошибок.
операции update, delete, merge в append-optimized таблице #x5
- Append-Optimized таблицы (AO) — это формат хранения в Greenplum, который оптимизирован для «больших» вставок (bulk insert) и секвенциального чтения.
- Принцип работы:
o При INSERT строки дописываются в конец файла (append).
o При UPDATE или DELETE AO-таблица фактически создаёт новые версии строк (MVCC), а «старые» версии помечаются как удалённые/неактуальные.
o MERGE (аналог upsert) сочетает в себе INSERT и UPDATE/DELETE, также создавая новые версии. - Проблемы:
o Из-за множественных обновлений или удалений таблица может «раздуться» (bloat). Старые версии строк остаются в файле, пока не будут очищены vacuum-процессом.
o UPDATE/DELETE в AO-таблицах — операции относительно «дорогие» по сравнению с массовыми INSERT. - Рекомендация:
o Стараться минимизировать частые одиночные обновления/удаления в AO-таблицах. Либо использовать стратегии bulk-update (с промежуточными таблицами) и регулярный VACUUM.
o AO-таблицы отлично подходят для аналитических систем, где INSERT преобладают над UPDATE/DELETE.
Когда лучше партиционирование (partitioning) вместо индексов и наоборот #Ярослав
Пртиционирование в Greenplum — это метод управления данными, позволяющий делить большие таблицы на более мелкие, управляемые сегменты (партиции).
- Что такое партиционирование?
Партиционирование — это процесс разделения таблицы на подтаблицы на основе определенных критериев, таких как диапазоны значений, списки значений или хеш-функции. Каждая партиция может храниться на отдельном сегменте, что позволяет обрабатывать данные параллельно. - Типы партиционирования
Диапазон (Range Partitioning): Данные распределяются по партициям на основе диапазонов значений, например, по месяцам или годам.
Список (List Partitioning): Каждая партиция соответствует определенному списку значений, что позволяет группировать данные по категориям.
Хеш (Hash Partitioning): Данные распределяются случайным образом по партициям на основе хеш-функции, обеспечивая равномерное распределение без явных критериев. - Преимущества партиционирования
Улучшенная производительность: Запросы, фильтрующие по партиционированным столбцам, могут использовать только соответствующие партиции, что уменьшает объем данных для обработки и ускоряет выполнение запросов.
Упрощенное управление: Легкость в добавлении и удалении партиций позволяет удобно управлять данными, например, архивировать старые записи.
Снижение фрагментации: Партиционирование помогает минимизировать фрагментацию, поскольку новые данные могут добавляться в конкретные партиции. - Партиционирование vs Индексы
Эффективность: Партиционирование часто оказывается более эффективным для больших объемов данных, так как снижает объем сканируемых данных. В то время как индексы ускоряют доступ к данным, они не всегда уменьшают объем сканирования.
Затраты: Поддержка индексов может быть ресурсоемкой, в то время как партиционирование позволяет избежать этих затрат, управляя данными более эффективно.
Поддержка транзакционности в append-optimized таблице #x5
- MVCC (Multi-Version Concurrency Control): Greenplum, как и PostgreSQL, использует многоверсионность. Это означает, что каждая операция (INSERT, UPDATE, DELETE) порождает новую версию строки.
- В AO-таблицах:
- Новые версии записываются в файлы AO-сегментов. Старые версии «не удаляются немедленно», а становятся невидимы новым транзакциям после коммита.
- Транзакционная целостность (ACID) соблюдается: чтения из одной транзакции не пересекаются с незакоммиченными изменениями другой транзакции и т. п.
- Вакуумация: Так как AO-таблицы могут «копить» удалённые/устаревшие версии, «VACUUM» нужен для физической очистки неактуальных строк, чтобы освобождать место.
- Вывод: AO-таблицы поддерживают транзакционность, но за счёт механизма версионности, что может приводить к накоплению неактуальных версий при большом количестве UPDATE/DELETE.
Поддержка сжатия в heap таблице #x5
- В Greenplum есть два основных типа таблиц: Heap (как в PostgreSQL) и Append-Optimized (AO).
- AO-таблицы обеспечивают полноценное блочное сжатие данных (например, ZLIB, ZSTD, SNAPPY и пр.), что может значительно экономить место, особенно в колоночных AOCO (append-optimized column-oriented).
- Heap-таблицы:
- В классическом PostgreSQL поддерживается «TOAST» для крупных значений, но это не совсем то же самое, что блочное сжатие.
- В Greenplum heap-таблицы не имеют таких возможностей гибкого сжатия, как AO-таблицы.
- Результат: Если требуется компрессия данных, особенно столбцовая (Column-oriented AOCO), рекомендуют AO-таблицы. Heap-таблицы обычно не применяют для больших объёмов, где нужна высокая степень сжатия.
Что такое MPP, в чём основное свойство? #x5
- MPP (Massively Parallel Processing) — это архитектурный подход, при котором одна большая задача разбивается на множество подзадач, которые одновременно исполняются на разных узлах (nodes).
- В Greenplum:
- Существует мастер-нода (Master), которая принимает запрос.
- Есть сегменты (Data Nodes), которые фактически хранят части данных (реплики, шарды).
- Когда приходит запрос, мастер «планирует» его с учётом дистрибуции и рассылает подзапросы сегментам. Каждый сегмент обрабатывает только свои данные. Затем результаты собираются и возвращаются клиенту.
- Основное свойство: Горизонтальное масштабирование. Можно добавить в кластер новые сегменты, и общая производительность вырастет пропорционально (при условии, что данные также распределены).
- Преимущество: позволяет работать с очень большими таблицами и сложными аналитическими запросами быстрее, чем в традиционной «одноузловой» архитектуре.
External tables - внешние таблицы, PXF? #Ярослав
- Внешние таблицы (External Tables)
Внешние таблицы позволяют создавать ссылки на данные, находящиеся вне Greenplum. Эти таблицы не хранят данные, а лишь описывают, как к ним обращаться.
Форматы данных: Greenplum поддерживает различные форматы данных, включая CSV, JSON, Avro и Parquet. Это позволяет работать с разнообразными источниками данных. - PXF (Platform Extension Framework)
PXF — это мощный компонент, который расширяет возможности Greenplum для работы с внешними данными.
Архитектура: PXF действует как посредник между Greenplum и внешними системами хранения данных, такими как HDFS и S3. Он использует протоколы, такие как HTTP и HDFS, для доступа к данным.
Профили: PXF предоставляет различные профили для работы с разными источниками данных, что позволяет легко настраивать доступ к данным. Например, можно использовать профили для работы с HDFS, Hive, JSON, Parquet и другими форматами. - Преимущества использования внешних таблиц и PXF
Гибкость: Внешние таблицы позволяют интегрировать данные из разных источников, не перемещая их в Greenplum, что обеспечивает гибкость в работе с данными.
Производительность: PXF позволяет оптимизировать запросы, используя параллельные операции чтения, что улучшает производительность работы с большими объемами данных.
Упрощенное администрирование: Работая с внешними таблицами, администраторы могут легко обновлять и изменять внешние источники данных, не затрагивая внутренние схемы базы данных. - Сценарии использования
Аналитика данных: Внешние таблицы и PXF идеально подходят для аналитических приложений, которые требуют доступа к большим объемам данных, находящимся вне Greenplum.
Интеграция данных: Они облегчают интеграцию с другими системами хранения данных, такими как Hadoop и облачные решения.
Чем отличаются дистрибуция и партиционирование? #x5
o Дистрибуция — распределение строк таблицы по сегментам кластера (горизонтальное «распараллеливание»).
o Партиционирование — логическое деление одной таблицы на несколько секций (partitions) внутри одного или нескольких сегментов, обычно по диапазону дат или другим критериям.
Перекос данных в GP, что делать? #Ярослав
Это негативный результат неверно выбранной стратегии распределения данных. Гринплам работает со скоростью самого медленного сегмента, также как упряжка лошадей бежит со скоростью самой уставшей лошади.
Проверить перекос можно через запрос к системному полю gp_segment_id, которое есть в каждой таблице, но скрывается при select *:
SELECT COUNT(1), gp_segment_id FROM <table-name> GROUP BY gp_segment_id ORDER BY 1 desc;
Перекос это когда разница между максимальным и минимальным числом строк в сегментах различается на 10% и более.</table-name>
Возможные причины перекоса:
. ключ распределения не указан явно, поэтому гринпламом выбран первый столбец (если нет PK constraint), в котором может быть много повторяющихся значений или null’ов
. выбранный ключ распределения содержит много одинаковых значений (null, идентификатор транзакций самого большого клиента или наиболее популярной категории товаров)
Способы борьбы с перекосом:
. ленивый способ, который сделает все запросы к таблице одинаково медленными: distributed randomly
. лучше - мониторить состояние max count, min count по gp_segment_id по активным табличкам и перераспределять данные до того, как произойдёт большое падение
. идеально - провести профилирование данных, обсудить с аналитиками, и понять, как будет использоваться таблица хотя бы в ближайшем будущем; выбирать ключ распределения “экспертно”
Что такое репликация? #x5
- Определение: Репликация — это процесс копирования данных (иногда в реальном времени, иногда с задержкой) между узлами/серверами, с целью обеспечить отказоустойчивость, балансировку нагрузки на чтение или геораспределённость.
- В Greenplum:
o Когда говорят о «репликации» в контексте GP, чаще всего имеют в виду «зеркалирование сегментов» (mirroring).
o В типичной установке Greenplum каждый сегмент (primary) может иметь соответствующий mirror-сегмент, на который пишутся те же данные.
o Если узел с primary-сегментом выходит из строя, система может переключить операции на соответствующий mirror-сегмент (failover).
o Таким образом, мы получаем отказоустойчивость на уровне сегментов. - Синхронная и асинхронная репликация:
o В некоторых СУБД (включая PostgreSQL) поддерживаются различные режимы (sync/async), влияющие на время записи и гарантию консистентности. В Greenplum зеркалирование, как правило, настраивается в синхронном режиме, чтобы при сбое не потерять данные (хотя в новых версиях есть возможность гибкой настройки). - Другие формы репликации (логическая репликация, репликация на уровне WAL и т.д.): В Greenplum используются в специфичных случаях (например, внешние системы), но базовая репликация — это зеркалирование сегментов.
Зачем нужна:
1. Отказоустойчивость: потеря одного узла не приводит к остановке кластера.
2. Балансировка чтения (в некоторых СУБД): реплики могут использоваться как read-only копии, уменьшая нагрузку на основную базу. В Greenplum обычно чтение идёт с primary-сегмента, но возможны и другие подходы, если настроен инструмент наподобие load balancing.
Ключевые моменты: зеркалирование (mirroring) сегментов, горячий (или полугорячий) резерв, возможность быстрого переключения на реплику.
Как происходит разделение данных в гринпалме? #Ярослав
- Архитектура Greenplum
Greenplum использует архитектуру Master-Segment,
Master узел: Управляет распределением данных и координирует выполнение запросов.
Segment узлы: Хранят часть данных и обрабатывают запросы параллельно, обеспечивая высокую производительность. - Методы распределения данных
Greenplum предлагает несколько стратегий для распределения данных:
2.1. Hash-распределение
Данные распределяются по сегментам на основе хеш-функции, применяемой к выбранному столбцу (или столбцам). Это обеспечивает равномерное распределение данных и позволяет эффективно обрабатывать запросы, использующие фильтрацию по хешируемым столбцам.
2.2. Round-robin распределение
Данные равномерно распределяются по всем сегментам без учета значений. Этот метод полезен, когда нет явного столбца для хеширования, и позволяет достичь равномерного распределения данных.
2.3. Random распределение
Данные распределяются случайным образом по сегментам. Этот метод не гарантирует равномерного распределения и используется в специфических сценариях, когда важна простота. - Учитываемые факторы
При выборе метода распределения данных следует учитывать:
Запросы и нагрузки: Как часто выполняются определенные запросы и какие столбцы используются для фильтрации.
Объем данных: Объем хранимых данных и количество сегментов.
Сбалансированность: Как обеспечить равномерное распределение данных для минимизации узких мест. - Преимущества распределения данных в Greenplum
Масштабируемость: Легко добавлять новые сегменты для обработки увеличивающихся объемов данных.
Производительность: Параллельная обработка данных на сегментах улучшает скорость выполнения запросов.
Устойчивость: Потеря одного сегмента не влияет на доступность данных благодаря дублированию и восстановлению.
Что такое партиционирование, как оно происходит? #x5
- Партиционирование (Partitioning) — это деление большой таблицы на более мелкие «логические» части (партиции), каждая из которых физически хранится отдельно (в Greenplum и PostgreSQL партиции могут быть «child»-таблицами или внутренними сегментами).
- Как происходит:
1. Определяется признак партиционирования (обычно поле даты или другой целочисленный/дискретный столбец).
2. Создаётся партиционная схема (например, PARTITION BY RANGE (дата) INTERVAL ‘1 month’), в результате чего СУБД создаёт структуры (подтаблицы) для каждой партиции (2019_01, 2019_02, и т. д.).
3. Когда вставляются данные, Greenplum автоматически направляет строку в нужную партицию согласно значению ключа. - Преимущества:
o Ускорение запросов: если запрос обращается, например, только к данным за один месяц, СУБД может «пропустить» остальные партиции («partition pruning»).
o Удобство администрирования: например, легко «отрезать» или «присоединить» старые данные (ALTER TABLE … DROP PARTITION).
o Уменьшение блокировок: при операциях DDL / maintenance можно оперировать отдельными партициями без затрагивания всей таблицы. - Взаимосвязь с дистрибуцией: в Greenplum есть два уровня — партиционирование (для логического разбиения внутри одного сегмента) и дистрибуция (распределение строк по сегментам). Их можно комбинировать, но это уже более сложная архитектура.
Вывод: Партиционирование в Greenplum (и PostgreSQL) очень полезно при больших объёмах данных и регулярных запросах с отсечением по партиционному ключу (чаще всего — по дате).
Есть 2 таблицы в GP распределенных по серверу. Надо эти 2 таблицы сджоинить. Как это сделать на физическом уровне? #x5
- Суть задачи: У нас есть 2 большие таблицы, каждая распределена по всем сегментам кластера (через distribution key). При выполнении запроса SELECT … FROM table1 JOIN table2 ON … Greenplum должен «объединить» строки, хранящиеся на разных сегментах.
- Что делает Greenplum:
o Shuffle (re-distribution): если у таблиц отличаются дистрибуционные ключи или ключи совпадают, но JOIN идёт по другим столбцам, Greenplum может перемешать (shuffle) некоторые данные. То есть часть строк с одного сегмента пересылается на другой, чтобы на каждом сегменте оказались парные строки, готовые к соединению.
o Broadcast: если одна из таблиц небольшая, оптимизатор может принять решение «раскидать» (broadcast) всю её целиком на все сегменты, чтобы вторую таблицу не гонять по сети. Тогда JOIN будет выполняться «локально» на каждом сегменте.
o No movement: если у таблиц совпадает дистрибуционный ключ и этот ключ используется в условии JOIN, данные уже «совпадают» по сегментам. В этом случае Greenplum может выполнить JOIN без дополнительной передачи строк по сети (т.н. «co-located join»). Это самый эффективный сценарий, так как нет большого сетевого трафика.
- Как это выглядит «на физическом уровне»:
1. Master (координатор) анализирует план запроса.
2. Определяет, нужно ли перетасовывать данные по сегментам. Это может быть Shuffle (redistribute), Broadcast, или No movement.
3. Сегменты обмениваются нужными «кусками» данных.
4. Каждый сегмент выполняет JOIN над локальным набором строк и возвращает результат.
5. Master собирает итоги и отдаёт клиенту. - Оптимизация: Чтобы уменьшить сетевой overhead, рекомендуется:
o Дистрибуировать таблицы по столбцам, которые часто используются для JOIN.
o Использовать одну и ту же схему distribution key, если это уместно.
o Не дистрибуировать большие таблицы с очень низкой кардинальностью ключа (иначе получится «горячий» сегмент).
o Если одна таблица заметно меньше другой, можно подумать о Broadcast.
Итог: При физическом выполнении JOIN Greenplum либо «перемешивает» данные между сегментами (Shuffle), либо делает Broadcast «малой» таблицы, либо, если ключи «совпадают», JOIN выполняется без движения данных (co-located join).
Расскажи про архитектуру гринпалма #Я
