➡️Параллельная обработка SQL-запросов в Greenplum. Как Greenplum выполняет запросы: что происходит «под капотом»? 👀 1️⃣ Откуда происходит рассылка планов запросов на сегменты? Для ответа на этот вопрос необходимо знать ответ на другой - чем собственно мастер-хост отличается от сегмент-хостов? Не трудно догадаться, что именно к мастер-сегменту подключаются пользователи и отправляют на него все SQL-запросы. Мастер-сегмент не содержит данных, а только принимает входящие подключения, собирает и систематизирует запросы, чтобы маршрутизировать их по сегментам, которые содержат фактические данные и выполняют запросы. 2️⃣Query Dispatcher (Координатор запросов) Какой механизм конкретно отвечает за координирование планов запросов на сегмент-хосты? На ведущем устройстве рабочий процесс запросов называется «query dispatcher» (QD). QD отвечает за создание и отправку плана запроса. Он также накапливает и представляет окончательные результаты. 3️⃣Query Executor (Выполнение запросов на сегментах) Как сегменты выполняют запросы? В сегментах рабочий процесс запроса называется исполнителем запроса (QE, Query Executor). QE отвечает за выполнение своей части работы и передачу ее промежуточных результатов другим рабочим процессам. 🔵🔵🔵🔵🔵🔵🔵🔵 Каждый сегмент отвечает за выполнение операций локальной БД со своим собственным набором данных. Большинство операций с БД, таких как сканирование таблиц, объединение, агрегирование и сортировка, выполняются во всех сегментах параллельно. Каждая операция выполняется в БД сегментов независимо от данных, хранящихся в БД других сегментов. 🔵🔵🔵🔵🔵🔵🔵🔵 4️⃣ Motions Каждый motion - это момент, когда данные перестают обрабатываться локально и начинают «переезжать» по сети. Чем больше motion - тем больше узких мест и падение производительности. 🔵Broadcast motion — копирование всех строк таблицы на каждый сегмент. Как правило для небольших таблиц. В случае, когда данные не распределились по ключу соединения, производится динамическое перераспределение нужных строк из одной из таблиц в другой сегмент. 🔵Redistribute motion — перераспределение строк между сегментами по хэш-ключу. 🔵Gather motion — сбор результатов со всех сегментов на мастер. 5️⃣Slices (слайсы) Slice — это часть плана, над которой сегменты могут работать независимо. План запроса делится на фрагменты везде, где в плане происходит операция motion (движение), по одному фрагменту на каждой стороне motion. Каждому слайсу плана запроса назначен как минимум один рабочий процесс, который работает над назначенной ему частью плана запроса независимо. 6️⃣Gangs Во время выполнения запроса в каждом сегменте будет несколько процессов, работающих над запросом параллельно. Связанные процессы, которые работают над одним и тем же фрагментом плана запроса, но в разных сегментах, называются группами (gangs). По мере завершения части работы кортежи передаются по плану запроса от одной группы процессов к другой в рамках межпроцессного взаимодействия Greenplum. 7️⃣Всегда ли запросы выполняются параллельно на всех сегментах? Определенные запросы могут получать доступ только к данным в одном сегменте, например однострочные операции INSERT, UPDATE, DELETE, SELECT или запросы, которые фильтруют столбцы ключа распределения таблицы. В таких запросах план запроса не рассылается по всем сегментам, а нацелен на сегмент, который содержит затронутые или релевантные строки. 💡Как работает Greenplum при выполнении запроса 🔵Мастер-узел (QD) получает SQL, анализирует, оптимизирует и строит план. 🔵План делится на части — slices. 🔵Каждая часть уходит на свои сегменты (QE), которые работают параллельно. 🔵Результаты собираются обратно через сеть — interconnect. 💛Где чаще всего теряется производительность 🔵Неверно выбранное поле DISTRIBUTED BY → появляются broadcast motion’ы. 🔵Устаревшая статистика (ANALYZE не выполнялся) → оптимизатор думает, что таблица «маленькая». 🔵Сложные запросы с подзапросами и CTE → избыточные вычисления и motion’ы. 🔥Понравился пост? Оставь реакцию, так ты поддержива