Как стать автором
Обновить

Комментарии 5

При этом в проект активно переносятся возможности более новых версий PostgreSQL;

ИМХО, путь в некуда для проекта, но очень прибыльно для того, кто это делает :)

Люблю такие развёрнутые и подробные комментарии, спасибо.

Такой подход (портирование фич вместо постоянного rebase'а) имеет свои плюсы и минусы.

Надо понимать, что Greenplum имеет очень много концептуальных и архитектурных отличий от PostgreSQL (свой планировщик, column-storage, шардирование, партиционирование, своя WAL-репликация, компрессия и т.д). В таких условиях rebase на более новую версию PostgreSQL — очень сложная, дорогая и долгая процедура. Например, rebase на версию 8.4 (сейчас 8.3) продолжается уже c полгода.

Как показывает практика других похожих по функционалу проектов (Citus Data, PostgresXL), построить полноценную аналитическую колоночную СУБД для DWH просто добавляя простенькую реализацию шардирования к PostgreSQL не получается. Хорошее распределённое OLTP-хранилище — да, OLAP RDBMS — нет.

Выдержка из поста представителя Citus Data на одном из форумов:
Сitus is not a traditional data warehouse. We position Citus as the real-time, scalable database that serves your application under a mix of high- concurrency short requests and ad-hoc SQL analytics (i.e. think both random and sequential scans for a customer-facing analytics app). The default storage engine for Citus is the PostgreSQL storage engine, which is row-based. This is in contrast to many data warehouses, which often use a column store and/or batch data loads, and are focused purely on analytics. The trade-offs you get are: — Citus vs. DWH performance: DWH and Citus both have a similar parallelization for analytics queries (multi-core, multi-machine), but most data warehouses typically use a columnar storage engine instead of a row-based one. Columnar storage is designed for faster analytics queries, so that makes columnar DWH generally faster on longer running analytics queries. However, this comes at the expense of (1) concurrency and (2) short-request performance (think simple lookups, updates, real-time data ingest) vs. Citus' row-based storage.


Как показывает практика других похожих по функционалу проектов (Citus Data, PostgresXL), построить полноценную аналитическую колоночную СУБД для DWH просто добавляя простенькую реализацию шардирования к PostgreSQL не получается.

То есть к Greenplum это тоже относится?

А что посоветуете из того, что как раз для DWH и «LAP» (т.е. OLAP, но не обязательно Online)?
Отмена. Не так понял разницу Citus и Greenplum.
Да, имелось ввиду что для аналитических сценариев нужен специфический функционал, которого нет в Citus и PostgresXL, но он есть (в том или ином виде) в GP.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.