13.02.2025 08:36
ibshcherbakov 13 525 Источник

Некоторое время назад руководитель задал мне вопрос: «Какой MPP-кластер лучше с точки зрения разработчика: Arenadata 6 или Cloudberry?» Я рассказал про версии PostgreSQL, лежащие в основе этих кластеров, - 9 и 14 соответственно. Еще сказал, что для детального анализа производительности желательно развернуть кластеры на серверах, заполнить их данными и выполнить побольше разных запросов.

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

Методика проведения экспериментов

Для проведения экспериментов на виртуальные машины были установлены MPP-кластеры:

1.     Arenadata DB 6.27 из репозитория:

https://github.com/arenadata/gpdb

по инструкции:

https://github.com/arenadata/gpdb/blob/adb-6.x/README.linux.md

2.     Cloudberry Database 1.6 из репозитория:

https://github.com/cloudberrydb/cloudberrydb

по инструкции:

https://cloudberry.apache.org/docs/cbdb-linux-compile

Настройки виртуальных машин – одинаковые:

  • оперативная память: 16 Гб,

  • процессоры: 4.

Конфигурации кластеров – одинаковые:

  • вариант конфигурации: Single-Node,

  • количество сегментов: 3,

  • зеркалирование сегментов: да.

Версии PostgreSQL в кластерах:

select version();
PostgreSQL 9.4.26 (Greenplum Database 6.27.1_arenadata59+dev.1.gcbb3338b74 build dev) on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, 64-bit compiled on …
PostgreSQL 14.4 (Cloudberry Database 1.6.0+dev.641.ge36838cea1 build dev) on x8 6_64-pc-linux-gnu, compiled by gcc (Ubuntu 10.5.0-1ubuntu1~22.04) 10.5.0, 64-bit compiled on …

В кластеры с помощью PXF (Platform Extension Framework) была загружена БД «Авиаперевозки»:

https://postgrespro.ru/education/demodb

Характеристики базы данных: 8 таблиц, общий объем 1.5 Gb и 22 млн строк.

Таблицы в кластерах были распределены (distributed by) по первичным ключам.

В кластерах были выполнены запросы двух видов:

  1. соединения таблиц,

  2. запросы из курса «QPT. Оптимизация запросов» фирмы «PostgresPro»:

    https://postgrespro.ru/education/courses/QPT

Замеры времени выполнения запросов выполнялись с помощью команды explain analyze. Для исключения влияния кеширования данных на замеры времени каждый замер выполнялся 3 раза и считалось среднее время.

Анализ производительности соединений

Сначала были выполнены запросы, для которых в первую очередь предназначены MPP-кластеры, - соединения таблиц. Запросы были подобраны максимально разнообразные:

  • соединения больших и маленьких таблиц,

  • соединения разного количества таблиц,

  • запросы с операциями Redistribute Motion в планах выполнения и без них,

  • запросы с использованием spill-файлов и без использования этих файлов.

Различия в производительности этих запросов на кластерах Arenadata 6 или Cloudberry оказались минимальными. Это можно объяснить тем, что оба MPP-кластера недалеко ушли от своего общего предка – «ванильного» Greenplum-а.

Выполнение запросов из курса «Оптимизация запросов»

В серии экспериментов по курсу оптимизации были обнаружены запросы, время выполнения которых на кластере Cloudberry было заметно меньше, чем на Arenadata 6:

Таблица 1. Запросы с различными временами выполнения на кластерах (мс)

Запрос

Arenadata DB 6.27

Cloudberry Database 1.6

Поиск по диапазону

201

81

Агрегирование 1

287

169

Агрегирование 2

198

97

Агрегирование 3

206

56

Агрегирование 4

165

85

Антисоединение

9

5

 
-- Поиск по диапазону
explain analyze select * from bookings where book_ref > '000900' and book_ref < '000939';

-- Агрегирование 1
explain analyze select count(*) from bookings;

-- Агрегирование 2
explain analyze select sum(total_amount) from bookings where book_ref < '400000';

-- Агрегирование 3
explain analyze select count(book_ref) from bookings where book_ref <= '400000';

-- Агрегирование 4
explain analyze select count(*) from bookings where total_amount < 20000 and book_date::timestamp with time zone > '2017-07-15 18:00:00+03'::timestamp;

-- Антисоединение
explain analyze select * from aircrafts a where a.model like 'аэробус%' 
  and not exists (select * from seats s where s.aircraft_code = a.aircraft_code);

Выводы

  1. Эксперименты показали, что версия PostgreSQL, лежащего в основе MPP-кластера, не оказывает существенного влияния на производительность соединений таблиц. Arenadata DB 6.27 с ядром PostgreSQL 9.4 и Cloudberry Database 1.6 с ядром PostgreSQL 14.4 показали приблизительно одинаковые времена выполнения этого типа запросов.

  2. Выявлено несколько типов запросов, которые в Cloudberry Database 1.6 выполняются эффективнее, чем в Arenadata DB 6.27: поиск по диапазону, агрегирование, антисоединение.

  3. Количество разнообразных MPP-кластеров постоянно растет: Arenadata DB, Cloudberry Database, Yandex.Cloud Greenplum, Greengage... Встает непростая задача выбора кластеров для конкретных проектов. Анализ производительности – одна из составляющих выбора. Поэтому важно совершенствовать методику анализа производительности запросов MPP-кластеров.

Комментарии (13)


  1. ostinru
    13.02.2025 08:56
    #27916438

    Еще можно посмотреть на бенчмарки от ClickHouse - там производительность получается плюс-минус одинаковая. Правда, там запросы без суровых join-ов - чисто на фильтрацию и аггрегацию.
    https://benchmark.clickhouse.com/


    1. ibshcherbakov Автор
      13.02.2025 08:56
      #27916676

      Интересные бенчмарки. Ценно то, что можно сравнить много разных систем.
      К сожалению, данные по Cloudberry и Greenplum уже устарели. По Cloudberry данные от 06.06.2024, тогда еще не было версии 1.6, была 1.5. По Greenplum данные от 18.08.2023, видимо, это старая "ванильная" версия.


  1. KlimenkoIv
    13.02.2025 08:56
    #27917638

    Добрый день. В чем смысл тестирования MPP системы на одной ноде?
    Какие типы таблиц вы применяли? Какое сжатие было применено? Приведите, пожалуйста, DDL таблиц и сами запросы. Мне кажется, что тестировать MPP на одной ноде, без дистрибуции и решения именно аналитической задачи - то, что реализует DWH, не корректно.
    База данных "Авиаперевозки" является БД, упорядоченной по 3НФ. Основной плюс MPP это работа с суррогатными ключами через распределение на ноды, на которые можно вынести запросы аггрегации и трансформации данных без необходимости передавать их на другие узы. То есть, под такие MPP СУБД предназначен Data Valut, с его принципами и возможностями.


    1. ibshcherbakov Автор
      13.02.2025 08:56
      #27918120

      Добрый день. Сначала отвечу на те вопросы, на которые можно ответить быстро.

      Дистрибуция применялась. В статье я это упомянул. Таблицы были распределены (distributed by) по первичным ключам. Это обеспечило равномерное распределение данных по сегментам. Тип таблиц - appendoptimized. Таблицы с большим количеством столбцов имели колоночную ориентацию (например, таблица flights, но она не упомянута в статье). Приведу полный DDL тех таблиц, которые упомянуты в статье:

      create table bookings.bookings(                       
	book_ref     bpchar(6),     -- Booking number
	book_date    text,          -- Booking date
	total_amount numeric(10, 2) -- Total booking cost
	)
	with (appendoptimized = true)
    distributed by (book_ref);

create table bookings.aircrafts_data(                 
	aircraft_code bpchar(3), -- Aircraft code, IATA
	model         jsonb,     -- Aircraft model
	"range"       int4       -- Maximal flying distance, km
	)
	with (appendoptimized = true)
    distributed replicated;

create table bookings.seats(                          
	aircraft_code   bpchar(3),   -- Aircraft code, IATA
	seat_no         varchar(4),  -- Seat number
	fare_conditions varchar(10)  -- Travel class
	)
	with (appendoptimized = true)
    distributed by (aircraft_code, seat_no);

      Запросы, которые различались временем выполнения на кластерах, приведены в статье.

      Сжатие не применялось, так как объем данных был не очень большой. Было бы интересно сделать замеры по таблицам со сжатием. Планирую получить такие данные в следующей серии экспериментов.


    1. ibshcherbakov Автор
      13.02.2025 08:56
      #27918224

      Про DataVault. Сошлюсь на:
      https://habr.com/ru/articles/348188/

      Этот подход имеет недостатки.


  1. RekGRpth
    13.02.2025 08:56
    #27918092

    Логичнее было бы сравнивать с Arenadata DB 7.2, где уже PostgreSQL 12


    1. ibshcherbakov Автор
      13.02.2025 08:56
      #27918128

      Сравнение с Arenadata DB 6 было заказано руководством, кроме того мне было интересно понять, насколько сильно версия PostgreSQL влияет на производительность запросов. Поэтому я сравнил актуальные кластеры, максимально отличающиеся версией PostgreSQL.


  1. EvgenyVilkov
    13.02.2025 08:56
    #27923180

    Где вы видели МПП систему в которой запросы по очереди запускают?

    Где вы видели МПП систему в которой только селект?

    Где вы видели МПП систему в которой только dml операции?


    1. ibshcherbakov Автор
      13.02.2025 08:56
      #27923940

      Описанная часть тестов ни в коем случае не претендует на полноту.


  1. Mapar
    13.02.2025 08:56
    #27923234

    Вот серьезно?

    Взяли 2 карьерных самосвала, погрузили в каждый по 1 бутылке пива и протестировали скорость на 100 метрах.

    Что Вы по факту проверили? Объемы данных даже при той слабой конфигурации должны полностью поместится в кэше?! MPP не тестировали. Сеть не нагружали. По факту проверили время разбора запросов... Или эффективность использования памяти на конфигурациях ниже рекомендуемых.

    Я молчу, что если ставили как написано в предыдущей статье автора отключили зеркалирование.

    Конфигурации машин как минимум для ADB ниже минимальных системных требований. Нет никаких гарантий, что банально не ушло в своп.

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

    Есть же стандартные тесты, тот же TPC-DS ну так погоняйте его на 1-2 Тб. И на конфигурациях одобренных разработчиком.

    А вот этот текст просто поднять рейтинг на хабре, не более того.


    1. ibshcherbakov Автор
      13.02.2025 08:56
      #27923914

      Спасибо за рекомендации!
      Мне для работы, а руководителю для принятия решения нужно иметь бенчмарки по большому числу MPP-кластеров (список см. ниже). В свободном доступе данных почти нет. На работе серверы для проверки производительности пока не выделяют. Приходится крутиться, чтобы получить хоть что-то. И многие находятся в такой же ситуации.

      Какой рейтинг за статью? Сплошные минусы и критика. И это было ожидаемо, потому что тема для многих больная.

      - «Ванильный» Greenplum - версии перед закрытием проекта,

      - Yandex.Cloud,

      - Arenadata - версии 6.23, 6.25, 6.27, 7.2, community/enterprise,

      - Cloudberry – версии 1.5 и 1.6,

      - Greengage – текущая версия,

      - Citus – версии 12 и 13.


      1. Mapar
        13.02.2025 08:56
        #27924004

        Ну вот я и спрашиваю, а что дают такие измерения? Без нормального оборудования, без объемов.

        Какое решение может на таких измерениях принять руководитель? Какие сведенья Вы из этого получите для работы? Ну получили Вы разницу в 100 мс (да даже в 1000 мс), при оборудовании ниже системных требований, на объемах для калькулятора, что это дало? Оно не описывает поведение системы на реальных объемах от слова совсем.

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

        Ну и странный смысл сравнения, вот взяли Вы, как пишите, «Ванильный» Greenplum, Greengage, Greenplum в Yandex Cloud, Arenadata - версии 6.23, 6.25, 6.27 (community/enterprise). Там же разница, не в миллисекундах, а в фичах и исправленных багах, ну и в сервисе. Сравнивать коммерческие дистрибутивы (и PaaS Yandex) и комьюнити опять же надо по фичам.


        1. ibshcherbakov Автор
          13.02.2025 08:56
          #27924026

          Еще раз спасибо! Ваши комментарии передал руководителю, они ускорят получение нормального оборудования для полноценного тестирования производительности.

          Только опубликовать результаты этого тестирования мне, скорее всего, не разрешат.