LINUX.ORG.RU

Вышел Postgres Pro Enterprise для 1С 18.4.1 с оптимизациями под тяжёлые нагрузки

 , ,

Вышел Postgres Pro Enterprise для 1С 18.4.1 с оптимизациями под тяжёлые нагрузки

1

2

Компания Postgres Professional объявила о выпуске Postgres Pro Enterprise для 1С 18.4.1. Обновление ориентировано на крупные инсталляции «1С», где база данных регулярно сталкивается со сложными запросами, множеством соединений, временными таблицами, отчётами и регламентными операциями. В официальных замечаниях к выпуску указано, что новая версия основана на PostgreSQL 18.4 и Postgres Pro Enterprise 18.3.2.

Одно из главных изменений — возможность использовать временные таблицы, временные последовательности и временные представления на сервере горячего резерва. Функция включается параметром enable_standby_temp_tables вместе с enable_temp_memory_catalog и hot_standby. Практический смысл простой: тяжёлые отчёты и ETL-процессы можно переносить на standby-сервер, не нагружая основной узел.

Для планировщика запросов добавлен механизм enable_join_predicate_pushdown. Он позволяет проталкивать условия соединения из внешнего запроса во вложенные подзапросы, чтобы оптимизатор мог выбрать более удачный план выполнения. Также ускорена оценка селективности для больших списков MCV и улучшена работа с ограниченными выборками через planner_upper_limit_estimation; это должно быть заметно в типичных сценариях «1С», включая закрытие периода и построение отчётов.

Обновлены и средства отказоустойчивости. Встроенное решение BiHA перешло на версию 1.8: многоуровневая геораспределённость и катастрофоустойчивость больше не считаются экспериментальными, а служебные соединения между узлами можно защищать SSL-сертификатами. В Proxima появилась адаптивная балансировка, учитывающая CPU, память и дисковый ввод-вывод, а также поддержка нескольких адресов подключения — IPv4, IPv6 и Unix-сокетов.

В релиз также вошли новые инструменты и расширения. pgpro_iheap добавляет табличный метод доступа iheap, рассчитанный на ускорение последовательного сканирования, а pgpro_temp_stats автоматически собирает статистику по временным таблицам, чтобы планировщик не работал вслепую. Для администраторов добавлена утилита pgpro_validate, которая проверяет целостность файлов, индексов, таблиц, системных каталогов и прав доступа в экземпляре Postgres Pro.

Так как Postgres Pro Enterprise 18.4.1 основан на PostgreSQL 18.4, в него также вошли исправления из апстрима PostgreSQL. Для обновления в пределах той же основной версии достаточно установить новый выпуск в текущий каталог, но при изменении ABI разработчики рекомендуют обновить поставляемые расширения или пересобрать сторонние.

>>> Источник

★★★★★

Проверено: cetjs2 ()
Последнее исправление: cetjs2 (всего исправлений: 2)

Так как Postgres Pro Enterprise 18.4.1 основан на PostgreSQL 18.4, в него также вошли исправления из апстрима PostgreSQL.

Спасибо Кэп за разъяснения!

dicos ★★★
()

Точно, для 1С) 1С без разницы, какой там enterprise. СУБД для 1С просто хранилище. Работа с данными, в основном, вне СУБД.

AndrK189100
()
Ответ на: комментарий от AndrK189100

На обычном постгрес оно работает хуже… медицинский факт. возможно тюнинг какой то может улучшить ситуацию, но рецепты такие не попадались, в своё время.

unclestephen ★★★★★
() автор топика
Ответ на: комментарий от AndrK189100

там какие-то оптимизации и механики добавлены, я сильно не разбирался, но 1с с ними работает, а вот с ванильным пг ну прям так себе.

bernd ★★★★★
()

Знаете что я хочу вам сказать. Я когда-то работал в компании «деловые линии». Там возникла проблема: в таблицу добавляли всё новые и новые поля и нужно было делать всё более сложные joinы.

Я предложил сделать хранимые процедуры. Которые могут выбираться в зависимости от времени и которые пишут в выборку то что туда попало без joinа

Не в коня корм. И базу не пофиксил и joinами трахаются

ckotctvo
()
Ответ на: комментарий от ckotctvo

Я почему это написал. Вот эти оптимизации под «тяжёлые нагрузки»…

А как насчёт того чтоб прекратить жрать гавно?

Ваши «тяжёлые нагрузки» результат как минимум не продумывания нагрузок а как максимум недумания за пределами «ящика»

ckotctvo
()
Ответ на: комментарий от unclestephen

1С одинаково хреново работает на любой СУБД. Проблема 1С архитектурная.
Плюс в современных конфигурациях это все усугублено БСП. Даже элементарный перенос части вычислений в СУБД, дал бы существенный прирост производильности. Но, тогда резко возрастают требования к квалификации «погромистов 1с». И уже не купишь «специалистов» по рублю за пучок. Вырастет стоимость внедрения и владения.

AndrK189100
()
Последнее исправление: AndrK189100 (всего исправлений: 1)
Ответ на: комментарий от ckotctvo

Я предложил сделать хранимые процедуры. Которые могут выбираться в зависимости от времени и которые пишут в выборку то что туда попало без joinа

Я не понел. То есть предлагается заменить стандартный SELECT на ручное пробегание по таблицам?

rkn-bot
()
Ответ на: комментарий от AndrK189100

1С одинаково хреново работает на любой СУБД. Проблема 1С архитектурная.

Цена, которую приходится платить за возможность одинаково работать с постгресом, мсскулем и их собственным форматом ака «файловые базы». Не назвал бы это проблемой.

Мне ничего не мешает считать, что можно посчитать, силами постгреса.

Плюс в современных конфигурациях это все усугублено БСП.

БСП, при грамотном обращении, - хорошо. Ещё лучше, чтобы добрую половину ОбщегоНазначения в платформе было, а не на интерпретируемом языке в конфе писалось. Оно ж появилось от того, что в платформе чего-то очень нужного нет.

И документация Шрёденгера по ней - боль. Вроде бы описано, что надо, всё, и можно разобраться. Но порой ответ на вопрос там найти - проще код открыть, и по нему раскрутить. Тем более, что в документации далеко не всё.

требования к квалификации «погромистов 1с». И уже не купишь «специалистов» по рублю за пучок

Вот это прям беда. «Зачем запрос сложный пишешь, можно же в 1С посчитать!», «Зачем инициализировать переменную с нужным типом - это же набирать долго, фигач Неопределено». И этоперемидл\недосеньёр с многолетним опытом говорит.
И нежелание добавлять в BSL префиксные\постфиксные операторы инкремента\декремента, или свич, вызванное тем, что «понапишут потом тяжелосопровождаемого» - тоже показательно.

mogwai ★★★★★
()
Ответ на: комментарий от rkn-bot

не, просто разные таблицы. у компании постоянно добавлялись поля в записи и они не придумали ничего лучше чем заводить дополнительные таблицы и joinами совмещать выборки. а можно просто делать новые таблицы и хранимой процедурой выбирать из какой читать и какие поля дописать в случае если в старой версии их нет

ckotctvo
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.