MPP-архитектура

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 12, остальные разбираются в тренажёре.

1. #gp_architecture1 / 5
   Что такое primary- и mirror-сегменты в Greenplum?

   A)Mirror-сегмент постоянно обслуживает запросы наравне с primary, удваивая пропускную способность чтения

   B)Primary и mirror хранят разные части данных, вместе составляя полный набор без дублирования

   C)Primary хранит и обрабатывает свою часть данных; mirror — его синхронная копия на другом узле для отказоустойчивости

   D)Mirror — это резервная копия на ленте, к которой обращаются при полном крахе кластера

   показать ответ и разбор

   +C)Primary хранит и обрабатывает свою часть данных; mirror — его синхронная копия на другом узле для отказоустойчивости

   // разбор: Каждый primary-сегмент — это отдельный экземпляр Postgres, хранящий и обрабатывающий свою долю данных. Mirror — его зеркальная копия на другом хосте, синхронно получающая изменения. Если primary падает, кластер переключается на mirror без потери данных, продолжая работу. Так Greenplum переживает отказ узла. Аналогично у координатора есть standby. Размещение зеркал на других хостах критично: иначе падение одной машины унесёт и primary, и mirror.

2. #gp_architecture2 / 5
   Как выполняется один SQL-запрос в Greenplum?

   A)Координатор выполняет весь запрос сам, последовательно перебирая данные каждого сегмента по очереди

   B)Запрос целиком выполняется на одном выбранном сегменте, а остальные всё это время простаивают

   C)Сегменты не обмениваются данными между собой, джойн идёт на координаторе

   D)Параллельно на всех сегментах + обмен через interconnect + сбор наверх

   показать ответ и разбор

   +D)Параллельно на всех сегментах + обмен через interconnect + сбор наверх

   // разбор: Координатор превращает SQL в распределённый план и раздаёт его всем сегментам. Каждый сегмент выполняет свою часть над локальными данными параллельно с остальными. Когда шаг требует данных с других сегментов (джойн/агрегация не по ключу распределения), сегменты обмениваются строками через сеть interconnect (операции motion). В конце строки собираются на координатор (gather) и уходят клиенту. Параллелизм по сегментам — источник производительности, а сетевой обмен между ними — главная статья расходов.

3. #gp_architecture3 / 5
   Что показывает системный столбец gp_segment_id у строки таблицы?

   A)Номер сегмента, на котором физически лежит строка; по нему диагностируют перекос распределения

   B)Порядковый номер строки внутри таблицы, присваиваемый последовательно при каждой вставке данных

   C)Идентификатор транзакции, в которой строка была вставлена или последний раз изменена

   D)Приоритет строки, определяющий, в каком порядке сегменты будут её обрабатывать при запросе

   показать ответ и разбор

   +A)Номер сегмента, на котором физически лежит строка; по нему диагностируют перекос распределения

   // разбор: gp_segment_id — скрытый системный столбец, возвращающий номер сегмента, где хранится строка. Он определяется ключом распределения (хеш) или случайно (RANDOMLY). Практическая польза — диагностика перекоса: SELECT gp_segment_id, count(*) FROM t GROUP BY 1 показывает, сколько строк на каждом сегменте; сильный разброс означает плохой ключ распределения (data skew), из-за которого один сегмент перегружен, а запрос идёт со скоростью самого медленного.

4. #gp_architecture4 / 5
   Зачем брать Greenplum вместо одного мощного PostgreSQL?

   A)Greenplum быстрее PostgreSQL на большинстве задач, включая частые точечные запросы по одной строке

   B)Объём/нагрузка сверх одной машины → параллелизм по многим узлам

   C)Greenplum нужен ради поддержки SQL, которого в обычном PostgreSQL якобы нет

   D)Причина — экономия лицензий, по возможностям он не отличается от одного PostgreSQL

   показать ответ и разбор

   +B)Объём/нагрузка сверх одной машины → параллелизм по многим узлам

   // разбор: Один Postgres упирается в ресурсы одной машины: диск, память, одно ядро на запрос по сути. Greenplum распределяет данные и вычисления по десяткам сегментов на многих серверах, обрабатывая терабайты аналитическими сканами и агрегациями параллельно — то, что одному Postgres недоступно. Цена — сложность кластера, сетевой обмен между сегментами и то, что это OLAP-движок (плохо подходит под частые точечные OLTP-операции). Для небольших объёмов обычный Postgres проще и достаточен.

5. #gp_architecture5 / 5
   Почему тяжёлые операции, стягивающие все строки на координатор, — антипаттерн в Greenplum?

   A)Это, наоборот, самый быстрый способ: координатор мощнее сегментов и обработает всё эффективнее их

   B)Никакой проблемы нет: Greenplum автоматически распараллелит и работу на координаторе по сегментам

   C)Координатор один и не параллелится: собрав всё на него, теряешь MPP и упираешься в ресурсы одного узла (узкое место, риск OOM)

   D)Проблема лишь в том, что при этом расходуется чуть больше сетевого трафика, на скорость это не влияет

   показать ответ и разбор

   +C)Координатор один и не параллелится: собрав всё на него, теряешь MPP и упираешься в ресурсы одного узла (узкое место, риск OOM)

   // разбор: Сила Greenplum — параллельная работа сегментов; координатор лишь координирует и собирает финал. Запросы, которые заставляют стянуть большие объёмы на координатор (огромный gather без предварительной агрегации на сегментах, сортировка/дедуп всего набора наверху, обработка на стороне клиента построчно), обесценивают MPP: вся работа ложится на один узел, который упирается в его память и CPU (риск OOM, длинные очереди). Правильно — максимум фильтрации и агрегации выполнять на сегментах, а наверх поднимать уже сжатый результат.