Нагрузочное тестирование GP6 vs GP7 vs Cloudberry
На связиМарк — ведущий архитектор группы компаний «ГлоуБайт». Мой коллега Евгений Вилков в своей статье Тестирование систем и движков массивно-параллельных вычислений. Часть II. TPC-DS анонсировал выход статьи по нагрузочному тестированию GreenPlum 6.X, GreenPlum 7.X и Cloudberry. Если не читали статью Евгения, рекомендую ознакомиться, в ней было краткое описание методики TPC-DS, про которую сегодня тоже пойдет речь. Тесты мы проводили параллельно, в своей статье Евгений как раз использовал результаты нашего тестирования Greenplum 6 на соответствующем для Data Ocean Nova сайзинге.
Историческая справка
В этом году GreenPlum отмечает 22 года. В конце сентября 2023 года состоялся релиз GreenPlum 7, спустя ровно 4 года после выхода GreenPlum 6. Между выходом GP5 и GP6 прошло 2 года. Заявлялось много новой интересной и полезной функциональности: как минимум повышение версии ядра с морально устаревшей Postgres 9.4 (2014 года рождения) до чуть менее устаревшей Postgres 12 (2019 года рождения). Многие ждали выход GreenPlum 7, ко мне до сих пор приходят коллеги и спрашивают: «А что там с GP7, собираете, когда ставить можно будет?»
Если смотреть на историю GP6, то стабилизация после релиза заняла примерно год. Активно выходили новые минорные версии, исправлялись баги. Некоторые компании только недавно мигрировали на GP6, кто-то даже до сих пор живет на GP5. Примерно такой же сценарий мы видели и для GP7, но в мае 2024 года репозиторий в GitHub был заархивирован, и дальнейшая разработка пошла в закрытом формате. Последняя открытая версия была 7.2. Именно она лежит сейчас в основе форков на российском рынке.
При этом Broadcom продолжает развивать технологию без OSS-сообщества. Актуальная версия на момент написания статьи — 7.5.2. Есть и интересные фичи, направленные на оптимизацию, управление ресурсами и исправление багов.
В этом году GreenPlum отмечает 22 года. В конце сентября 2023 года состоялся релиз GreenPlum 7, спустя ровно 4 года после выхода GreenPlum 6. Между выходом GP5 и GP6 прошло 2 года. Заявлялось много новой интересной и полезной функциональности: как минимум повышение версии ядра с морально устаревшей Postgres 9.4 (2014 года рождения) до чуть менее устаревшей Postgres 12 (2019 года рождения). Многие ждали выход GreenPlum 7, ко мне до сих пор приходят коллеги и спрашивают: «А что там с GP7, собираете, когда ставить можно будет?»
Если смотреть на историю GP6, то стабилизация после релиза заняла примерно год. Активно выходили новые минорные версии, исправлялись баги. Некоторые компании только недавно мигрировали на GP6, кто-то даже до сих пор живет на GP5. Примерно такой же сценарий мы видели и для GP7, но в мае 2024 года репозиторий в GitHub был заархивирован, и дальнейшая разработка пошла в закрытом формате. Последняя открытая версия была 7.2. Именно она лежит сейчас в основе форков на российском рынке.
При этом Broadcom продолжает развивать технологию без OSS-сообщества. Актуальная версия на момент написания статьи — 7.5.2. Есть и интересные фичи, направленные на оптимизацию, управление ресурсами и исправление багов.
Примеры фичей:
Примерно в то же время в информационном поле стали появляться китайские “убийцы” Greenplum. Один из них – Cloudberry, результат “скрещивания” GP7 и Postgres 14. Cloudberry привлек к себе внимание, когда на ряде конференций (например, тут) Яндекс объявил, что решил контрибьютить в него.
Если сравнивать репозитории, то можно заметить, что развитие Open Source Greenplum 7 остановилось не начавшись, а в Cloudberry что-то даже происходит.
Сегодня мы хотим ответить на следующие вопросы:
- Оптимизация ANALYZE (7.5.0): Пропуск статистических вычислений, если таблица не изменялась с последнего сбора статистики (новый параметр gp_analyze_only_modified_relations).
- Улучшения GPORCA:
- Поддержка REFRESH для материализованных представлений (7.5.0);
- Оптимизация SIRV (Subquery Inlining for Row Expressions) (7.5.0, 7.4.0);
- Поддержка Row Expressions (7.4.0);
- Улучшенное управление памятью для метаданных (7.4.0).
- Улучшения Direct dispatch для DML операций с явным указанием id сегмента (7.4.0).
- Раннее освобождение ресурсов (7.4.0): Параметр gp_resgroup_enable_early_unassign. Ресурсы будут высвобождать после исполнения отдельного запроса, не дожидаясь завершения всей сессии.
- Добавлены новые утилиты:
- gpcheck (7.5.0): Новая утилита для диагностики кластера (начальная версия включает проверку сети MTU);
- gpmigrate (7.4.0): Утилита проверки совместимости между Greenplum 6 и 7;
- gpctl и gpservice (7.4.0): Новые утилиты для управления кластером на основе gRPC;
- Улучшения vacuumdb (7.5.0).
- Большое количество критических исправлений в части стабильности, надежности и производительности.
Примерно в то же время в информационном поле стали появляться китайские “убийцы” Greenplum. Один из них – Cloudberry, результат “скрещивания” GP7 и Postgres 14. Cloudberry привлек к себе внимание, когда на ряде конференций (например, тут) Яндекс объявил, что решил контрибьютить в него.
Если сравнивать репозитории, то можно заметить, что развитие Open Source Greenplum 7 остановилось не начавшись, а в Cloudberry что-то даже происходит.
Сегодня мы хотим ответить на следующие вопросы:
- Насколько лучше производительность в GP7 и Cloudberry относительно GP6?
- Насколько стабильно работают GP7 и Cloudberry?
- А стоит ли мигрировать с GP6 в 2025? И если да, то на что?
Подготовка к тестированию
Стенд тестирования: ВМ в Яндекс Cloud следующего сайзинга:
Стенд тестирования: ВМ в Яндекс Cloud следующего сайзинга:
Наши подопытные:
Тесты, которые проводились:
Тестирование проводилось на одинаковых настройках ОС, за исключением использования cgroups v1 и cgroups v2.
Базовые настройки кластера также совпадают для всех дистрибутивов:
Дополнительные настройки кластера для оптимизации делались в рамках тестов и будут указаны ниже в деталях тестирования.
Настройки ресурсных групп выставлялись одинаковые, с поправкой на изменившийся формат конфигурации, за исключением ситуаций, когда тесты падали по памяти. В таком случае выставлялось значение concurrency, при котором тест отрабатывал без ошибок.
Тесты проводили на 4 и 8 сегментах на сегмент-хост. По итогу выбрали конфигурацию с 8 сегментами, так как на ней результаты оказались лучше у всех участников забега.
Методика НТ MPP-движков
Методика была разработана нашим клиентом совместно с одним из вендоров лет 8 назад и хорошо себя зарекомендовала для use case сценариев проверки решения задач аналитического хранилища данных. Методика, адаптированная под Greenplum, выложена в нашем открытом репозитории: https://git.angara.cloud/gbgreenplum/greenplum.playbook.loadtest
В процессе тестирования моделируются данные и процессы, которые являются типовыми в задачах ETL-вычислений, ad-hoc запросов и, самое главное, в режиме высококонкурентного пользовательского доступа.
Тестирование платформ проводится на одинаковом наборе синтетических данных.
Приблизительный объем несжатых тестовых данных составляет 8 ТБ (терабайт).
Допускается применение любых особенностей платформы для оптимизации тестовых запросов кроме:
- Open Source GreenPlum 6.27.1 – последняя open source версия GP6;
- Open Source GreenPlum 7.2;
- CloudBerry 1.6.0.
Тесты, которые проводились:
- Тестирование по методике НТ MPP-движков.
- Тестирование по методике TPC DS.
Тестирование проводилось на одинаковых настройках ОС, за исключением использования cgroups v1 и cgroups v2.
Базовые настройки кластера также совпадают для всех дистрибутивов:
- max_connections=400
- max_prepared_transactions=400
- gp_resource_group_memory_limit=0.9
Дополнительные настройки кластера для оптимизации делались в рамках тестов и будут указаны ниже в деталях тестирования.
Настройки ресурсных групп выставлялись одинаковые, с поправкой на изменившийся формат конфигурации, за исключением ситуаций, когда тесты падали по памяти. В таком случае выставлялось значение concurrency, при котором тест отрабатывал без ошибок.
Тесты проводили на 4 и 8 сегментах на сегмент-хост. По итогу выбрали конфигурацию с 8 сегментами, так как на ней результаты оказались лучше у всех участников забега.
Методика НТ MPP-движков
Методика была разработана нашим клиентом совместно с одним из вендоров лет 8 назад и хорошо себя зарекомендовала для use case сценариев проверки решения задач аналитического хранилища данных. Методика, адаптированная под Greenplum, выложена в нашем открытом репозитории: https://git.angara.cloud/gbgreenplum/greenplum.playbook.loadtest
В процессе тестирования моделируются данные и процессы, которые являются типовыми в задачах ETL-вычислений, ad-hoc запросов и, самое главное, в режиме высококонкурентного пользовательского доступа.
Тестирование платформ проводится на одинаковом наборе синтетических данных.
Приблизительный объем несжатых тестовых данных составляет 8 ТБ (терабайт).
Допускается применение любых особенностей платформы для оптимизации тестовых запросов кроме:
- Принудительного размещения объектов в памяти;
- Материализации результатов тестовых запросов в виде заранее созданных аналитических проекций, join-индексов, материализованных представлений.
Методика включает в себя следующий набор тестов:
Методика TPC DS
Информация о методике: https://www.tpc.org/tpcds/.
Если кратко:
3. Запускаются 99 запросов в single user режиме, каждый запрос запускается последовательно. Фиксируется длительность выполнения каждого запроса и длительность выполнения теста.
4. Запускаются эти же 99 запросов только в multi user режиме. Для тестов Greenplum 6/Greenplum 7/Cloudberry мы выбрали 5 одновременных подключений. Для сравнения с Data Ocean Nova повторяли тест в 4 одновременных подключениях на увеличенном, соответствующем тестам Data Ocean Nova, сайзинге (сайзинг указан в статье). Фиксируется длительность каждого запроса, длительность всего теста и сумма времени по всем запросам.
Методика TPC DS
Информация о методике: https://www.tpc.org/tpcds/.
Если кратко:
- При запуске теста задается scale factor, который влияет на количество данных. В нашем случае мы делали два теста:
- scale factor 1000 – 1ТБ RAW CSV (объем данных в GP AOCO со сжатием ZSTD 3 ~400 ГБ);
- scale factor 10000 – 10ТБ RAW CSV (объем данных в GP AOCO со сжатием ZSTD 3 ~4 ТБ).
3. Запускаются 99 запросов в single user режиме, каждый запрос запускается последовательно. Фиксируется длительность выполнения каждого запроса и длительность выполнения теста.
4. Запускаются эти же 99 запросов только в multi user режиме. Для тестов Greenplum 6/Greenplum 7/Cloudberry мы выбрали 5 одновременных подключений. Для сравнения с Data Ocean Nova повторяли тест в 4 одновременных подключениях на увеличенном, соответствующем тестам Data Ocean Nova, сайзинге (сайзинг указан в статье). Фиксируется длительность каждого запроса, длительность всего теста и сумма времени по всем запросам.
Результаты тестирования
Для тех, кто шел посмотреть чисто на циферки, сразу итоговый результат.
Ниже будут детали по тестированию GP7 и CBDB и выводы, которые мы для себя сделали.
В итоги тестирования брали лучшие результаты по каждому тесту.
Настройки РГ для GP6 (по сути одинаковые, но разные по формату конфигов):
Для тех, кто шел посмотреть чисто на циферки, сразу итоговый результат.
Ниже будут детали по тестированию GP7 и CBDB и выводы, которые мы для себя сделали.
В итоги тестирования брали лучшие результаты по каждому тесту.
Настройки РГ для GP6 (по сути одинаковые, но разные по формату конфигов):
Настройки РГ для GP7 и Cloudberry:
Результаты:
Таблица. Сравнение результатов тестирования по методике НТ MPP-движков для GP6, GP7 и CBDB
Диаграмма. Сравнение GP6, GP7 и CBDB. Чем меньше, тем лучше
Диаграмма. Сравнение конкурентной нагрузки и построения витрины на GP6, GP7 и CBDB. Чем меньше, тем лучше
Объемы синтетических данных (при одинаковом количестве строк в таблицах):
Время генерации данных:
Результаты tpc-ds:
Таблица. Сравнение результатов tpc-ds для GP6, GP7 и CBDB
Диаграмма. Сравнение результатов tpc-ds для GP6, GP7 и CBDB. Чем меньше, тем лучше
Что видим из тестов:
- В большинстве тестов все дистрибутивы показывают схожие результаты.
- Cloudberry очень плохо показывает себя на группировках и сортировках (группы запросов 1, 2, 3 и 4).
- За счет оптимизаций витрина на Cloudberry считается намного быстрее (последний тест – запрос построения витрины).
- Cloudberry эффективнее хранит данные. В GP7 тоже есть улучшения по оптимальности хранения относительно GP6.
- В tpc-ds GP7 проявил себя лучше, но прирост производительности незначительный.
- При этом есть вопросы по стабильности работы Cloudberry и GP7. Для GP7 пришлось повторять тест, так как половина тестов упала из-за проблем с интерконнектом. Но проблемы плавающие, при повторном тесте только один запрос упал с ошибкой. Аналогичные проблемы есть у Cloudberry.
Детали тестирования Greenplum 7
Тестирование проводилось в конфигурации: 8 сегментов на хост.
В рамках тестирования проводилось 2 итерации:
Но при использовании cgroups v1 игнорируется настройка ограничения на IO.
Также при переключении ресурсных групп меняются внутренние механизмы выделения и распределения ресурсов между процессами.
В наших тестах мы не упирались в диски, поэтому ограничение на IO не выставляли.
Настройки ресурсных групп одинаковые для всех тестов:
Тестирование проводилось в конфигурации: 8 сегментов на хост.
В рамках тестирования проводилось 2 итерации:
- С использованием cgroups v1.
- С использованием cgroups v2.
Но при использовании cgroups v1 игнорируется настройка ограничения на IO.
Также при переключении ресурсных групп меняются внутренние механизмы выделения и распределения ресурсов между процессами.
В наших тестах мы не упирались в диски, поэтому ограничение на IO не выставляли.
Настройки ресурсных групп одинаковые для всех тестов:
Результаты:
Таблица. Сравнение результатов GP7 на разных версиях cgroups
Из результатов видно, что при использовании cgroups v1 результаты получаются лучше. При этом cgroups v2 дают более тонкую настройку и могут давать эффект в инсталляциях с сильно нагруженными дисками.
Одна из самых интересных фичей в GP7 – BRIN Index.
Эту фичу мы сначала очень ждали в GP6. Потом очень ждали GP7, чтобы протестировать, что же в итоге получилось. Проверяли его на самой большой таблице transaction (21 млрд записей, 835 GB).
Размер индекса – 9 ГБ.
Одно из самых больших разочарований в GP7 – BRIN Index.
Он не сработал на таком объеме данных. При этом он срабатывает для данного запроса, если в таблице transaction мало данных (в public была создана таблица transaction с тем же ddl, вставлено небольшое количество записей из оригинальной таблицы, создан BRIN Index, произведен analyze). При том что BRIN можно создать над AO таблицей и занимает он не так много места, как, например, уникальный индекс, его все еще нужно обслуживать и его обновление занимает время. По итогу минусов все равно больше, чем плюсов.
Прочитать статью полностью можно тут.
Одна из самых интересных фичей в GP7 – BRIN Index.
Эту фичу мы сначала очень ждали в GP6. Потом очень ждали GP7, чтобы протестировать, что же в итоге получилось. Проверяли его на самой большой таблице transaction (21 млрд записей, 835 GB).
Размер индекса – 9 ГБ.
Одно из самых больших разочарований в GP7 – BRIN Index.
Он не сработал на таком объеме данных. При этом он срабатывает для данного запроса, если в таблице transaction мало данных (в public была создана таблица transaction с тем же ddl, вставлено небольшое количество записей из оригинальной таблицы, создан BRIN Index, произведен analyze). При том что BRIN можно создать над AO таблицей и занимает он не так много места, как, например, уникальный индекс, его все еще нужно обслуживать и его обновление занимает время. По итогу минусов все равно больше, чем плюсов.
Прочитать статью полностью можно тут.