Greenplum Flashcards
(7 cards)
Дистрибьюция?
Disrtibuted by, randomly, replicated? Что произойдет если мы напишем distributed by поле какое-то? Что чаще используется?
Дистрибьюция — это размещение строк таблицы по сегментам (нодам) кластера.
Она определяет, как данные физически распределяются между узлами MPP-системы.
Существует три основных способа распределения:
DISTRIBUTED BY(multiple or single columns) - преимущественно используется распределение по одной колонке, желательно int и без null
DISTRIBUTED RANDOMLY
DISTRIBUTED REPLICATED
В большинстве ситуаций логика - если есть уникальный для каждого значения клюx(primary key), то вешаем распределение по этому ключу, если нету - делаем randomly
Делать Join лучше всего по ключу распределения, особенно если нам предстоят тяжёлые джоины, тогда ищем primary key, вешаем на него distributed by и джоиним по этому ключу
Если подгружаем какой-то небольшой лёгкий справочник, то можно распределить и целиком по сегментам - replicated
Чаще всего используется DISTRIBUTED BY по бизнес-ключу, особенно если это primary key.
Это даёт:
стабильную дистрибуцию,
минимизацию Motion,
быструю обработку JOIN и GROUP BY.
Если не подобрать ключ — используют RANDOMLY.
Если таблица маленькая — REPLICATED.
Что произойдёт, если мы напишем DISTRIBUTED BY (поле) в Greenplum:
СУБД будет использовать указанное поле, чтобы распределить строки таблицы по сегментам кластера.
Greenplum вычислит хеш от значения этого поля и отправит строку на соответствующий сегмент.
Что это даёт:
Распараллеливание обработки
Каждая нода (сегмент) работает со своей частью данных → ускорение JOIN, GROUP BY, COUNT и других операций.
Оптимизация JOIN
Если JOIN идёт по тому же полю, что и DISTRIBUTED BY, то строки окажутся на одних и тех же сегментах, и Greenplum избежит Redistribute Motion (тяжёлого перемещения данных по сети).
Партиционирование что это?
Типы партиционирования в GP например
Что чаще используется? Если напишем partition by date что произойдет? Для чего мы это делаем? Что это даст?
Партиционирование — это физическое разбиение таблицы на части (партиции) по значению одного или нескольких столбцов.
Каждая партиция — как отдельная подтаблица с собственными данными.
Физическое разделение хранимых данных, по сути создаём несколько таблиц(реально физически выделяются новые файлы) из одной по логическому условию, позволяет выборочно сканировать только те части таблицы, которые соответствуют условию (partition elimination), значительно ускоряя запросы
Существует три способа партиционировать:
PARTITION BY RANGE - создание партиций по диапазону(дат, цен и т.д.)
PARTITION BY LIST - создание партиций по списку(регионы, типы и т.д.)
PARTITION BY default - партицию отделённую таким образом GP будет сканировать всегда
Partition by RANGE - самый стабильный вариант разбить на логически равные и удобные части, в 90% случаев идут диапазоны дат
Сначала происходит Distribution -> потом Partitioning на всех сегментах, т.е. GP сначала распределил таблицу по сегментам, равномерно(в идеале) распределив данные между сегментами, а потом уже внутри сегментов данные дробятся на партиции
Что произойдёт, если написать PARTITION BY date в Greenplum:
Ты создашь партиционированную таблицу, где каждая партиция будет хранить строки с определённым значением или диапазоном дат.
Ускорение запросов с фильтром по дате
Запросы типа WHERE event_date = ‘2024-05-01’ будут читать только нужную партицию, а не всю таблицу (partition pruning).
Упрощение управления данными
Можно легко удалить старую партицию (DROP TABLE events_2022_*) — вместо DELETE.
Типы хранения данных? В GP например какие типы хранения для таблицы мы можем задать?
Append? Optimize? Колоночной или строковый тип хранения? Хит таблица?
Основные виды таблиц:
1. Heap - таблица
2. Append-optimized таблица
Гринплам как OLAP система лучше всего раскрывает себя с Append-Optimized Column-oriented (AOCO) таблицами. Это свойство хранения таблицы по колонкам, когда записи вставляются в конец, а уже имеющиеся не обновляются и не удаляются. Хорошо комбинируется с SCD2 на одной колонке effective_from.
Также есть “heap” – row-oriented , по сути обычные постгрес таблицы. Хорошо подходят для справочников – маленьких таблиц, которые обновляются вручную. Не сжимаются, потому что
Верхнеуровневая архитектура GP? Какие блоки?
Master-node: Здесь развернут главный инстанс PostgreSQL, через него идёт подключение, обрабатываются SQL-запросы, проходит оптимизация
Standby или резервный мастер: Обеспечивает отказоустойчивость, вручную врубается при отказе мастера
Сегментов(каждый сегмент - отдельный инстанс postgres)
Interconnect - узел связи между мастером и сегментом
Segment-host - Хранит и обрабатывает данные по сегментам. Обычно сегментов в Greenplum от 2 до 8. Каждый primary segment - отдельный инстанс PostgreSQL, у которого есть свой зеркальный сегмент(тоже инстанс посгри), который включается в работу при отказе основного
Из архитектуры GP вытекает 2 проблемы
Сомнительная отказоустойчивость - если падает мастер, надо вручную переключать, а значит GP будет простаивать вырубленным, а у этого килотонна последствий от рассинхрона до полной остановки важных вычислений
Невозможность адекватно горизонтально масштабировать на хранилища, которые измеряются в петабайтах:
Слишком высокая нагрузка на interconnect + перегрузка мастера обработкой системных задач + лимиты на количество сегментов(слишком большое кол-во сегментов нерационально поддерживать)
Сами данные в GP где будут лежать?
Данные в Greenplum хранятся на сегментных нодах (segment hosts)
Архитектура:
Master node — управляет запросами, хранилища не имеет.
Segment nodes — на них размещены сегменты, каждый из которых — это фактически экземпляр PostgreSQL, в котором и лежат данные.
Если мы пишем запрос к GP, то как GP будет его обрабатывать? Откуда куда пойдет наш запрос и откуда куда данные будут перетекать?
Когда мы отправляем запрос в Greenplum, он сначала попадает на master node, которая анализирует и оптимизирует запрос, а затем строит план выполнения.
Этот план распределяется по segment-нодам, где и происходит основная обработка данных.
Каждый сегмент выполняет свою часть работы: читает строки, применяет фильтры, агрегирует, джоинит и т.д.
Если нужно соединить данные между сегментами — возникает Motion (перемещение данных по сети): например, Redistribute или Broadcast.
После выполнения сегменты отправляют результаты обратно на master, который собирает финальный ответ и возвращает его клиенту.
Сам master данные не хранит — только управляет планом и координирует выполнение.
Предположим, что мы сделали distributed by по какому-то полю, у нас данные лежат на нескольких сегментах, именно те данные, которые нам нужны в запросе и при этом мы хотим их заджойнить с другой таблицей, распределение у которой по сегментам другое (ключ дистрибьюции разный и мы их джойним). Как запрос будет происходить?
Если мы делаем JOIN двух таблиц в Greenplum, у которых разные ключи дистрибуции, то строки, которые должны соединиться, лежат на разных сегментах.
В этом случае Greenplum не сможет выполнить JOIN локально на сегментах и выполнит Motion-операцию — это перемещение данных между сегментами по сети.
Motion (перемещение данных по сети): например, Redistribute или Broadcast.
При тяжёлом JOIN в Greenplum, если таблицы распределены по разным ключам, система выполняет Redistribute Motion — она перераспределяет строки одной или обеих таблиц по сети между сегментами, чтобы данные, которые должны соединиться, оказались на одном и том же сегменте.
После перераспределения JOIN выполняется на сегментах, а не на мастере.
Master node не участвует в джойне и фильтрации — он только управляет планом и собирает финальный результат.
