Основным элементом MPP в GreenPlum является Сегмент, который является — неделимой конфигурационной единицей в кластере GP и представляет из себя экземпляр сервера PostgreSQL. Именно сегменты производят чтение и запись данных.
На одной ноде (физическом сервере) может находиться несколько сегментов. Разделение мощностей нод на сегменты необходимы для выравнивания производительности кластера и его масштабирования. Число сегментов на сервере зависит от его основных характеристик (число ядер ЦПУ, объема ОЗУ и размера дискового пространства). Все сегменты на Segment Host кластера имеют одинаковый объем оперативной памяти, размер доступного хранилища.
В примере кластера видно, как сегменты распределились по нодам в зависимости от ресурсов нод. Каждый сегмент резервирует часть ресурсов ноды.
В GreenPlum существует три способа распределения данных по сегментам кластера.
- Distributed replicated — копирование всех строк таблицы на каждый сегмент
- Distributed by — распределение данных по сегментам на основании указанного поля
- Distributed randomly – равномерное распределение данных по сегментам
Данные способы реализуются при создании таблиц в конструкции Create table.
Подробное сравнение способов сегментирования таблиц.
В качестве примера возьмем кластер из 228-ми сегментов. И таблицу из 10 млн строк.
Одно из полей содержит Уникальный ID “MY_ID integer”
- Занимаемое место:
distributed replicated -19 GB.*
distributed by (MY_ID) -97 MB.*
distributed randomly -97 MB.*
Как видим distributed replicated таблица заняла в сотни раз больше места из-за того, что все строки таблицы размещены на каждом из 228-ми сегментах.
* -расчет занимаемого места производился исходя из упрощения — не производится зеркалирования данных. Фактически таблицы будут занимать места в N раз больше, где N — это число зеркальных копий сегментов.
- Равномерность размещения данных:
distributed replicated Не распределяет данные по сегментам, а производит их копирование. В случае таких таблиц равномерность распределения по сегментам абсолютна.
distributed by (MY_ID) Распределяет данные по полю (MY_ID). В нашем случае значения данного поля являются равно-распределёнными. И распределение по сегментам, в этом случае, близко с абсолютному.
Выбор данного способа распределения накладывает ответственность за равномерность.
Для демонстрации создаем две таблицы (table_distr_by, table_distr_by2) и распределяем данные в них по полю (MY_ID).
В таблице table_distr_by в поле (MY_ID) разместим равнораспределённый идентификатор со значениями (1,2,3,4…), а в таблице table_distr_by2 тоже поле заполним одним значением (1) в каждой строке.
С помощью запроса выясним как распределились данные:
Как видно в первом случае у нас сроки таблицы равномерно распределились по сегментам кластера, а во втором случае — все 10 млн строк разместились на одном сегменте.
Неравномерное распределение строк по кластеру в случае с таблицей table_distr_by2 приведет к тому, что место на сегменте №171 закончится раньше, чем на остальных.
Представим, что пользователь создает таблицу, которая сегментирована по неравно распределённым значениям. В процессе заполнения такой таблицы появляется ошибка о том, что нет свободного места. Несмотря на то, что на кластере места в сотни раз больше. Если оставить такую таблицу на кластере, то на данный сегмент более не получится записать данные.
distributed randomly Распределяет строки поровну между всеми сегментами.
Как видим, данные распределились равномерно. Незначительное отклонение в распределении связанно кратностью числа строк таблицы с количеством сегментов и особенностей работы алгоритма распределения.
Если вычислить среднее отклонение всех значений поля от count от 43 859 то получим 0.1%.
Получается, что 99.9% строк будут читаться и записываться одновременно всеми сегментами.
Сравнение скорости записи
- Сравнение скорости запросов к таблицам
Запросы без условий
Запросы с условиями
Запросы с JOIN
Далее производим 9 измерений, связывая между собой сегментируемые тремя способами таблицы.
Сравнение производительности запросов было проведено в условиях исключающий использования HASH данных. В случаях, когда производился JOIN между таблицами с идентичным способом сегментирования создавалась вторая таблица с тем-же набором данных.
Для исключения влияния нагрузки на результат тестирование производилось 3 раза. Во всех случаях отклонения во времени выполнения одного и того-же запроса составляла не более 5%
Встроенный в GreenPlum анализатор запросов и план запросов даёт исчерпывающую информацию о задействованных сегментах и переносах данных между ними. Показатель стоимости запроса COST представляет из себя диапазон значений (пример 126172..464844), разброс которых не позволяет произвести точную оценку эффективности запроса. По этой причине для сравнения запросов использовалось время его выполнения.
Для наглядности нормализуем результаты в процентах от максимального значения. Где минимальное значение – лучший результат.
Выводы
Использование distributed replicated не оправдано. Занимает избыточно много места на диске. Долго записывается и читается, медленно связываются с другими таблицами. Единственный плюс заключается в том, что данные равномерно распределяются по кластеру.
Использование distributed by оправдано, когда заведомо знаем по каким полям данная таблица будет связываться с другими таблицами. И в этом случае связывание покажет наилучшие результаты. Минусом является возможность неравномерного размещения данных на кластере.
Использование distributed randomly оправдано в большинстве случаев. Его легко использовать, так как не нужно указывать поля, по которым будет проходить сегментация. Данные равномерно распределяются по сегментам и не занимают лишнего места.