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
()
Ответ на: комментарий от AndrK189100

Помниццо мне, как я пытался сопрячь Firebird и PowerPoint. Примерно из этой серии. Причём я был близок к успеху. Не сопряг, так сложилось.

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

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

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

А, то есть есть изначальная таблица T(pkey, A, B, C, D), а потом наплодили дополнительных таблиц по мере выдумывания новых атрибутов T1(pkey, X, Y), T2(pkey, U), T3(pkey, W). Но всё равно не понятно, как тут можно ускориться по-сравнению с обычными join и при этом не нагородить слопа. Может проще иногда объединять всё в одну таблицу или же перейти к схеме (entity_key, attr_name, attr_value).

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

Microsoft тоже вносит и сопоставимый. Давайте писать про их продукты. Postgres Pro – это некогда приличная компания, которая планомерно закрывает свой код, а в сообщество идут багфиксы на баги, найденные клиентами, минорные комиты и кодревью. Но спама, что мы «опенсорс» попрежнему много. Этой новости место на cnews и forbes )

powerguy ★★★
()

на opennet.ru про это ни слова, кстати

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

Мечтаю о том что когда-то будет реализован анализ конфигураций 1С чтобы на их основе в какой-то нормальной БД или бухгалтерии можно было бы делать автоматически разворачиваемые системы. Вот уж куда ИИ можно было бы применить!

Раз поднапрячься, сделать, и далее спокойно не напрягаясь потреблять то, что 1Сники понадёргали из своих источников во власти

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

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

А зачем это в 2026? Почему бы просто не использовать PG даже локально, спрятав его от «дешёвых программистов 1С» чтобы они не испугались?

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

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

А зачем это в 2026? Почему бы просто не использовать PG даже локально, спрятав его от «дешёвых программистов 1С» чтобы они не испугались?

Жаль, конечно, что такую светлую идею, такие светлые умы подают только сейчас, а не в каком-нибудь мохнатом 1991 году, когда все начиналось. Представляете, как бы они, 1С, тогда бы развернулись? А так столько времени потеряли, подсадили миллионы пользователей на свое недоподелие. Но можно же все это исправить, написав свой 1С, например, 3С, который будет работать только на Postgres (в общем-то тоже еще то знатное авно мамонта). Почему 3С. Ну, во-первых - чтобы никто не догадался. А во-вторых, потому что 2С вроде бы уже была - кто-то пытался переписывать 1С, и поэтому могут возникнуть юридические терки с этими поцами. Ждем когда нам здесь представят на обсуждение идеальный, опенсорсный 3С, использующий PostgreSQL. Удачи.

А еще жаль, что PostgresPro докатилось до того, что позиционирует себя как «база для 1С», а не как универсальная, современная, мощная база данных. Это как-бы Oracle позиционировал Oracle DB как «лучшая база для SalesForce», пытаясь поднять крохи с рынка его продаж. Но Oracle позиционирует себя как - самая лучшая универсальная база данных, а подстраиваются под нее уже разные производители других программ - ERP, CRM, Finance и т.д.

Кстати, адаптацию PostgreSQL под «особенности-изверты» 1С проводит не только фирма PostgresPro, но и сама 1С, а также Tantor - это из того, что я знаю. Может еще кто-то.

А PostgreSQL, скажем честно, это устаревшая база из того века, хотя и совершенствуемая в некоторых аспектах, но все равно база уровня Депертамента, а не Предприятия. Где-то на уровне Oracle 9i (2001 год) c примочками в виде JSON, GIS и некоторыми другими, картины не меняющими.

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

Ну и к чему был этот сарказм? Что им именно в 2026 мешает вынести остальные бэкенды и оставить ПГ?

А PostgreSQL, скажем честно, это устаревшая база

Ой всё

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

А еще жаль, что PostgresPro докатилось до того, что позиционирует себя как «база для 1С», а не как универсальная, современная, мощная база данных.

Во-первых, не база, а СУБД.

Во-вторых – вот ни за что не поверю, что ты не застал времена, когда Oracle себя рекламировала как «лучшая СУБД для Windows», при том, что самые серьёзные решения у них и тогда, и до, и после были как раз для юниксов. Это просто была конкретная ниша, в которой оракл агрессивно конкурировал с MS SQL Server – «и под Windows мы тоже лучшие». И ниш таких у одного продукта может быть сильно больше одной.

Тут примерно такая же история. PostgresPro не отказывается от титула универсальной, современной, мощной СУБД. Просто речь идёт об атаке на позиции, на которых ещё несколько лет назад безраздельно стоял тот же MS SQL Server. Обычно получается, что если взять ванильный PostgreSQL и вкатить на него 1С без тонкой настройки, результат будет так себе. А тут ребята предлагают решение.

А PostgreSQL, скажем честно, это устаревшая база из того века

А это без технических аргументов просто малохудожественный свист.

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

взять ванильный PostgreSQL и вкатить на него 1С без тонкой настройки

не получится. Без «патчей от 1С» не заработает. Но не помню, не заработает совсем (раньше точно какого-то из типов данных не хватало), или просто медленно работать будет, но в прод точно не проканает.

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

Что им мешает вынести остальные бэкенды и оставить ПГ?

Здравый смысл, и владение предметной областью.

Что им именно в 2026 мешает

Другие задачи, которые на развитие направлены будут, а не на деградацию.

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

Ты реально не понимаешь, почему ты глупость написал?

Проблемы трёх бэков нет. У 1С свой промежуточный язык запросов не из-за нескольких бэкендов. А потому что в условном Регистре накопления «ЦеныНоменклатуры» поле «Номенклатура» на одном сервере это _inforg72010._fld72011rref, а на другом _inforg32198._fld32199rref. Ибо заранее знать, что в какой конфигурации понапишут невозможно. Они же не одно конкретное приложение пишут, а платформу для разработки бизнес приложений.

И главное, допустим, есть таблица, где хранятся цены на товар: «Дата(date), Товар(str), Цена(int)». Для простоты цены без копеек (необходимость даты объяснять, надеюсь, не надо).

Напиши запрос для получения всех цен на определённую дату. А 1Снику для этого достаточно ВЫБРАТЬ * ИЗ РегистрНакопления.Цены.СрезПоследних(&Дата), платформа сама развернёт его в правильный SQL запрос.

Поэтому на чистый SQL 1С не перейдёт. И как ты думаешь, за взаимодействие со всеми СУБД отвечает один код, или под каждую у них отдельный коннектор есть? Как улучшится ситуация с постгресом, если чуваков, что под мсскуль пишут, разгонят? Никак.

«Цена которую приходится платить» - это не «плохо поддерживаемый X», а например:

В СУБД PostgreSQL реализована только частичная поддержка FULL OUTER JOIN (ERROR: «FULL JOIN is only supported with mergejoinable join conditions»). Для реализации полной поддержки FULL OUTER JOIN при работе 1С:Предприятия 8 с PostgreSQL подобный запрос трансформируется в другую форму с эквивалентным результатом, однако эффективность использования конструкции ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ снижается.

В связи с этим не рекомендуется использовать ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ при работе с PostgreSQL. В большинстве случаев без использования этой конструкции можно обойтись, переписав исходный запрос.

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

Удовлетворён на 120%

Почему не на 122%? Чего не хватило? Или НДС недоплачиваешь?

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

Напиши запрос для получения всех цен на определённую дату. А 1Снику для этого достаточно ВЫБРАТЬ * ИЗ РегистрНакопления.Цены.СрезПоследних(&Дата), платформа сама развернёт его в правильный SQL запрос.

Вот это, кстати, можно переписать на SQL через VIEW с читаемыми названиями столбцов. А View можно создать из метаданных. На проектах и в организациях так и делают, когда надо брать данные из базы данных 1С. Иногда, правда приходится это делать по нескольку раз, потому что метаданные могут измениться.

Проблема у 1С вот в чем: в середине-конце 1990х годов 1C после успеха файловой версии на DOS и р выбрали для себя (что тогда было совершенно обосновано), в качестве ОС - Windows, в качестве подхода - Модульное программирование как в СOM и Visual Basic, когда модули пишутся квалифицированными программистами на объектно-ориентрованных языках, типа С+, а эти модули потом используются менее продвинутыми программистами, даже в процедурном стиле, но при этом получается делать стандартные решения достаточно быстро, без отвлечения на мелочи. Язык 1С, соответственно - это Visual Basic подобный язык с элементами Pascal, и некоторыми другим плюшками на ORM и модулями, названными как «Платформа 1С». И в качестве базы данных была выбрана Ms SQL Server, что тоже было естественно, потому что это была средняя по мощности, недорогая по баблу база данных, нативная для Windows от серьезной фирмы. Oracle представлялся тогда тяжелой, дорогой базой данных, работающей в основном на UNIX (SUN Solaris, IBM AIX и т.д.), что для средне-мелкого бизнеса, на который был нацелен 1С было за гранью возможностей. Ни о каких Postgre тогда речи не шло, потому что за ней не стоял какой-то крепкий вендор, опенсорец был в зачатке и это было какой-то экзотикой для гиков, как и Linux в целом.

Но 1С слишком положились на Ms SQL Server и задействовали все ее специфические средства и механизмы, которых не было в других базах данных или они там работали не так. И у 1С с Microsoft даже был непрочный «альянс» на этой почве.

Позже, когда Microsoft в России начала пытаться продвигать свои ERP - Navision, Axapta, 1С, типа пытались показать Мелкомягким, что они тоже могут обойтись без Ms SQL Server и начали попытки адаптировать 1С к работе и на других бд - на IBM DB2 for Windows, Oracle - но ничего хорошего из этого не выходило и эти варианты были скорее для «галочки».

Затем, когда начались терки с Западом с одной стороны, а с другой необходимость удешевить владение 1С, начали адаптировать к работе на PostgreSQL.

Но, как я написал, выше, 1С была сильно завязана на Ms SQL Server и некоторых ее специфических механизмах. Поэтому «адаптация» PostgreSQL для 1С - это попытка сделать PostgreSQL похожей на Ms SQL Server вплоть до неправильного порядка сортировки и т.д., ну и как я тоже ранее писал PostgreSQL - менее качественная база чем Ms SQL Server и Oracle, поэтому требует дополнительных настроек и оптимизаций и все равно на одинаковом железа работает хуже чем Ms SQL Server.

Oracle, кстати, тоже не пошел для 1С примерно по тем же причинам - непохожесть на Ms SQL Server, и люди из 1С, которые адаптировали 1С под Oracle знали его не очень хорошо, до такой степени, что не знали, что в версии Oracle 10g и выше для таблиц есть Recycle Bin и поле оператора DROP TABLE таблицы физически не удаляются, а копятся в этой Корзине, что приводило к тому, что диски забивались полностью. (физически таблицы удалялись после очистки из Корзины и освобождали занимаемое место).

Кстати, у SAP для их внутреннего языка ABAP (COBOL) есть механизм работы с базами данных «OPEN SQL», который представляет простой SQL, без специфических для той или оной базы фишек. Поэтому SAP раньше работал спокойно как на Ms SQL Server, так и на Oracle, а сейчас на SAP HANA.

Как-то так.

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

Вот это, кстати, можно переписать на SQL через VIEW

Ну перепиши) Но не забывай, что ты должен сохранить возможность разработчика написать эквивалент

ВЫБРАТЬ Товар,Цена ИЗ РегистрНакопления.Цены.СрезПоследних(&Сегодня);
ВЫБРАТЬ Товар,Цена ИЗ РегистрНакопления.Цены.СрезПоследних(&НеделюНазад, Товар = "Лицензия на ПостгресПро");
ВЫБРАТЬ Товар,Цена ИЗ РегистрНакопления.Цены.СрезПоследних(&ЧерезНеделю, Товар ПОДОБНО "%Постгрес%");

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

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

с читаемыми названиями столбцов.

SELECT 
Товар,Цена,Количество,Сумма,НалогооблажениеНДС,СтавкаНДС,СуммаНДС,СуммаСНДС
FROM [ЗаказКлиента Товары];

SELECT 
Nomenclatura,Tsena,Kolichestvo,Summa,NalogooblojenieNDS,StavkaNDS,SummaNDS,SummaSNDS 
FROM [ZakazKlienta Towary];

SELECT 
Nomenclature,Price,Quantity,Total,VATTaxation,VATValue,TotalVAT,TotalWithVAT
FROM [ZakazClienta Tovari];

Что бы выбрать? 5 переключений раскладки на простейший запрос? Или нечитаемое месиво? А может лучше по лингве каждому разработчику и бухгалтеру выдать, чтобы переводили (и надеяться, что все сообразят, что под «Amount» предыдущий разработчик подразумевал именно количество, а не сумма (или наоборот? он же нифига не нейтив, мог и перепутать)?

Проблема у 1С вот в чем: в середине-конце 1990х годов 1C после успеха файловой версии на DOS

Слишком поздно начал. Надо было с изобретения полупроводников. Когда-то привязались, теперь отвязываются. И что?

как я тоже ранее писал PostgreSQL - менее качественная база чем Ms SQL Server

Статистику по гарантийным случаям где брал, чтобы качество сравнить? Или исходник мсскуля дорогой гарнитурой набран, а Постгрес - бесплатным «дежавю моно», потому первый более качественно написан?

Кстати, у SAP для их внутреннего языка ABAP (COBOL) есть механизм работы с базами данных «OPEN SQL»,

Кстати, у 1С для их внутреннего языка 1С (BSL) есть механизм работы с базами данных «Язык запросов»…

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