Greenplum без отставания от PostgreSQL

Эксперимент показал, как превратить MPP-движок Greenplum в набор расширений поверх PostgreSQL 19. Цель — получить распределённую аналитику на актуальной версии ядра без многомесячных слияний форка. Это важно для команд, которым нужны последние возможности SQL, свежие расширения и простой переезд на новые мажорные релизы. MPP здесь означает massively parallel processing, то есть архитектуру, где запросы выполняются одновременно на многих узлах, что ускоряет обработку больших объёмов данных. Такой подход позволяет аналитикам работать с терабайтами информации без ручного разделения задач.

Почему форки Greenplum отстают от апстрима

Greenplum и его продолжение Apache Cloudberry остаются полноценными форками. На каждую новую версию PostgreSQL уходит много времени: в репозитории Greenplum накопилось почти полторы тысячи правок ядра плюс отдельный оптимизатор ORCA. ORCA — это cost-based optimizer, который строит планы запросов с учётом распределения данных и стоимости пересылок между узлами. Пока разработчики завершают слияние, PostgreSQL уходит вперёд ещё на один релиз. В результате пользователи получают версию ядра, которая уже устарела на два-три года, и не могут сразу подключить актуальные PostGIS или pgvector.

Эксперимент пошёл обратным путём. Вместо того чтобы вливать исходники PostgreSQL в Cloudberry, автор добавил в PostgreSQL 19 всего 22 точки расширения. На их основе Cloudberry превратился в набор модулей, которые загружаются в обычный сервер. При этом сервер без загруженных расширений остаётся неотличимым от ванильного PostgreSQL 19 как по поведению, так и по производительности. Это важно при выборе решения: минимальное вмешательство в ядро снижает риск конфликтов при обновлениях и упрощает аудит безопасности.

Что именно удалось перенести

За 12 дней и 629 коммитов с помощью Claude Code удалось портировать более 90 % кода Cloudberry. 59 % тестов оригинального проекта теперь проходят на новой архитектуре. Планы запросов режутся на слайсы, данные пересылаются между сегментами, транзакции используют распределённые снимки и двухфазную фиксацию. Это не FDW, который тянет все данные на координатор, а именно MPP-выполнение. FDW — foreign data wrapper, механизм для доступа к внешним источникам, но он не обеспечивает истинного параллелизма, потому что собирает всё на одном узле и создаёт узкое место.

Главное ограничение — пока это личный эксперимент, а не официальный релиз Apache Cloudberry. PostgreSQL 19 находится в стадии бета-версии, поэтому стабильность и производительность в промышленной нагрузке ещё предстоит проверить. Тем не менее, количество изменений в ядре минимально, и это даёт шанс быстро обновляться вместе с апстримом. Для команд, решающих брать ли решение, важно, что производительность остаётся на уровне оригинала, а поддержка новых расширений становится доступной сразу после выхода апстрима.

Как это работает в российском контуре

В России многие компании до сих пор держат Greenplum 6 и 7 на базе PostgreSQL 12 и старше. Переход на новую мажорную версию требует либо долгого слияния патчей, либо отказа от части расширений. Расширение под PostgreSQL 19 решает эту проблему напрямую: можно оставить текущие скрипты и инструменты, а на узлах сразу подключить свежие версии PostGIS 3.7 и pgvector 0.8.8 без пересборки. PostGIS отвечает за работу с геоданными, а pgvector — за векторный поиск, который востребован в задачах машинного обучения и рекомендаций.

Для команд, которые уже используют Cloudberry или рассматривают его как альтернативу Citus, появляется понятный путь миграции. Достаточно перевести 22 небольших патча на 1,5 тысячи строк вместо того, чтобы месяцами интегрировать весь форк. Это снижает риски при обновлении и позволяет быстрее получать исправления безопасности и новые возможности планировщика из апстрима. При принятии решения стоит учитывать, что такой подход уменьшает время простоя и упрощает compliance с требованиями к актуальным версиям СУБД.

Ограничения и следующие шаги

Эксперимент не даёт готового продукта. Нужно проверить поведение под реальной смешанной нагрузкой, устойчивость распределённых транзакций и совместимость с популярными российскими сборками PostgreSQL. Также предстоит оценить overhead от новых точек расширения при высоком параллелизме. Overhead здесь — это дополнительные затраты ресурсов на пересылку данных и синхронизацию, которые могут повлиять на latency в OLTP-сценариях.

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

Источник

Это краткий разбор материала Habr. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: Greenplum без отставания от PostgreSQL.

Курс по теме — Каталог курсов Школы Больших Данных