Послушал тут разные мнения, в том числе Антона Дорошкевича по поводу того, кто кого заборет, MS Postgres или наоборот
С удивлением выясняется, что Postgres мало того, что как минимум почти везде не уступает MS, так еще и местами делает его, а вот это уже интересно
Кто что имеет сказать?
Мнение интересно с учетом всего: скорости, надежности, работы при перегрузках, цены, удобства, автоматических архивных копий, копий без выгона пользователей и т .д. т. п.

(418) Извиняюсь. Просто утомили уже. Каждому по десять раз надо повторить и разжевать - о чем идёт речь. И почему-то 9 из 10 1С-ников всерьез считают обычную настройку бекапов и обновления статистики тюнингом и магией 80 уровня.

(419) Чек-лист с ИТС делают не более 5% от общего числа серверных баз. Остальные именно "Далее - далее - готово" и все.

(420) 5% это ИМХО крайне оптимистично.
Далее далее далее я видел везде.
А что то там читать с ИТС - когда проблемы пойдут, а может к тому моменту я уже уволюсь(с) - типичная ситуация

(421) так вот оказывается в чем проблема :-)
постгри ставят там, где почему-то обитают Васи.

(422) Постри ставят что бы не платить за скуль.
А про DBA хотя бы на настройку все почему то забывают.
Ну если исключить крупные внедрения.

(409) понятие не имею о чем ты

(404) никто не тюнет. Если сильно прижмет настроют по рекомендациям 1С с итс.
Я лет 6 туда не заглядывал. Это сейчас, когда база доросла до 100 гигов, настроил по рекомендации 1С. Правда субъективно - ничего не поменялось

(425) к (414)

(384) что за глупости, постгрес также надежен как МС, а в вопросах восстановления на 2 головы выше

(380) судя по вакансиям центра им.Хруничева порогов набирают на скуль и оракл.Как с санкциями?

(415) Прогресс не остановить, в России будущее за Postgres

(427) "в вопросах восстановления на 2 головы выше"
Ага щаз. Ну, подскажите тогда простой способ подцепить существующие базы с неживого сервера на новый. Вот если внезапно сервер умер, не грузится, но каталог с базами доступен.

(429) этого никто не знает. Тут видение будущего меняется примерно раз лет в 10, а однажды поставленные системы от 1С чаще всего столько не живут по причине морального устаревания.

https://habr.com/post/433056/
На днях стало известно о том, что экспертный совет по программному обеспечению при Минкомсвязи собирается через полгода начать исключать из реестра отечественного софта продукты, которые базируются на разработках иностранного происхождения. По словам авторов идеи, эта мера принесет пользу заказчикам, которые находятся под санкциями или могут попасть под них.

(428) тока вакансиям в Хруничева больше года

(432) Это Госсектор

(382) если владельцу автопарка должны привезти тушу поросёнка, причем в любом случае везти по жутким пробкам - какое ему дело до модели транспортного средства? Ему главное - что-бы было довезено. А вот себестоимость транспортных расходов с учетом амортизации будет не в пользу мерса.

(432) ну и 1С надо исключать.
оно же - само 1С - не на отчетсевнном софте написано. а какойнить иностранный язык типа Си. и фреймворк еще какойнит использовался некузявый.

(336) Хрень какая.
Вот внедряю я ВМС.
ошибки лезут. где же без них.
и говорю клиенту
"Со временем ситуация будет только улучшаться с этим делом. Но и сейчас оно уже намного лучше и легче устанавливается, настраивается и ошибок меньше. Намного меньше."
- клиенту это ПОХЕР. ему надо работать СЕЙЧАС. а не в будущем. И не абы как, а "эффективно и производительно и недорого" - он для этого систему брал.

(434) Это да, госсектор должен страдать.

(400) не совсем так. "Набор пакетов" у мс четко фиксирован и на момент заказа точно знаешь что берешь. Коробка  - это вендор. Мы берём любую современную поставку мсскл и 1С с ним работает - это коробка. В случае с постгри производитель клиентского ПО 1С патчит сервер под себя. Да и вообще, любой кому не лень может сделать свой дистр постгри, и что там будет - зависит от его левой пятки. Какая же это коробка?

вообще, говорить о какой-то продуктивности этого спора можно будет в том случае, когда будет некий дистр постгри, который будет оснащен конфигом, обеспечивающим работоспособность большинства баз... ну хотя бы самых часто встречающихся, до 50 Гб размером. Без ловли клинов спустя несколько месяцев после установки. Для MS SQL это так или иначе есть, доступно. А когда об этом начинаешь говорить в постгри-сообществе, то немедленно сбегаются красноглазики, которые говорят что это нельзя, что все индивидуально, что нужна тонкая настройка и вообще надо смотреть хиты в кэше и pre-warm'ить таблички, без этого никак :)) Вот именно это и отпугивает от постгри людей.

(440) но оно так и есть.
Ты просто словил ошибку в 2011 году.

Мы в этом году просто взяли и переустановили на своих базах и ничего там каким-то особым и хитрым образом не настаивали. И это не одна установка, а целая серия баз. Но они не большие, конечно, но их достаточно много. Обычные без особых претензий базенки. Обычно работают. На виндусовых компах, виндусовые версии постгри.

(441) Это я к тому, что свежий дистриб использовался и таких граблей, каких словили в 2011-ом не случилось больше.

(440)Повторю (412)
Ты точно отключал оптимизатор? Так-то пг работает годами, нет никаких клинов через 3 месяца

(443) да он с 2011 года наверное больше и не приближался к постгри - если я не прав, то прошу не обижаться :-)

(443)
+
https://its.1c.ru/db/metod8dev/content/4692/hdoc
Хотя эта раекомендация от января 2012, но, может где-то и раньше она встречалась

(444) :)

(417) Эт хорошо, что градус тебе понизили, может адекватнее будешь. А что касаемо прочего, то мне лично пофигу, что вы "перечисленное в чек-листах" тюнингом не называете, хотя, можете сделать "чек-лист" для ПГ и тогда его тоже тюнить не придется (можно даже вообще в скрипт засунуть оптимальную настройку). Как по мне - любое изменение дефолтных параметров - это тюнинг. И его надо проводить как на МС, так и на ПГ. Тот факт, что с МС-ом больше возились и по нему больше адекватных инструкций - это конечно плюс, но не столь существенный, чтобы возводить его на пьедестал.
И как правильно вам заметили в (441)-(445) надо еще смотреть на версии используемого ПО, т.к. в том же МС-2000 была известная бага с ТемпДБ, а в более новых версиях уже поправили. Так же и ПГ живет, развивается, да и конфы 1С поворачиваются к нему лицом.

(443) судя по всему, статейку вывесили как раз после этой проблемы. Потому как я встрял именно осенью 11, а дата - январь 12.

(444) да, я это бросил как страшный сон, и думаю, на тот момент я был прав. Но сейчас ситуация реально улучшилась? Можно браться за это?

я больше не напорюсь на грабли с падением бэкапа по недостатку памяти, вот на такую хрень с запросами? Или опять же это не гарантировано?

(449) Последние рекомендации по ссылке из (445) прочитал?
"
После изменнеия этих параметров, следует оценить возможное влияние этих изменений на работу системы и выбрать наиболее приемлимый выриант для ваших задач.
"
Всмысле : Попробуйте. Может повезет.

(448) А статистика, что количество установок постгри постоянно растет?

А упорство самой 1С, которая пилит связку с постгри гораздо активней, чем с той же DB2 или Оракл?

В моем окружении, например, почти все новые случаи установленных СУБД - это постгри. Там, где ставят мс скл - именно среди тех случаев, к которым я имею достаточно близкий доступ и знаю инфу как бы изнутри - либо заведомое грубое пиратство и абсолютное нежелание платить (там и просто за 1С платят хреново, не говоря уж про СУБД), либо навязанное свыше использование МС СКЛ за деньги вышестоящих организаций. Других вариантов сознательного выбора МС СКЛ я не встречаю. И это не в Москве, конечно. Я понимаю, что в Москве доступ к затратам на ай-ти несколько свободней и там есть масса других примеров.

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

(451) статистика статистикой, но интересен реальный опыт. Мне бы не хотелось повторно выкидывать на это свое время и силы просто так, поэтому и задаю вопросы. Тем более что по состоянию "на тогда" спросить было не у кого, из чего опять же следует вывод, что тогда я взялся за слишком сырую тему. Что ж, если сейчас все изменилось, то хорошо.

У нас есть клиент, который сидит на Postgree и старинном сервере 2010 года. В новой версии КА2.4 Гилев на нем выдал 10.5 попугая, что, честно, меня впечатлило. Если не уйдут на SQL - буду изучать Postgree, все вам потом расскажу.

Ведь у него есть планы запроса в виде xml, ведь да, да?

(452) если у ТЕБЯ нет реального опыта - то никакой другой тебя не впечатлит.

У меня есть РЕАЛЬНЫЙ опыт и что тебе с него... хотя я уже реально кучу постов в этой ветке напостил со своего опыта :-)

(455) это не цирк чтобы впечатлять. Я хочу понять, есть ли смысл этим заниматься, только и всего.

Насчёт постов и вообще этой ветки - да, я видел, ветка полезная, большое спасибо.

(453) На xml, наверное, не очень похоже https://habr.com/post/203320/
На работающей системе можно пользоваться модулем auto_explain https://postgrespro.ru/docs/postgrespro/11/auto-explain
А чтобы запрос на языке 1С сопоставлялся с запросом для СУБД и тут же рядом план выполнения запроса и стрелочкам показывались взаимосвязи между ними - да, такого нет, по крайней мере, бесплатного...

Кстати. Решил тут у клиента попробовать Постгре. Смотрю чего есть у 1С. Есть версия 9.6 и версия 10.5. Все хорошо, но версия 10.5 рекомендуется для платформы не ниже 8.3.13. А чета меня терзают сомнения по поводу 8.3.13. Да и развернуто щас все на 8.3.12. Таки что посоветуют опытные товарищи? Остаться на 8.3.12 и поставить 9.6 или перейти на 8.3.13 и поставить 10.5?

(459) я сам 10.5 не ставил еще, т.к. тоже хочу увязать ее использование с 8.3.13 или 8.3.14
Просто в описании 10.5 четко указано, что отличающие ее от 9.6 фишки заработают только на новой платформе. Т.е. ставить вроде как можно, но отличий заметно не будет.

(446) Не понял нафига ты мне это пишешь да ещё и со ссылками на посты, которые к моим высказываниям никакого отношения не имеют.
Если для тебя установка ПО заканчивается нажатием кнопки "Готово" в мастере установки, то Бог тебе судья.

Перенесли базу с pgsql на ms sql - стало тупить. pgsql 9.6 на centos, работало как часы около 3 лет, база специфическая,  толстый клиент >50 гб, перенесли из за проблем долгим восстановлением базы.

(462) Статистику сбрось. А еще лучше реструктуризацию сделай. База будет тупить пока не прогреется.

(462) pg_dump -Z 0 -j число_потоков(ядер процессора) может существенно ускорить данную процедуру. Сжать выгрузку можно и потом, тоже многопоточно. Восстановление аналогично.
Конечно, это все при наличии какого-нибудь количества ядер у процессора(и частоты), ну и, достаточном размере оперативной памяти.

(460) не все фишки требуют какой-то платформы. К примеру где-то пробегало что в 10.* Изменился алгоритм расчета хэшьта таблицы (для hаsh join) - платформа тут ничего не решает, а в 9.6 решили проблему деградации производительности при слишком большим значении effective_cashe_size (я ведь не сильно переврал имя параметра?) - тут тоже платформа никаким местом

(367)
Ну так возьми, настрой правоверно-пряморуко как ты любишь и выложи сюда результаты тестов.
Но тебе в лом настраивать постгрес.
И всем в лом.
И вообще не понятно - можно ли как-то умудриться заставить постгрес работать близко по скорости к мс скл.
Вот поэтому такие как ты только и ноют про чужие кривые руки, а на деле ничего подкрепляющего эти слова не имеют.

(466) Так вот же тесты, MS хуже: http://catalog.mista.ru/public/962876/

(467)
Там же комментарий Вячеслава Гилева
"отличная манипуляция и подтасовка фактов, в лучших традициях маркетологов 1С"

(468) Так нет других тестов, остальные просто так болтают, вообще без каких-либо цифр.

(468) А Вячеслав да, тот ещё фрукт :))

(466) ну нет у МС СКЛ какой-то особой скорости

Вот отткуда из обсуждения по ссылке копипаст сделаю
---
(74) если вы ознакомитесь с ответом (53) , пройдете по ссылкам и посмотрите видео, то поймете что PostgreSQL, впрочем как и MS SQL Server - продукты которые мы и сами используем, и нашим клиентам настраиваем.

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

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

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

мы за правду, а не за тренды и маркетинг

понятно объяснил?
http://forum.infostart.ru/forum86/topic205816/message2109892/#message2109892

жаль, что тут сейчас выделение штрифтами не срабатывает...

вот обратите внимание на мнение Гилева по ссылке в (472)
---
а мне бы не хотелось терять будущих коллег по PostgreSQL
потому что типовые конфигурации, особенно старые,
а еще больше доработки фирм франчайзи
не заточены под PostgreSQL,
и не достаточно поставить субд и галочки понажимать,
надо еще пилить код, причем, не пять минут

Вроде 1cfresh на Postgresql работает.
Это о чем-то говорит.

(474) Ну как работает... вроде бы просто служебная вспомогательная база, типа ЛК на ней крутиться

(475) А базы пользователей на чем?

(476) хз

кнопка (так фирма называется) свой фреш на постгри разворачивала. Даже на хабре о проблемах писали

https://habr.com/company/knopka/blog/345692/
https://habr.com/company/knopka/blog/333480/

(477) хз, что там внутри статьи за проблемы, но

Заключение

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

У нас более 350 Гб информационных баз отлично себя чувствуют, растут и развиваются. Чего и вам желаем!

и в другой статье

С этого момента у нас есть минимальный работающий сервис 1C Fresh. Как видно, развернуть его достаточно просто.

Заключение

Это далеко не весь функционал. Можно настроить планируемые обновления конфигураций, синхронизацию данных в сервисе. Добавление шлюза приложений обеспечивает масштабируемость экземпляра сервиса, добавляя в него новые информационные базы и сохраняя единый внешний адрес для однотипных информационных баз. Сайт и форум сервиса, мониторинг недоступности и прочие можно без проблем ввести в эксплуатацию совместно с сервисом 1C Fresh, что дает гибкость в выборе функционала в зависимости от ваших потребностей.

(т.е. здесь даже самоцель 1С Фрэш, а не проблемы с постги, но инструкция весьма и весьма подробная - любопытно ее действия воспроизвести)

По поводу 1С:Fresh в госсекторе - http://gov.cnews.ru/news/top/2018-12-06_informsistema_kaznachejstva_i_minfina_sekonomit
"Платформа сервиса бухучета строится на платформе «1С:фреш», которая позволяет разворачивать работу с «1С:Предприятием» на любых компьютерах через интернет. В качестве СУБД для системы используется Posgres Pro отечественной компании Postgres Professional. Серверы работают под управлением ОС семейства Linux."

(474) > Вроде 1cfresh на Postgresql работает. Это о чем-то говорит.
(475) >  Ну как работает... вроде бы просто служебная вспомогательная база, типа ЛК на ней крутиться

Насколько я знаю, часть(!) (не весь) сервиса 1cfresh крутится на Postgresql. Причем довольно давно (не один год). И точно речь идёт непосредственно о самих реальных базах данных, а не о каких-то служебных или вспомогательных.

(480) Возможно. Я просто читал где то несколько лет назад об этом.

(472) Всё это лирика и эмоции. Странно видеть такую реакцию от такого уважаемого спеца, как Гилёв.

> подача материала не нравится тем, что доверчивые люди решат что PostgreSQL решит все их проблемы...

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

Ну и далее по тексту перечислен ряд особенностей Postgres, часть из которых на сегодняшний день с последними версиями  PG уже не так остро актуален. (типовые конфигурации,...доработки франчайзи не заточены под PostgreSQL, ...надо еще пилить код,...). Действительно было время, когда надо было затачивать код 1С под PG. Сейчас эта потребность перешла в категорию "желательно" из категории "жизненно необходимо".

(482) А что изменилось? Т.е. если я возъму допиленную УПП 10ти летней давности то всё будет летать, так как проблема в PG? Или проблема частично решена исключительно при использовании последней версии БП 3.0 (так как она во фреше на PG крутиться), а в УТ11/ERP проблема осталась? Т.е. пробллема в конфигурации и всё решается индивидуально, т.е. все равно нужно затачивать код?

(483) Уж сколько раз всё это обсуждалось...
Есть (условно) несколько вариантов.
1. У вас типовые конфигурации актуальных версий на последних версиях платформы  с последними версиями PG. Проблем вообще быть не должно.
2. У вас есть старые конфигурации (в том числе допиленные), но крутятся они на актуальной версии платформы (в режиме совместимости или без него - не принципиально) с актуальной версией PG. Глобальных проблем у вас не будет, но возможны тормоза в отдельных сценариях. Как раз в той части кода, о необходимости допиливать который пишет Гилёв.
3. У вас старые конфигурации (возможно с дописками, а возможно и без) на старых версиях платформы и соответственно  (из-за совместимости по системным требованиям) на старых версиях PG. Тут действительно всё грустно. Надо долго шаманить с настройками PG, переписывать 1С-овский код для нормальной работы PG и т.п.

Но суть то в том, что Дорошкевич пишет о последних актуальных версиях платформы (не ниже 8.3.5 если не ошибаюсь) и версиях слона (не ниже 9.6). А плача о плохой работе древних версий платформы с древними версиями PG я, честно говоря, не понимаю.

Проблема о которой пишет Гилёв существует, но, ИМХО, несколько им преувеличена.

(483) >все равно нужно
не нужно, а нужно было... например ранее была проблема у запросов с полным соединением - недели 2 назад проверяли у себя... не воспроизводится! У актуальной версии ПГ + актуальных версий типовых проблемы не выявлено.

(485) Т.е. это единственная проблема которая тормозила переход?

(486) у нас кроме упыпырища(старая, переписанная и дописанная в хлам, обновляем только регламентированную) всё на постгре уже пару лет как... По упп все наши текущие тесты с проблемами пройдены успешно. Тестили 10.3-3.1с тех.платформа если не забыл 8.3.13.1667

(484) Можно еще добавить - на древних серверах тех же лет.

(487) Вчера выложили 10.5.9

(489)минорные версии постгри это как правило чисто баг-фикс, ставить разумно сразу ее.

(490) Туда походу запихали фичи из 11 версии.

(489) Причем предыдущую вообще убрали. :)

(491) нет, фичи в мажорных обновлениях, у постгри такие обычно выходят примерно раз в год последнее время

что такое минор и мажор?

+(494) в контексте постгри

(493) Разница в релизах 10.3 и 10.5
http://downloads.v8.1c.ru/content//AddCompPostgre/10_5_9_1C/postgreUpdate_ru.htm
Оптимизация

1.Перед построением плана запроса выполняется упрощение запроса (удаление избыточных соединений и т.д.). План запроса строится по упрощенному запросу.

2.При вычислении стоимости сортировки учитываются стоимость сортировки одной или нескольких колонок, стоимость самой сортировки, количество операций сравнения полей.

3.Улучшена оценка стоимости соединения при построении плана запроса в том случае, если в планируемом запросе используется соединение таблиц с условием по нескольким колонкам.

4.При планировании запроса, содержащего выражение СГРУППИРОВАТЬ ПО, планировщик выбирает наиболее оптимальный индекс из имеющихся (исходя из списка полей в выражении). На основании выбранного индекса планировщик может изменить порядок полей в выражении СГРУППИРОВАТЬ ПО для того, чтобы порядок полей соответствовал выбранному индексу.

Это же не ванильная сборка. Это Pro.

Надо потестить postgree

(497) Прошу результатами тестов поделиться с сообществом! :-)

Хехехе.
Вот она, сама мякотка.
Все обсуждают сферических коней...
Нельзя просто взять и поставить Postgree!

(499) Что значит нельзя? Берут и ставят.

(499) Я не буду удивлен, что это 1С-овцы ошиблись с описанием.

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

(499) под винду вообще только выбрать правильный каталог для base и локаль + потом проверить SecondaryLogon/ВторичныйВход.
Под Пингвином убедиться, что все либы той системы

+ (503) хотя и локаль и каталог можно потом сменить, но чуть сложнее и чуть больше знаний требует.

А чего у Постгре с разностным бэкапом? Или он может каждый минут 10 спокойно снимать полную копию не мешая работать и копия получается нормальная?

(505) Вопрос по Postgresql
Работать,при этом, не мешает. Нужно только некоторое количество ядер и достаточный объем памяти.
А так - пожалуйста, за деньги https://postgrespro.ru/docs/postgrespro/10/app-pgprobackup

(505) может.
Только зачем каждые 10 минут? )

(507) может ему реплика нужна?

Я работаю и с sql.
Но что мне лично претит- это политика $MS насчет лицензий на ядра. Цена, которую не все готовы платить. Плюс лицензии на сам вин сервер.
А вот, если соображаешь, как сделать на линуксе и postgre, получается нормально, и пофиг на размеры базы, все пугалки от незнания, нежелания напрячь мозги, а иногда и от ннадобности- когда привели, посадили перед ms sql на винде и все так хорошо, что ничего и не надо.

(508) интересно, какой смысл?

(509) нуууу, "если нет желания - ищется причина, если есть - способ"

(510) упала база и тут опа - поднялась реплика!

(512) это где на 1с такие базы, для которых такая срочность ?
И падучесть )

(513) не "и падучесть" а 10 минут простоя стоят конски дорого

(514) переходите на САП.)

(515) вы не перепутали оппонента? Не мне нужно каждые 10 минут бэкап.

(505) Можно смело поднимать отдельный сервер PostgreSQL для реплики. При этом за ним нужно следить, чтобы он не выключался на длительное время, иначе придется полностью перезаливать базу.

(517) смотря как сделано... может и основную базу завалить