PostgreSQL isn’t just a simple relational database; it’s a data management framework with the potential to engulf the entire database realm. The trend of “Using Postgres for Everything” is no longer limited to a few elite teams but is becoming a mainstream best practice.
OLAP’s New Challenger
На встрече по базам данных в 2016 году я утверждал, что значительным пробелом в экосистема баз данных PostgreSQL является отсутствие достаточно хорошего колоночного хранилища для OLAP-нагрузок. Хотя сама PostgreSQL предлагает множество аналитических функций, её производительность при полномасштабном анализе больших наборов данных не совсем соответствует специализированным хранилищам данных в реальном времени.
Рассмотрим ClickBench, аналитический тест производительности, где мы задокументировали производительность PostgreSQL, её расширений и производных баз данных. Неоптимизированная PostgreSQL показывает слабые результаты (x1050), но может достигать (x47) с оптимизацией. Кроме того, есть три расширения, связанные с анализом: колоночное хранилище Hydra (x42), временные ряды TimescaleDB (x103) и распределённая Citus (x262).
Эту производительность нельзя назвать плохой, особенно по сравнению с чистыми OLTP базами данных, такими как MySQL и MariaDB (x3065, x19700); однако её производительность третьего уровня не является «достаточно хорошей», отставая от компонентов первого уровня OLAP, таких как Umbra, ClickHouse, Databend, SelectDB (x3~x4) на порядок. Это сложная ситуация — недостаточно удовлетворительная для использования, но слишком хорошая для отказа.
Однако появление ParadeDB и DuckDB изменило правила игры! Нативное расширение PG ParadeDB pg_analytics достигает производительности второго уровня (x10), сокращая разрыв до верхнего уровня всего до 3–4 раз. Учитывая дополнительные преимущества, такой уровень расхождения в производительности часто является приемлемым — ACID, свежесть и данные в реальном времени без ETL, отсутствие необходимости в обучении новым технологиям и поддержке отдельных сервисов, не говоря уже о возможностях полнотекстового поиска уровня ElasticSearch.
DuckDB сосредоточен на чистом OLAP, доводя производительность анализа до предела (x3.2) — исключая академически ориентированную, закрытую базу данных Umbra, DuckDB можно считать самой быстрой для практической OLAP-производительности. Это не расширение PG, но PostgreSQL может полностью использовать прирост производительности анализа DuckDB как встроенной файловой базы данных через проекты, такие как DuckDB FDW.
Появление ParadeDB и DuckDB поднимает аналитические возможности PostgreSQL до верхнего уровня OLAP, заполняя последний важный пробел в её аналитической производительности.
Маятник мира баз данных
Различие между OLTP и OLAP не существовало при зарождении баз данных. Разделение OLAP-хранилищ данных от баз данных появилось в 1990-х годах из-за того, что традиционные OLTP-базы данных не могли поддерживать шаблоны запросов и требования к производительности аналитических сценариев.
Долгое время лучшей практикой в обработке данных было использование MySQL/PostgreSQL для OLTP-нагрузок и синхронизация данных со специализированными OLAP-системами, такими как Greenplum, ClickHouse, Doris, Snowflake и т.д., через процессы ETL.
Как и многие «специализированные базы данных», сила специализированных OLAP-систем часто заключается в производительности — достижении улучшения на 1–3 порядка по сравнению с нативной PostgreSQL или MySQL. Однако цена за это — избыточные данные, дополнительные затраты на инфраструктуру и сложность управления.