Прозрачное архивирование PostgreSQL: как pgEdge ColdFront сокращает расходы на СУБД до 90%

Прозрачное архивирование PostgreSQL: как pgEdge ColdFront сокращает расходы на СУБД до 90%

Проблема стоимости хранения исторических данных

С ростом масштаба бизнеса объем баз данных под управлением PostgreSQL неизбежно увеличивается. В транзакционных системах (OLTP) значительную долю занимают исторические данные — старые заказы, логи событий, финансовые транзакции прошлых лет. Хранение сотен гигабайт или терабайт архивных данных на быстрых и дорогих твердотельных накопителях (SSD/NVMe), необходимых для обеспечения низкой задержки (latency) текущих операций СУБД, становится экономически нецелесообразным и может составлять значительную часть ИТ-бюджета.

Традиционные методы архивирования, такие как перенос исторических строк в отдельные архивные таблицы, сжатие во внешние файлы или экспорт в специализированные аналитические хранилища, создают серьезные проблемы для разработчиков. Данные переходят в статус «только для чтения» (read-only), а доступ к ним требует переписывания SQL-запросов в коде приложения. Более того, при необходимости изменить или удалить архивную запись (например, при получении запроса на удаление персональных данных по правилам GDPR) инженерам приходится выполнять сложный и рискованный процесс «регидратации» (rehydration): переносить архивные файлы обратно в горячую базу, выполнять операцию удаления, повторно сжимать и загружать данные в архив.

Концепция pgEdge ColdFront: полностью перезаписываемый холодный слой

Для решения этих сложностей компания pgEdge 18 июня 2026 года представила решение ColdFront — систему прозрачного разделения данных (transparent data tiering) для классического PostgreSQL. Основным отличием ColdFront от традиционных архиваторов является сохранение полной возможности перезаписи (fully writable cold tier) архивных данных.

UPDATE и DELETE запросы продолжают без ограничений работать с архивными строками напрямую, используя исходные имена таблиц и стандартный SQL. Приложению не требуется знать, где физически находится строка — в горячей оперативной памяти или в холодном хранилище. Вся логика перехвата запросов и прозрачного взаимодействия с архивом выполняется на уровне расширения базы данных. Если клиент отправляет запрос на удаление пользователя, запись удаляется как из активных таблиц PostgreSQL, так и из архивных Parquet-файлов в объектном хранилище без ручного вмешательства администратора.

Внутреннее устройство: Apache Iceberg и DuckDB под капотом

Под капотом ColdFront автоматически переносит старые секции (partitions) секционированной таблицы PostgreSQL в открытый формат Apache Iceberg (с использованием колоночного сжатия в файлы Parquet). Эти файлы размещаются во внешних недорогих объектных хранилищах (S3-совместимые хранилища, Google Cloud Storage или Azure Blob Storage ADLS Gen2). Это позволяет сократить расходы на хранение архивных данных до 90%.

Для обеспечения высокой скорости чтения аналитических запросов по холодному слою разработчики интегрировали движок DuckDB непосредственно внутрь процесса PostgreSQL. При сканировании архивных данных DuckDB выполняет векторизованную колоночную обработку Parquet-файлов. Такой подход обеспечивает ускорение аналитических запросов в 10–100 раз по сравнению со стандартным построчным чтением в PostgreSQL. Поскольку Apache Iceberg является открытым индустриальным стандартом, сохраненные архивные данные могут свободно считываться внешними системами аналитики (такими как Apache Spark, Trino, Snowflake или Databricks) напрямую из объектного хранилища без участия PostgreSQL или ColdFront.

Управление жизненным циклом данных и режимы работы

ColdFront автоматизирует рутинные операции по обслуживанию секций с помощью гибко настраиваемых периодов жизненного цикла:

1. hot_period: определяет временное окно, в течение которого данные считаются горячими и удерживаются на локальных дисках PostgreSQL.
2. retention_period: задает максимальный срок хранения архивных данных, по истечении которого они автоматически удаляются из холодного хранилища. Система самостоятельно создает будущие секции в фоновом режиме и параллельно отсоединяет (detach) устаревшие секции без блокировки основных транзакционных операций записи.

ColdFront поддерживает три основных режима работы:

• Tiered (Гибридный): классический режим, при котором свежие данные хранятся локально в PostgreSQL, а старые автоматически вытесняются в Apache Iceberg на S3.
• Decoupled (Разделенный): режим без локального диска, оптимизированный под бездисковые аналитические и AI-нагрузки, где все данные изначально лежат в объектном хранилище Iceberg.
• Partition-only: режим чистого управления жизненным циклом секций без использования внешнего холодного хранилища.

Интеграция в Spock и распределенные Mesh-сети

Для геораспределенных баз данных на базе multi-master репликации pgEdge Spock решение ColdFront предлагает гибридную схему. Горячие транзакционные данные реплицируются между узлами Mesh-сети через Spock, в то время как холодный слой на базе S3 является общим для всех узлов.

Специализированный протокол сериализации коммитов bakery protocol предотвращает конфликты версий (ошибки HTTP 409) при одновременной записи в Iceberg с разных узлов СУБД. В ходе тестирования 6-узловой mesh-сети с объемом данных в 60 миллионов строк система подтвердила пропускную способность записи в холодный слой на уровне 4.4 миллиона строк в секунду. Это открывает возможности прямого подключения аналитических и AI-инструментов к гигантским массивам данных через стандартные драйверы PostgreSQL без развертывания промежутекных ETL или CDC систем.

Инструкция по подготовке и тестированию

В настоящее время решение ColdFront находится на стадии публичного бета-тестирования (v1.0.0-beta1). Оно полностью совместимо со стандартным upstream-дистрибутивом PostgreSQL версий 16, 17 и 18, не требуя установки закрытых проприетарных форков. Для тестирования функционала рекомендуется следующий порядок действий в изолированном окружении:

1. Подготовьте работающий сервер PostgreSQL (версии 16, 17 или 18).
2. Настройте объектное хранилище (локальный MinIO, облачный S3, Azure или Google Cloud Storage) и получите реквизиты доступа.
3. Создайте тестовую секционированную таблицу, определив правила разделения по датам.
4. Установите расширение coldfront и настройте параметры подключения к объектному хранилищу в файле конфигурации postgresql.conf.
5. Задайте параметры hot_period для вашей таблицы. Убедитесь, что старые секции автоматически конвертируются в Parquet и переносятся на S3.
6. Выполните пробные запросы UPDATE и DELETE к архивным строкам, чтобы убедиться в прозрачности и сохранении возможности записи холодного слоя. Не переносите конфигурацию в промышленную среду (production) без отладки процедур резервного копирования и восстановления.