Вам прислали новость о Postgres Pro AXE 2.0, а рабочая база 1С хранится в PostgreSQL. Совпадение названий ещё не означает, что сервер пора обновлять.
Postgres Professional позиционирует AXE 2.0 как вычислительное ядро для OLAP и компонент хранилищ DWH и Lakehouse. Релиз касается аналитического контура, куда данные поступают из 1С для отчётов и обработки. Если такого контура у вас нет, миграцию на AXE планировать не нужно.
Администратору надо ответить на два вопроса: установлена ли AXE и вызывают ли ваши скрипты процедуры версии 1.x. Ответ отделит обычную новость от проекта, который придётся закончить до конца 2027 года.
Найдите AXE в схеме обмена данными
Начните не со списка пакетов на сервере 1С, а со схемы движения данных. AXE может стоять на отдельном узле, куда обмен или ETL-процесс передаёт сведения из рабочей базы.
В такой схеме пользователи вводят документы в 1С. Операционная СУБД хранит эти документы, обслуживает блокировки и проводит транзакции. AXE получает выгрузку и работает с аналитическими наборами.
Это два разных контура. Версия PostgreSQL под информационной базой ничего не говорит о наличии AXE.
| Схема компании | Касается ли её AXE 2.0 | Что делать |
|---|---|---|
| 1С работает со своей операционной базой, отдельного хранилища нет | Нет | Не включать AXE в план обновления |
| Отчёты строятся прямо в рабочей базе 1С | Нет | Проверять нагрузку на текущую СУБД, а не миграцию AXE |
| Данные из 1С выгружаются в AXE 1.x | Да | Найти вызовы старых процедур и подготовить пилот |
| Компания проектирует новый DWH или Lakehouse | Да | Сопоставить модель AXE 2.0 с архитектурой проекта |
| AXE 2.0 уже разворачивают на тестовом контуре | Да | Проверить загрузку, права, каталог и чтение отчётов |
Вывод: надпись PostgreSQL в настройках 1С не служит основанием для установки AXE 2.0.
Проверьте задания обмена, ETL-конвейеры, строки подключения и документацию аналитической системы. Ищите отдельную базу AXE, обращения к схеме metastore и параметр axe.data_storage_location.
Если ничего из этого нет, на этом проверку можно закончить. Релиз не требует остановки 1С, обновления операционной СУБД или изменения сервера.
В AXE 2.0 аналитические таблицы получили обычный SQL-интерфейс
Главное изменение затрагивает способ работы с аналитическими данными. В AXE 1.x для них применяли специальные хранимые процедуры, представления и прокси-таблицы.
В AXE 2.0 аналитические таблицы ведут себя как обычные heap-таблицы PostgreSQL. По сообщению Postgres Professional о выпуске версии 2.0, к ним можно обращаться командами SELECT, INSERT, UPDATE и DELETE.
Права тоже перешли на привычную модель PostgreSQL. Администратор выдаёт и отзывает их командами GRANT и REVOKE, а не отдельным набором операций аналитического слоя.
Для новых интеграций это сокращает число специальных конструкций. Загрузчик может записывать данные обычным SQL, а система отчётности — читать их через SELECT, если такая схема подходит проекту.
Старые интеграции от этого не становятся совместимыми автоматически. Если скрипт версии 1.x создаёт прокси-таблицы или вызывает metastore.*, его надо прогнать на пилотном контуре.
Подход здесь тот же, что при обновлении средств наблюдения за 1С: сначала проверяют отдельный экземпляр, затем рабочий. Подробный порядок такой проверки есть в материале про пилот обновления PPEM 2.9.
Слой совместимости даёт время, но не отменяет перенос
Официальная документация Postgres Pro AXE 2.0 описывает переход с ветки 1.x отдельно. Старые процедуры можно вернуть вызовом axe.create_metastore_aliases.
Postgres Professional заявляет их поддержку до конца 2027 года. Это срок жизни прежнего интерфейса, а не дата обязательной установки AXE 2.0.
Слой совместимости нужен для поэтапного перехода. Он даёт возможность сначала поднять новую версию, затем переносить служебные скрипты по одному. Оставлять старые вызовы без учёта и владельца до конца срока не стоит.
Соберите все обращения к metastore.* до пилота. Проверять только отчёты пользователей мало: несовместимость чаще проявится в загрузчиках, обслуживании каталога и создании хранилищ.
| Изменение в AXE 2.0 | Что искать в скриптах | Что проверить на пилоте |
|---|---|---|
Хранилище по умолчанию задаёт axe.data_storage_location | Старый способ задания основного пути | Новое значение параметра и доступ AXE к каталогу |
Пользовательское хранилище создаёт axe.create_storage | Вызовы metastore.add_storage | Создание, запись и чтение тестового набора |
metastore.add_storage игнорирует tmp_uri | Передачу временного пути | Не зависит ли загрузчик от содержимого tmp_uri |
metastore.remove_table игнорирует force | Удаление таблицы с параметром force | Как скрипт обрабатывает занятый или связанный объект |
metastore.rename_table не принимает схему в новом имени | Новое имя в формате schema.table | Переименование внутри нужной схемы |
Из metastore.copy_table удалён json_name | Именованный или позиционный аргумент json_name | Копирование таблицы без старого параметра |
Третий параметр metastore.add_files теперь содержит имя общего каталога | Путь к JSON-файлу в третьем аргументе | Загрузку файлов с новым значением аргумента |
| Каталог инициализируется при первом аналитическом запросе или вызове процедуры | Явный вызов metastore.init | Первый запуск на чистом тестовом экземпляре |
| Несколько процедур удалены | Вызовы процедур из списка ниже | Замену каждого вызова новым SQL или интерфейсом |
Вывод: основной риск сосредоточен в служебных скриптах каталога и загрузки, а не в запросах пользователей рабочей базы 1С.
Документация Postgres Pro AXE 2.0 перечисляет удалённые процедуры: metastore.create_view, metastore.test_show_view_sql, metastore.cleanup, metastore.expire_snapshot_on_time, metastore.expire_snapshot_on_ids, metastore.delete_expired_files, metastore.define_catalog_connection и metastore.init.
Ищите точные имена в репозиториях ETL, заданиях планировщика и скриптах развёртывания. Простого просмотра журналов рабочей 1С недостаточно: эти вызовы могут выполняться на отдельном аналитическом сервере.
Проверьте и позиционные аргументы. Скрипт может не содержать имя json_name, но всё равно передавать удалённый параметр на прежнем месте. Такой вызов легче пропустить при поиске по тексту.
Parquet и DuckLake меняют хранилище, а не скорость 1С
AXE 2.0 хранит данные аналитических таблиц в файлах Parquet. Метаданные лежат в SQL-таблицах по открытой спецификации DuckLake.
Переработанный каталог знает о содержимом файлов без их открытия. Эта модель влияет на устройство аналитического хранилища, резервное копирование его компонентов и интеграцию с внешними инструментами.
Из неё нельзя вывести ускорение рабочей базы 1С. В предоставленных материалах нет испытаний AXE 2.0 на нагрузке 1С, замеров времени отчётов или сравнения с операционной СУБД.
Не переносите на AXE цифры из новостей о Postgres Pro Enterprise для 1С. Это другой продукт, предназначенный для другой нагрузки. Его результаты ничего не доказывают о скорости AXE 2.0 в вашем аналитическом контуре.
По той же причине нельзя заранее назвать окно миграции. Время зависит от объёма данных, числа загрузчиков, вызовов metastore.*, способа хранения файлов и приёмочных проверок. Исходных данных для честного расчёта здесь нет.
Окно определяет пилот. Зафиксируйте время развёртывания, переноса тестового набора, проверки прав и выполнения контрольных отчётов. После этого добавьте резерв на возврат к прежней версии.
Что проверить на пилотном контуре
Пилот должен повторять не весь рабочий объём, а все способы обращения к AXE. Возьмите данные, на которых выполняются загрузка, изменение, удаление и чтение аналитических таблиц.
Сначала зафиксируйте текущую схему. Запишите версию AXE 1.x, параметры хранилищ, перечень процедур, роли, права и расписание заданий. Без этой описи не получится отличить ошибку миграции от старой неисправности.
Затем разверните AXE 2.0 отдельно. Не обновляйте единственный рабочий экземпляр ради проверки: пилот должен допускать удаление и повторное создание контура.
Проверьте четыре цепочки:
- Загрузка создаёт или обновляет аналитические таблицы.
- Роли получают доступ через
GRANTи теряют его послеREVOKE. - Служебные задания проходят без удалённых процедур и старых аргументов.
- Контрольные отчёты читают те же срезы данных, что до перехода.
Отдельно проверьте первый запрос после чистого развёртывания. AXE 2.0 инициализирует каталог автоматически, поэтому старый вызов metastore.init надо удалить или заменить согласно документации Postgres Pro.
Если компания регулярно обновляет PostgreSQL-компоненты, заведите для AXE такой же паспорт перехода: версия до миграции, версия после неё, владелец скрипта, результат пилота и способ возврата. Для обновлений операционной СУБД можно использовать отдельный порядок проверки версии и безопасного обновления сервера 1С.
Решение зависит от состояния вашего контура
Если AXE нет, ничего не устанавливайте из-за одной новости. Рабочая база 1С продолжает жить на своей СУБД, а релиз аналитического продукта её не затрагивает.
Если работает AXE 1.x, составьте перечень вызовов metastore.*. На пилоте проверьте удалённые процедуры, изменённые параметры, axe.data_storage_location, загрузку данных и права. Слой совместимости можно включить через axe.create_metastore_aliases, но перенос надо закончить до прекращения поддержки прежних процедур в конце 2027 года.
Если вы строите новый DWH или Lakehouse, проектируйте интеграцию сразу под AXE 2.0. Используйте прямой SQL, права GRANT и REVOKE, хранение в Parquet и каталог DuckLake. Наследовать интерфейс 1.x в новом проекте незачем.
Перед рабочим переходом примите контур по пяти признакам:
- загрузка завершилась без старых процедур и аргументов;
- роли читают только разрешённые таблицы;
- изменение и удаление данных проходят штатным SQL;
- контрольные отчёты возвращают ожидаемые срезы;
- время перехода и возврата измерено на пилоте.
Правило одно: миграцию AXE планируют по зависимостям аналитического контура, а не по версии PostgreSQL под 1С.