PostgreSQL и Greenplum: инженерная база для EDWH

Почему это разные инженерные контексты#

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

Правило: нельзя переносить выводы о производительности из небольшой PostgreSQL-таблицы или SQLite-прототипа на промышленный MPP-кластер без новых измерений.

PostgreSQL: базовые аспекты#

План выполнения: EXPLAIN показывает план, EXPLAIN ANALYZE исполняет запрос и возвращает фактические характеристики.
Статистика: оценки кардинальности влияют на выбор алгоритма соединения и стоимость плана.
Индексы и доступ: нужны для конкретных фильтров, соединений и упорядочивания; избыток индексов тоже имеет стоимость.
Партиционирование: может помогать ограничивать объём данных при правильных условиях отбора.
MVCC и транзакции: требуют понимания снимков, длительных операций и обслуживания таблиц.

Greenplum: MPP-специфика#

Основные темы изучения:

Сегменты и распределение строк по узлам.
Hash-distribution, random distribution, replicated distribution (доступность зависит от версии).
Skew - неравномерная нагрузка или объём данных по сегментам.
Локальные соединения и операции, требующие перемещения данных.
Партиционирование отдельно от физического распределения по сегментам.
План выполнения и зависимость от статистики.

Тип распределения нужно выбирать с учётом гранулярности и ожидаемых соединений. Например, распределение по почти постоянному признаку может создать выраженный skew; распределение по одному уникальному полю не всегда будет лучшим для всех аналитических соединений.

Финансовый пример#

Есть большой журнал проводок. Требуется рассчитывать обороты по счёту и валюте. Стоит оценить:

частоту соединения со справочниками счетов, документов, подразделений;
селективность дат и наличие партиционирования;
размеры отдельных сегментов, неравномерность ключей;
объём перемещений данных при агрегациях и соединениях;
сохранение точности денежных величин независимо от параллельного выполнения.

План оптимизации должен опираться на измеренные объёмы и реальные планы запросов, а не только на общие рекомендации.

Граница первой версии лаборатории#

Financial EDWH Lab сейчас работает на SQLite, не на PostgreSQL или Greenplum. Это решение сделано для запуска тестов без отдельного сервера БД. Темы MPP, EXPLAIN и распределения в данном разделе - справочные; лаборатория не подтверждает практическую оптимизацию Greenplum.

При переходе к PostgreSQL отдельным этапом нужны миграция схемы, тесты денежных типов, интеграционные тесты и сравнение планов.

Different engineering contexts#

PostgreSQL and Greenplum share a related SQL foundation, but Greenplum's distributed architecture changes operation costs. Physical placement across segments and inter-segment data movement can have a major impact on query execution.

Rule: do not transfer performance conclusions from a small PostgreSQL table or SQLite prototype to a production MPP cluster without new measurements.

PostgreSQL: fundamentals#

Execution plans: EXPLAIN displays a plan; EXPLAIN ANALYZE executes the query and reports actual behavior.
Statistics: cardinality estimates influence join strategy and plan cost.
Indexes and access: indexes should serve specific filters, joins, and ordering; too many indexes also have a cost.
Partitioning: can reduce scanned data when predicates allow partition pruning.
MVCC and transactions: require understanding snapshots, long-running operations, and table maintenance.

Greenplum: MPP considerations#

Key topics include:

Segments and row distribution across nodes.
Hash, random, and replicated distribution (availability depends on version).
Skew: uneven data volume or workload across segments.
Local joins and operations that require data movement.
Partitioning as a separate choice from segment distribution.
Execution plans and their dependence on statistics.

Choose distribution with grain and expected joins in mind. Distribution by a nearly constant attribute can create severe skew; distributing by a unique field is not necessarily best for every analytical join.

Financial example#

Suppose a large journal must provide turnover by account and currency. Evaluate:

Join frequency with account, document, and department reference data.
Date selectivity and partitioning.
Segment sizes and key skew.
Data movement caused by joins and aggregations.
Preservation of monetary precision under parallel execution.

Optimization should rely on measured volumes and real query plans, not general advice alone.

Boundary of the first lab version#

Financial EDWH Lab currently runs on SQLite, not PostgreSQL or Greenplum. This keeps tests runnable without a separate database server. MPP, EXPLAIN, and distribution topics here are reference material; the lab does not demonstrate practical Greenplum optimization.

A PostgreSQL transition needs a separate schema migration, monetary-type tests, integration tests, and plan comparisons.