Нагрузочное тестирование YMatrix: как ведёт себя новый форк GreenPlum под нагрузкой
Марк, ведущий архитектор группы компаний «ГлоуБайт»
---
В этот раз основной фокус смещён на YMatrix — относительно новый игрок на рынке MPP-СУБД, построенный на базе GreenPlum 7. Цель испытаний — понять, насколько результаты YMatrix сопоставимы с уже протестированными дистрибутивами GreenPlum 6, GreenPlum 7 и CloudBerry, и как новый форк чувствует себя в реальных нагрузочных сценариях.
Методика тестирования, общий подход к генерации данных и параметры стендов для GP6, GP7 и CloudBerry уже были отработаны ранее. В этой работе мы расширили матрицу за счёт YMatrix, чтобы оценить относительную производительность и поведение под одинаковыми нагрузками.
---
Что такое YMatrix и откуда он взялся
YMatrix — это активно развивающийся форк GreenPlum 7, появившийся в 2020 году в Пекине. Проект основали выходцы из R&D‑команды GreenPlum, поэтому в продукте чувствуется глубокое понимание исходного кода и типичных «болей» MPP-систем.
Несколько ключевых фактов о команде и продукте:
- В команду YMatrix входят 2 из 5 топ‑контрибьюторов GreenPlum — разработчиков, которые вносили изменения непосредственно в ядро системы и суммарно ответственны примерно за 20% R&D‑вклада в GreenPlum.
- Ядро команды — более 30 разработчиков, сосредоточенных на развитии базового функционала, оптимизации производительности и развитии архитектурных фич.
- С точки зрения кода YMatrix — не просто косметический форк, а серьёзно доработанная ветка GreenPlum 7 с рядом архитектурных изменений и новых возможностей.
Основные особенности YMatrix, которые важны именно в контексте производительности и нагрузочного тестирования:
MARS3 — гибридный формат хранения на базе LSM Tree
MARS3 представляет собой гибридный колоночно-строчный формат хранения, реализованный поверх структуры LSM Tree (Log-Structured Merge Tree). Ключевые моменты:
- данные могут храниться в отсортированном виде по выбранным полям;
- это даёт заметный выигрыш при запросах с Nested Loop Join и фильтрацией по ключам сортировки;
- гибридный характер формата позволяет одновременно выигрывать и в аналитических, и в условно-операционных сценариях.
Domino — потоковая репликация
Domino отвечает за потоковую репликацию данных между узлами и кластерами, обеспечивая высокую доступность:
- минимизация времени простоя при отказах;
- возможность построения отказоустойчивых конфигураций без сложных самостоятельных сценариев репликации;
- важный элемент для продакшн‑кластеров с жёсткими SLA.
MXShift — инструмент миграции
MXShift предназначен для миграции данных в кластер YMatrix:
- поддерживает полную, инкрементальную и условную миграцию;
- умеет переносить данные из кластеров GreenPlum/YMatrix в новый кластер YMatrix;
- снижает входной порог для перехода с других форков GreenPlum, так как избавляет от необходимости писать собственные скрипты миграции.
MXVector — векторизованные вычисления
MXVector переводит исполнение запросов на векторизованную модель:
- операции обрабатывают не отдельные строки, а пачки данных (вектора), что снижает накладные расходы;
- при больших объёмах данных это даёт существенный прирост скорости выполнения запросов, особенно в аналитике и отчётной нагрузке;
- векторизация особенно актуальна совместно с колоночным или гибридным хранением.
YMatrix Cloudedition — разделение хранения и вычислений
Cloudedition-версия YMatrix опирается на разделение слоёв хранения и вычислений:
- бинарные данные могут храниться во внешнем объектном хранилище;
- вычислительные ресурсы масштабируются независимо от хранилища;
- такой подход хорош для облачных сценариев с эластичными нагрузками и большими объёмами данных.
---
Участники тестирования
Для сравнения были взяты следующие системы:
- Open Source GreenPlum 6.27.1 — последняя доступная open source‑версия GP6;
- Open Source GreenPlum 7.2;
- CloudBerry 1.6.0;
- YMatrix 6.6.
Все дистрибутивы тестировались по одинаковой методике, с максимально унифицированными настройками и идентичными объёмами синтетических данных, чтобы сохранить сопоставимость результатов.
---
Набор тестов
Использовались два типа нагрузочных испытаний:
1. Методика НТ MPP‑движков
Набор запросов и сценариев, заточенный под проверку поведения MPP‑кластера под типичными аналитическими и смешанными нагрузками.
2. Методика TPC‑DS
Классический индустриальный бенчмарк для DWH‑нагрузок, включающий сложные аналитические запросы, множество джойнов, подзапросов и нетривиальные паттерны доступа к данным.
---
Общие настройки и окружение
Чтобы результаты можно было сравнивать «на одном экране», все дистрибутивы запускались с максимально одинаковой конфигурацией.
ОС и cgroups
Операционная система и базовые параметры окружения были выровнены. Единственное существенное отличие — использование cgroups v1 и cgroups v2 в зависимости от требований конкретного дистрибутива. Это обусловлено совместимостью и особенностями реализации ресурсных групп в разных ветках.
Базовые параметры кластера
Для всех систем выставлялись одинаковые значения ключевых параметров:
- `max_connections = 400`
- `max_prepared_transactions = 400`
- `gp_resource_group_memory_limit = 0.9`
Таким образом, все движки получали доступ к примерно одинаковому пулу ресурсов, и различия в результатах можно интерпретировать как следствие внутренних архитектур и оптимизаций.
Ресурсные группы
Настройки ресурсных групп (Resource Groups) старались держать максимально единообразными между системами, с учётом разных форматов конфигурации:
- лимиты по CPU и памяти задавались одинаково для всех движков;
- если отдельные тесты «падали» по памяти, параметр `concurrency` снижался до минимального значения, при котором прогон проходил без ошибок;
- такой подход позволяет сохранить баланс между стабильностью теста и реалистичностью нагрузки.
Для YMatrix были использованы следующие настройки ресурсной группы:
- `concurrency = 10`
- `cpu_max_percent = 100`
- `cpu_weight = 500`
- `cpuset = -1` (без жёсткой привязки к конкретным ядрам)
- `memory_limit = 80`
- дополнительные параметры (min_cost, io_limit и т.п.) подбирались аналогично другим движкам.
---
Особенности конфигурации YMatrix
У YMatrix есть нюанс, который важно учитывать при сравнении:
- тестирование проводилось сразу на 8 сегментах на хост;
- такой выбор связан с необходимостью сопоставить результаты с другими форками GreenPlum и тем, как они обычно конфигурируются для MPP‑нагрузки;
- большее количество сегментов на узел повышает утилизацию ресурсов, но и усиливает требования к настройке планировщика и ресурсных групп.
---
Аппаратный стенд: методика НТ MPP‑движков
Для методики НТ MPP‑движков использовался кластер виртуальных машин в Яндекс Cloud следующего сайзинга:
Роли и параметры узлов:
- Master:
- Количество: 1
- vCPU: 8
- RAM: 64 ГБ
- SSD: 1,5 ТБ
- Segment:
- Количество: 4
- vCPU: 16
- RAM: 128 ГБ
- SSD: 2 ТБ × 4 на каждый хост
Такая конфигурация даёт достаточно ресурсов для имитации типичного промышленного DWH‑кластера в средней размерности и позволяет адекватно проверять масштабируемость и устойчивость под нагрузкой.
---
Аппаратный стенд: методика TPC‑DS
Для TPC‑DS использовался увеличенный сайзинг по сравнению со стендом НТ MPP‑движков. Это сделано для:
- сопоставимости с результатами других движков, протестированных в том же режиме;
- более честной оценки производительности в условиях сложных аналитических запросов;
- проверки масштабируемости при увеличении объёмов данных и числа конкурентных запросов.
Важный момент:
Все тесты по методике TPC‑DS запускались:
- на увеличенном стенде;
- в 4 одновременных конкурентных потока, чтобы нагрузка была ближе к реальным сценариям многопользовательской аналитики.
---
Генерация и объёмы данных
Синтетические данные генерировались по одной схеме для всех систем при одинаковом количестве строк в таблицах. Ниже — совокупные объёмы по основным таблицам (в ГБ):
| Таблица | GP6, GB | GP7, GB | CBDB, GB | YM, GB |
|---------------|---------|---------|----------|--------|
| Contractor | 1.5 | – | – | – |
| Account | 19 | 17 | – | – |
| Agreement | 9 | – | – | – |
| Document | 419 | 389 | 388 | – |
| Transaction | 866 | 835 | 687 | 845 |
| Transaction индексы | 7 | – | – | – |
| Сумма | 1315 | 1251.5 | 1109 | 1262 |
Из таблицы видно:
- общие объёмы данных у движков сопоставимы, что важно для корректного сравнения;
- у YMatrix итоговый объём близок к GP7, но немного отличается от CloudBerry из‑за особенностей форматов хранения и индексации.
---
Время генерации данных
Помимо объёмов, имеет смысл смотреть на время генерации данных, так как оно частично отражает эффективность работы с диском и организацию хранения:
| Система | Время генерации, сек |
|--------|------------------------|
| GP6 | 19800 |
| GP7 | 17600 |
| CBDB | 25200 |
| YM | 20150 |
Интерпретировать эти значения нужно аккуратно:
- GP7 показывает лучший результат по времени генерации из представленных систем;
- YMatrix по этому показателю немного уступает GP7, но опережает CloudBerry;
- разница с GP6 также заметна — YMatrix быстрее классической шестой версии, что логично для более современной архитектуры.
---
Форматы хранения YMatrix: AOCO против MARS3
В рамках нагрузочного тестирования YMatrix мы отдельно сравнивали два формата хранения:
- AOCO — классический колоночный формат, знакомый по GreenPlum;
- MARS3 — гибридный колоночно-строчный формат на базе LSM Tree.
Итоги сравнения форматов
Практические наблюдения:
- MARS3 показывает лучшие результаты там, где удаётся добиться использования Nested Loop Join:
- данные хранятся отсортированными по ключам соединения;
- это снижает стоимость поисков и джойнов;
- оптимизатор получает возможность строить планы, сильно выигрывающие по latency.
- В сценариях без выраженной выгоды от сортировки по ключам соединения разрыв между MARS3 и AOCO может быть менее заметным, но MARS3 всё равно остаётся конкурентоспособным форматом.
Иными словами, при проектировании схемы и ключей сортировки можно специально «подружить» модель данных с MARS3 и получить существенно более быстрые join‑операции и выборки.
---
Сравнение GP6, GP7, CloudBerry и YMatrix
Все результаты для GP6, GP7 и CloudBerry по методике НТ MPP‑движков были перенесены в этот обзор, чтобы можно было визуально и логически сравнивать системы между собой.
Ключевые замечания:
- YMatrix по ряду сценариев демонстрирует поведение, близкое к GP7, но с улучшениями за счёт:
- векторизованных вычислений (MXVector),
- формата MARS3,
- изменений в оптимизаторе и механизмах хранения.
- При этом на «сырая» производительность на чтение и вычислениях в отдельных кейсах может быть выше, чем у GP6, и не уступать CloudBerry при сопоставимых настройках.
- Важно учитывать, что YMatrix — относительно молодой продукт и находится в активной фазе развития, поэтому потенциал для дальнейшего роста производительности сохраняется.
---
Результаты TPC‑DS для YMatrix
Для YMatrix в рамках TPC‑DS были выполнены те же наборы запросов, что и для остальных движков, на:
- увеличенном сайзинге;
- с четырьмя конкурентными потоками.
Здесь особенно хорошо проявляются:
- преимущества векторизованного исполнения;
- эффективность работы MARS3 при правильно заданных ключах сортировки;
- способность кластера выдерживать одновременную аналитическую нагрузку без серьёзных деградаций по времени отклика.
Хотя конкретные цифры по каждому запросу зависят от нюансов настройки и схемы данных, общий вывод следующий:
- YMatrix уверенно вписывается в общий ряд форков GreenPlum;
- в ряде сценариев демонстрирует выигрыш за счёт более современных механизмов хранения и исполнения;
- в сложных аналитических запросах на больших объёмах данных система показывает себя конкурентоспособной.
---
Практические выводы и рекомендации
На основе проведённого тестирования YMatrix можно сделать несколько практических выводов для архитектора или DBA, подбирающего MPP‑движок под аналитический DWH:
1. Сопоставимость с «классическими» форками GreenPlum
YMatrix по своему характеру нагрузки и модели работы остаётся GreenPlum‑совместимой системой, но обладает заметным количеством улучшений.
2. Использование MARS3 там, где важны join‑операции
Если планируется большое количество джойнов по предсказуемым ключам, стоит:
- продумать ключи сортировки;
- использовать MARS3 на соответствующих таблицах;
- это даст выигрыш в сложных запросах и TPC‑DS‑подобных нагрузках.
3. Выигрыш от MXVector на больших объёмах
Векторизация даёт максимальный эффект в:
- тяжёлых аналитических запросах;
- отчётности по большим объёмам;
- регулярных массовых расчётах.
4. Облачные сценарии — зона применения Cloudedition
Если ключевые требования — эластичность, разделение хранения и вычислений, использование объектного хранилища, имеет смысл смотреть в сторону YMatrix Cloudedition.
5. Миграция с существующих кластеров GreenPlum/CBDB
Наличие MXShift облегчает переход с:
- существующих кластеров GreenPlum;
- уже работающих инсталляций YMatrix;
- минимизирует простои и риски при переносе.
6. Необходимость тщательной настройки ресурсных групп
Как и для любого MPP‑движка, важно уделить внимание:
- правильной конфигурации resource groups;
- выбору значений concurrency;
- управлению CPU и памятью для разных типов нагрузок (ETL, аналитика, отчёты).
---
Итог
YMatrix — это не просто ещё один форк GreenPlum, а продукт, в котором:
- сочетается опыт ключевых разработчиков исходного проекта;
- внедрены современные подходы к хранению (MARS3), вычислениям (MXVector) и репликации (Domino);
- реализована практичная экосистема миграции (MXShift) и облачного использования (Cloudedition).
С точки зрения нагрузочного тестирования YMatrix показывает результаты, сопоставимые с другими зрелыми форками, а в ряде сценариев — превосходящие их, особенно там, где можно осознанно задействовать гибридный формат хранения и векторное исполнение.
Для команд, которые уже знакомы с GreenPlum и ищут более современный и активно развиваемый вариант, YMatrix выглядит перспективным направлением для пилотных проектов и дальнейшего промышленного использования.
