Postgres Pro и 1С: как использовать, лицензировать и выжимать максимум для аналитики

С переходом многих компаний на отечественное ПО всё чаще используется связка: платформа 1С:Предприятие + СУБД Postgres Pro. Это промышленный, сертифицированный стек, который позволяет работать не только с оперативными бизнес-процессами, но и строить на его основе полноценную аналитическую платформу — в том числе для BI, отчетности и Data Warehouse.

1. Почему Postgres Pro для 1С

Postgres Pro — это расширенная версия PostgreSQL, разработанная компанией Postgres Professional, включающая дополнительные модули, улучшения производительности и сертификацию ФСТЭК. С 1С она используется как полноценная backend-СУБД, начиная с версии платформы 8.3.8 и выше.

Преимущества:

Поддержка официально сертифицирована 1С.
Более высокая производительность по сравнению с vanilla PostgreSQL (в т.ч. при работе с большими справочниками и регистрами).
Интеграция с российскими ОС: Astra Linux, Альт и др.
Поддержка 1С-совместимого режима, обеспечивающего работу с типами, транзакциями и блокировками.

2. Лицензирование Postgres Pro под 1С

Postgres Pro лицензируется в зависимости от редакции и сценария использования.

Варианты:

Редакция	Особенности
Postgres Pro Standard	Базовая редакция, Open Source + поддержка
Postgres Pro Enterprise	Расширенная: онлайн-индексация, JIT, репликация
Postgres Pro Certified	ФСТЭК-сертифицированная, для госкомпаний

Лицензия 1С + Postgres Pro

Существует специальная лицензия "Postgres Pro для 1С", доступная только через партнёров 1С. Она лицензируется:

по числу ядер CPU, участвующих в обработке.
Требует отдельного ключа лицензии, не путать с лицензией 1С.

Важно: лицензия "для 1С" НЕ покрывает использование Postgres Pro как DWH/BI, API или ETL-сервер. Для аналитики нужна дополнительная лицензия или отдельная инсталляция Postgres Pro Enterprise.

3. Технические аспекты работы 1С с Postgres Pro

Поддержка ключевых режимов

Компонент 1С	Поддерживается
Хранилище конфигурации	✓
Распределённая ИБ	✓
Регистр накопления	✓
Фоновые задания	✓
Управление блокировками	✓ (через FOR UPDATE)
Распределенные транзакции	× (обход — middleware)

Особенности производительности

1С генерирует SQL в нестандартной форме:

SELECT ... FROM (SELECT ... FROM ...) AS _1 WHERE ...

Это вызывает:

множественные JOIN’ы
использование NULL-safe-сравнений
активную работу с временными таблицами

Рекомендации по настройке:

shared_buffers = 30-40% RAM
work_mem = 128MB
effective_cache_size = 75% RAM
random_page_cost = 1.1
seq_page_cost = 1.0

Обязательно:

включить jit = off для 1С (JIT замедляет маленькие OLTP-запросы)
использовать только официальную сборку Postgres Pro с патчами для 1С

Характерные нагрузки

Много UPDATE, DELETE по индексам
Высокая частота создания временных таблиц
Использование "табличных" UUID и ссылок
Автогенерация сложных SQL через ORM

4. Извлечение данных из 1С для аналитики

Сложность в том, что 1С хранит данные в унифицированных регистрах, и названия таблиц не очевидны (_DocumentNN, _AccRgXXXX, _InfoRgXXX, _ReferenceXXXX, _EnumXXX и т.д.).

Этапы подготовки аналитики

4.1. Выделение витрин

Определить справочники (Reference), документы (Document), регистры накопления и сведений.
Разобрать метаданные 1С (можно выгрузить .epf или .xml или подключиться через COM).

4.2. Доступ к таблицам напрямую

SELECT * FROM "_Reference59" -- например, справочник "Контрагенты"

SELECT * FROM "_Document293" -- например, документ "Поступление товаров"

Названия зависят от конфигурации. Лучше использовать метаданные через 1С API или выгрузку конфигурации.

4.3. Создание представлений под BI

CREATE VIEW v_sales AS
SELECT
  d._Date AS doc_date,
  c._Description AS customer_name,
  l._Quantity AS qty,
  l._Price AS price
FROM _Document293 d
JOIN _Document293_VT l ON d._IDRRef = l._Document293_IDRRef
JOIN _Reference59 c ON d._Fld2234RRef = c._IDRRef;

5. Подключение BI к Postgres Pro под 1С

Power BI, Tableau, FineBI, Superset — работают через стандартный PostgreSQL-драйвер.
Данные приводятся к читабельному виду через представления или ETL (dbt, Airflow).
Настраиваются витрины: продажи, склад, движение, остатки, документы.

6. Рекомендации по архитектуре

Подход	Комментарий
Разделение среды OLTP и BI	Идеально: отдельный read-replica
Прокси-схемы и views	BI не должен обращаться к "сырым" таблицам
Инкрементальная выгрузка	Через _Period, _Date, _Number
Партиционирование	Применимо на уровне витрин
ETL через Airflow/dbt	Возможна сборка витрин по расписанию

7. Что можно получить для аналитики

Сквозной отчет по продажам: из документов + регистров
Анализ запасов по складам: регистр накопления + справочники
Анализ отклонений по документообороту
BI-дашборды на базе Power BI, Superset, Qlik

Аналитика по 1С на Postgres Pro: от таблиц к витринам

1. Карта соответствия таблиц 1С и метаданных

Платформа 1С использует внутреннюю структуру хранения данных в виде «технических» таблиц, названия которых не соответствуют именам объектов конфигурации. Вот основные типы объектов и соответствующие таблицы:

Объект 1С	Префикс таблицы	Пример названия	Содержание
Справочник	_ReferenceNN	_Reference59	Таблица справочника
Документ	_DocumentNN	_Document293	Таблица шапки документа
Табличная часть	_DocumentNN_VT...	_Document293_VTGoods	Табличная часть документа
Регистр накопления	_AccumRgNN	_AccumRg123	Регистр остатков, оборотов
Регистр сведений	_InfoRgNN	_InfoRg77	Периодические и не периодические
Перечисления	_EnumNN	_Enum43	Значения перечислений
План счетов	_ChartOfAccountsNN	_ChartOfAccounts4	План счетов
План видов характеристик	_ChartOfCharacteristicTypesNN	_ChartOfCharacteristicTypes12	Виды характеристик
Регистр расчётов	_CalcRgNN	_CalcRg18	Расчёты, графики начислений

Чтобы понять, какой номер (NN) относится к какому объекту — можно:

экспортировать конфигурацию из 1С (в XML);
использовать инструменты reverse engineering;
подключиться через COM API и получить метаданные.

2. Разворачивание витрин с dbt (data build tool)

2.1 Каталог проекта

dbt init analytics_1c
cd analytics_1c

2.2 Настройка подключения (profiles.yml)

analytics_1c:
  target: dev
  outputs:
    dev:
      type: postgres
      threads: 4
      host: 1c-postgres-host
      port: 5432
      user: dwh_user
      pass: yourpassword
      dbname: 1c_db
      schema: analytics

2.3 Пример модели витрины продаж models/sales_mart.sql

WITH raw_sales AS (
  SELECT
    d._Number AS doc_number,
    d._Date AS doc_date,
    c._Description AS customer_name,
    l._Fld112 AS quantity,
    l._Fld113 AS price,
    l._Fld112 * l._Fld113 AS total
  FROM _Document293 d
  JOIN _Document293_VTGoods l ON d._IDRRef = l._Document293_IDRRef
  JOIN _Reference59 c ON d._Fld234RRef = c._IDRRef
  WHERE d._Posted = true
)

SELECT
  customer_name,
  date_trunc('month', doc_date) AS month,
  SUM(quantity) AS total_qty,
  SUM(total) AS total_amt
FROM raw_sales
GROUP BY customer_name, date_trunc('month', doc_date);

models/schema.yml
version: 2

models:
  - name: sales_mart
    description: "Витрина продаж по клиентам"
    columns:
      - name: customer_name
        tests:
          - not_null
      - name: total_amt
        tests:
          - not_null

2.4 Запуск

dbt run
dbt test

3. ETL-скрипты для ежедневной выгрузки продаж и остатков

3.1 Скрипт на SQL (Postgres Pro)

-- выгрузка продаж за вчера
INSERT INTO dwh.sales_fact (doc_date, customer_id, product_id, qty, price, total)
SELECT
  d._Date,
  d._Fld234RRef,
  l._Fld123RRef,
  l._Fld112,
  l._Fld113,
  l._Fld112 * l._Fld113
FROM _Document293 d
JOIN _Document293_VTGoods l ON d._IDRRef = l._Document293_IDRRef
WHERE d._Date >= current_date - interval '1 day'
  AND d._Posted = true;

3.2 Скрипт по остаткам

-- Выгрузка остатков по складам
INSERT INTO dwh.stock_balance (warehouse_id, product_id, quantity, actual_date)
SELECT
  _Fld305RRef,   -- склад
  _Fld306RRef,   -- номенклатура
  SUM(_Fld307)   -- количество
  , now()
FROM _AccumRg123
WHERE _Period = (SELECT MAX(_Period) FROM _AccumRg123)
GROUP BY _Fld305RRef, _Fld306RRef;

3.3 Автоматизация (Airflow DAG)

from airflow import DAG
from airflow.providers.postgres.operators.postgres import PostgresOperator
from datetime import datetime

with DAG('daily_sales_etl', start_date=datetime(2024, 1, 1), schedule_interval='@daily') as dag:
    load_sales = PostgresOperator(
        task_id='load_sales',
        sql='sql/etl_load_sales.sql',
        postgres_conn_id='postgres_dwh'
    )

    load_balance = PostgresOperator(
        task_id='load_balance',
        sql='sql/etl_load_stock_balance.sql',
        postgres_conn_id='postgres_dwh'
    )

    load_sales >> load_balance

Результаты

После настройки такого контура можно:

Автоматически собирать данные из 1С;
Иметь читаемые витрины в BI;
Делать отчеты без прямого подключения к сырым таблицам 1С;
Построить сквозную аналитику от остатков до выручки.

Репликация Postgres Pro для аналитики под 1С

Зачем это нужно

1С работает в OLTP-режиме: быстрые вставки, блокировки, короткие транзакции. Аналитические запросы (JOIN, GROUP BY, агрегаты по миллионам строк) могут:

замедлить основную работу 1С;
вызвать блокировки;
затруднить сопровождение.

Решение:

Настраиваем реплику (standby) на отдельный сервер и отправляем туда всю аналитику, BI-запросы, витрины и ETL.

Какие есть типы репликации в Postgres Pro

Тип	Подходит для 1С?	Описание
Потоковая (streaming)	✓	Репликация WAL (write-ahead logs)
Логическая (logical)	Частично	Работает не со всеми объектами 1С
Slony / Bucardo	×	Устаревшие, не рекомендуются

Для 1С подходит потоковая репликация — она стабильна, эффективна, и не требует изменений в схеме.

Пошаговая настройка потоковой реплики для 1С

1. На главном сервере (master)

Подготовка postgresql.conf

wal_level = replica
max_wal_senders = 5
wal_keep_size = 2048MB
archive_mode = on
archive_command = 'cp %p /var/lib/postgresql/wal_archive/%f'
hot_standby = on

В pg_hba.conf

Разрешаем подключение standby:

host replication replica_user 192.168.1.50/32 md5

Создаем пользователя:

CREATE ROLE replica_user REPLICATION LOGIN PASSWORD 'yourpassword';

2. На реплике (standby)

Остановка PostgreSQL и очистка старой БД:

sudo systemctl stop postgrespro
rm -rf /var/lib/pgpro/14/data/*

Синхронизация данных через pg_basebackup:

pg_basebackup -h master-host -U replica_user -D /var/lib/pgpro/14/data -Fp -Xs -P -R

Параметр -R автоматически создаст файл standby.signal (для PG14+).

3. Проверка запуска

sudo systemctl start postgrespro
tail -f /var/log/postgresql/postgresql-14.log

Если всё корректно — реплика будет «читать» данные с главного сервера.

Как использовать реплику для аналитики

BI-инструменты (Power BI, Superset, Tableau) подключаются к standby.
Вы создаёте только read-only соединения.
Можно создавать materialized views, индексы, функции, но только если реплика переведена в режим logical replica (logical decoding) или вы используете cascading replica с read-write.

Важно: ограничения standby-реплики

Возможность	Доступна?
SELECT-запросы	✓
CREATE MATERIALIZED VIEW	× (на read-only)
CREATE TEMP TABLE	✓
Индексы и ANALYZE	× (если без logical)
JOIN и аналитика	✓
VACUUM	×

Если вы хотите использовать BI-витрины — можно создать отдельную базу и реплицировать в неё данные логически, либо делать ETL на основе реплики, загружая данные в свою структуру.

Альтернатива: логическая репликация по таблицам

Работает через pgoutput или pglogical.
Можно транслировать только нужные таблицы (_DocumentXXX, _ReferenceXXX).
Позволяет писать собственную схему аналитики.
Требует больше поддержки, но даёт большую гибкость.

Рекомендации

Используйте реплику для всех BI-инструментов и dbt.
Настройте мониторинг репликации (отставание pg_stat_replication.lag).
Раз в сутки прогоняйте sanity-тест: row count между master и replica.
Если нужно собирать витрины → используйте отдельную БД + ETL с replica.
Не ставьте BI на ту же ноду, где работает 1С — даже с read-only.

Заключение

Да, вы можете и должны использовать реплику Postgres Pro под 1С для аналитики. Это:

безопасно (read-only),
разгружает основную базу,
работает из коробки,
не нарушает структуру 1С.

Настройка реплики Postgres Pro для 1С с помощью pg_basebackup

Исходные условия

Параметр	Значение
Главный сервер	192.168.1.100
Реплика	192.168.1.101
Пользователь репликации	replica_user
Версия Postgres Pro	14
Каталог данных	/var/lib/pgpro/14/data

Шаг 1. Конфигурация главного сервера

1.1 postgresql.conf (на 192.168.1.100)

# Для репликации
wal_level = replica
max_wal_senders = 5
wal_keep_size = 2048MB
hot_standby = on
archive_mode = on
archive_command = 'test ! -f /var/lib/pgpro/wal_archive/%f && cp %p /var/lib/pgpro/wal_archive/%f'

Убедитесь, что archive_command и wal_keep_size соответствуют ожидаемому объему WAL.

1.2 pg_hba.conf (добавьте строку)

# Разрешить доступ к репликации
host replication replica_user 192.168.1.101/32 md5

1.3 Создать пользователя для репликации

CREATE ROLE replica_user REPLICATION LOGIN ENCRYPTED PASSWORD 'replica_pass';

Шаг 2. Подготовка реплики

На сервере 192.168.1.101 выполните:

2.1 Остановить СУБД и очистить каталог данных

sudo systemctl stop postgrespro-14
rm -rf /var/lib/pgpro/14/data/*

2.2 Выполнить pg_basebackup

pg_basebackup -h 192.168.1.100 \
              -U replica_user \
              -D /var/lib/pgpro/14/data \
              -Fp -Xs -P -R \
              --write-recovery-conf

Пояснение параметров:

-Fp: формат plain
-Xs: копировать WAL-логи
-R: создать standby.signal и файл подключения
--write-recovery-conf: записать строку подключения

2.3 Пример файла подключения к master (postgresql.auto.conf)

Создается автоматически, но можно вручную проверить:

primary_conninfo = 'host=192.168.1.100 port=5432 user=replica_user password=replica_pass'

Шаг 3. Запуск реплики

sudo systemctl start postgrespro-14

Проверить статус:

psql -U postgres -c "SELECT * FROM pg_stat_wal_receiver;"

Проверка

На главном сервере:

SELECT client_addr, state, sync_state, write_lag, flush_lag
FROM pg_stat_replication;

На реплике:

psql -U postgres -c "SELECT pg_is_in_recovery();"
-- Должно вернуть: true

Сценарий автоматизации (bash)

#!/bin/bash

MASTER=192.168.1.100
REPLICA_USER=replica_user
DATA_DIR=/var/lib/pgpro/14/data

systemctl stop postgrespro-14
rm -rf $DATA_DIR/*

pg_basebackup -h $MASTER -U $REPLICA_USER -D $DATA_DIR -Fp -Xs -P -R

systemctl start postgrespro-14

Архив WAL (опционально)

Для устойчивости при обрывах и long replay:

restore_command = 'cp /var/lib/pgpro/wal_archive/%f %p'

Полезные команды

# Проверка реплики
pg_controldata /var/lib/pgpro/14/data | grep "Database cluster state"

# Принудительная репликация WAL
SELECT pg_switch_wal();

# Задержка реплики
SELECT now() - pg_last_xact_replay_timestamp();

Заключение

Этот процесс позволяет:

Настроить read-only копию для BI и аналитики на отдельной ноде;
Изолировать нагрузку от 1С;
Сохранять актуальность данных с отставанием в несколько секунд/минут.

Логическая репликация только нужных таблиц

Когда не нужна полная база, можно избирательно реплицировать только нужные таблицы — например, sales, clients, documents.

Как работает

Используется pgoutput или расширение pglogical.
Репликация не требует standby — целевая база может быть read-write.
Можно фильтровать таблицы, столбцы и даже условия по строкам.

Шаги логической репликации

1. Настройка источника (master)

В postgresql.conf:

wal_level = logical
max_replication_slots = 5
max_wal_senders = 10

Создание репликационного слота:

SELECT pg_create_logical_replication_slot('slot_sales', 'pgoutput');

2. Создание публикации (на master)

CREATE PUBLICATION sales_pub

FOR TABLE public.sales, public.clients, public.documents;

3. На стороне получателя (target/Postgres Pro)

Убедитесь, что структура таблиц совпадает (можно pg_dump --schema-only).
Создайте подписку:


CREATE SUBSCRIPTION sales_sub
  CONNECTION 'host=192.168.1.100 port=5432 user=repl_user password=yourpass dbname=1c_prod'
  PUBLICATION sales_pub
  WITH (copy_data = true);

copy_data = true означает, что данные будут скопированы сразу, без ожидания новых WAL.

Примеры использования

Делать реплику только регистра остатков и документов для анализа логистики.
Реплицировать справочники в другую БД для обогащения витрин BI.
Подключить стороннюю систему без доступа к остальной базе 1С.

Ограничения логической репликации

Особенность	Поддержка
Триггеры	× (не активируются на subscriber)
Права доступа	✓
Изменения структуры таблиц	× (требует ручного обновления)
COPY, TRUNCATE, ALTER	×

Заключение

pgBackRest + потоковая репликация — лучший способ сделать standby для BI.

Логическая репликация — гибкий способ "выдернуть" только нужные данные без overhead от остальной 1С.

Postgres Professional — это российская промышленная СУБД, созданная на базе открытого PostgreSQL, но значительно расширенная для корпоративного применения. В отличие от классического PostgreSQL, решения от Postgres Professional включают в себя поддержку российских ГОСТов и сертификацию ФСТЭК, повышенную надёжность, оптимизации под высоконагруженные системы (в том числе 1С и DWH), инструменты резервного копирования, мониторинга и отказоустойчивости. За платформой стоит команда ядра PostgreSQL в России, что гарантирует актуальность, стабильность и экспертную техническую поддержку 24/7.

Для компаний, которым важно не просто использовать PostgreSQL, а внедрить его на уровне корпоративных стандартов — с гарантией, сопровождением, документированными улучшениями и адаптацией под российское законодательство — Postgres Pro Enterprise становится логичным выбором. Это не просто бесплатная база данных, а полноценный продуктовый стек, совместимый с BI, аналитикой, ERP, 1С и другими системами, в том числе импортозамещёнными.

← Предыдущая статья

Postgres Pro Enterprise: скачивание и установка

Следующая статья →

Postgres Pro на Windows: установка, настройка, особенности