Каковы преимущества Greenplum для полного сканирования диска?

Question

Как мы знаем, GPDB распределяет элементы БД по нескольким сегментам по заданному хэш-ключу. Я уверен, что это даст лучшую производительность для условных запросов, особенно для тех запросов с данным распределенным ключом / полем, потому что это может значительно уменьшить область сканирования.

Но как насчет полной проверки диска? Например, select count(distinct aField) from table или select aField, count(distinct bField) from table group by aField, ... и т. Д. - запросы без условия.

Таким образом, все сегменты полностью отсканированы, и результаты запроса будут отправлены мастеру для агрегирования по сети. Что мы можем извлечь из такого случая?

Answer 1

Greenplum обрабатывает последовательное сканирование очень быстро, и поскольку ваши данные распределяются по сегментам, это означает, что небольшие фрагменты данных сканируются параллельно несколькими сегментами.

Не говоря уже о том, что вы можете организовать свои данные с правильным подходом ориентации «строка / столбец», что может привести к сканированию еще меньших данных.

Также, если вы говорите об огромных объемах данных, вы, вероятно, будете использовать многораздельные таблицы, что означает еще более быстрые результаты.

Answer 2

Поскольку Greenplum является форком PostgreSQL, предназначенным для параллельного выполнения запросов на нескольких сегментах - если фактические запрашиваемые данные распределены по ним - он может в основном использовать повышенную производительность выполнения на нескольких дисковых системах и отдельных узлах кэши. Затраты на отправку данных на главный узел и окончательную обработку запросов, а также на то, что главному узлу приходится подготавливать запрос каждого узла и отправлять его для обработки, обычно невелики, но значительно увеличиваются, если неагрегированные запросы с окончательной сортировкой должны быть сделано мастером.

Однако, поскольку они только недавно слились в версии 9.4 вышестоящего кода PostgreSQL, основная проблема заявлений о производительности Greenplums заключается в том, что она сравнивается с версией PostgreSQL, которая слишком старая для тех, кто заботится о ней. производительности и не имеет преимуществ от каких-либо улучшений параллельного запроса , которые были введены, начиная с версии 9.6.

Несколько сегментов на хост также не сильно помогают, так как каждый из сегментов ничего не знает о других на одном хосте и, следовательно, конкурирует за ресурсы (дисковый ввод-вывод, операции с памятью, кэш-память ЦП, сеть). , ...) или вам на самом деле нужно ограничить его много на сегмент, как рекомендовано , что может свести вас с ума, потому что некоторые запросы затем просто выливаются на диск для сортировки. Правильно настроенная одиночная установка PostgreSQL 11 должна превзойти любое количество сегментов Greenplum на одном узле просто потому, что у него больше общего кэша, и он на самом деле знает об этом.

TL; DR

PostgreSQL upstream получил много улучшений в последние годы, и для конкретных случаев использования, пожалуйста, рассмотрите возможность использования расширений, а не полного форка.

Кроме того, если вас беспокоит производительность count(distinct ...), вам следует обратить пристальное внимание на как вы считаете .