PostgreSQL на Windows – реальная альтернатива для высоконагруженных систем на базе 1С

0. Антон Дорошкевич (user596204_a.doroshkevich) 119 31.05.17 11:28 Сейчас в теме
Многие интересуются PostgreSQL, но не знают, насколько хорошо будет она работать с уже существующими системами. «Инфософт» - одна из первых компаний, кто опробовал PostgreSQL на Windows. О своем опыте перехода рассказывает руководитель отдела информационных технологий компании.

Перейти к публикации

Комментарии
100. Евгений Фербер (omut) 02.07.17 12:54 Сейчас в теме
Прочитал и, честно говоря, ничего не понял. В том смысле, что не понял, где в статье находится полезная информация. Сплошная реклама в стиле "возможно все, приходите, мы вам покажем". Самое главное: нет анализа в каких конкретно случаях переход на такую загадочную (для меня во всяком случае) конструкцию, как Win+Psgr имеет смысл. ОК, у вас есть специалисты по настройке самой БД, есть специалисты и возможность переписывать код типовых конфигураций. Но почему тогда не перевести БД на linux? Что помешало или какие недостатки у подобного решения?
P.S. используем полностью "традиционное" win-решение для "больших" и "специфических" баз (некоторые в принципе не могут работать под linux. Для разработки и собственных "самописных" есть linux-сервер с postgre. Админам постоянно подкидываю статьи по оптимизации СУБД. Особых изменений не вижу. Вот что реально и грандиозно оптимизирует быстродействие, так это переписывание запросов, алгоритмов в самой 1С. Тут реально куча возможностей для оптимизации. И по текстам запросов, и по серверным вызовам, и по использованию объектной модели. И прирост производительности за счет подобных настроек на 1-2 порядка обычное дело. Но запиливать это именно ради СУБД... ну извините. Это совсем уж нужно быть фанатом-героем. И учитывая стоимость поддержки подобных решений (в течении срока жизни конфигурации/БД), особенное, если конфигураций несколько... Проще взять админа на широко знакомые решения. И проще, и дешевле. Потенциал у решения есть. Но реализовывать его нужно на уровне платформы (1С). Иначе практический смысл теряется. Вот авторы сколько возьмут за повышение производительности моего сервера до (или выше) уровня работы MSSQL? Авторы, вы нереально круты, но вот где ваше место в промышленной эксплуатации того, что есть мне не совсем ясно. ;)
101. Андрей Sh. (ansh15) 04.07.17 21:34 Сейчас в теме
(47) Задачи бизнеса своей компании автор публикации решает.
102. nick perel (nickperel) 2 10.07.17 09:30 Сейчас в теме
(59)
Если я всех пользователей загоню в терминал на сервер приложений, он же сервер СУБД, почты и домена... То и у меня настанет разруха.
Думаете так не бывает? Бывает.


Я бы сказал так и надо, при современном железе. По шаред мемори 1с - ms sql работает резче.
почта с доменом на 100-200 - ерунда, если производительно организован диск.
Терминальный сервер можно выбросить в виртуальную машину на другие ядра.
Какая разруха? Нормально все
103. Юрий Патласов (NoRazum) 18 11.07.17 18:49 Сейчас в теме
(98)
Если 1с сервер поставить на Линукс то убъёт быстрее полнотекстовый поиск.
УТ 11
25-30 пользователей. Нагрузка на диски создавал сам сервер 1с, а потом postgresql
на рам диск пришлось выкинуть. благо в линукс это проще сделать
104. Uladzimir - (nvv1970) 13.08.17 00:44 Сейчас в теме
"Нельзя просто так взять и перейти на Постгрес" (С)
Огромное спасибо автору за материал. Безусловно есть крупнейшие применения постгреса, с 1с и не только.
Однако следует вставить пару жирных НО...
На постгрес нельзя просто так перевести любую конфу. Внедрений на автоматических блокировках пруд пруди... Они наверно в еще долго будут в большинстве. ((( И что любопытно, до сих пор продолжают внедряться. Постгрес умрет не приходя в сознание.
На постгрес нельзя просто так взять и сделать "сложный" отчет. Например отчет, успешно работающий на десятках внедрений на точно такой же конфе вдруг вообще намертво виснет при почти отсутствующих данных на постргресе... В чем дело? Ах да... Слишком много соединений виртуальных таблиц (>10 шт). Но MS с этим вообще не заморачивался, а элефант не осилил построить план выполнения запроса. Эпик фейл.
Даже не подлежит сомнению, что все может быть переделано в лучшем виде (код переписан, скуль настроен) и postgres в состоянии утереть нос ms, но какой ценой? Конфигурации должны быть оптимизированы, говнокод не пройдет. Это автоматически обозначает, что 80-90% разработчиков (ниже уровня эксперта) нужно не допускать к проекту на постгресе. Что с ними делать? Увольнять? Не всегда у заказчика есть бюджет на экспертизу и оптимизацию проекта.
А что касается администраторов sql ? Где их взять? С MS худо-бедно все справляются. Да там и из коробки все хорошо, а регламент обслуживания поможет настроить франч-программист. Простая арифметика показывает, что в подавляющем большинстве допрасходы на спеца по постгресу превышают стоимость лицензии ms за год. При этом лицуху можно украсть, а зп админа - нет.
Вот такая жизненная грусть...
105. Сергей Крымов (СергейК) 50 13.08.17 14:28 Сейчас в теме
(104)
...Слишком много соединений виртуальных таблиц (>10 шт). Но MS с этим вообще не заморачивался, а элефант не осилил построить план выполнения запроса. ...

Версию Постгреса не помните?
106. Uladzimir - (nvv1970) 13.08.17 23:40 Сейчас в теме
(105) PostgresPro 9/4/9 1c for Windows. Кажется эта.
107. Sergey Andreev (starik-2005) 1041 14.08.17 09:58 Сейчас в теме
(104)
Но MS с этим вообще не заморачивался, а элефант не осилил построить план выполнения запроса.
А подробности будут? Скайп как-то работал, правда там не требовалось "слишком много соединений виртуальных таблиц" (которые, в свою очередь, тоже соединения).
108. Uladzimir - (nvv1970) 14.08.17 23:58 Сейчас в теме
.(107) ээээ.... какие тут нужны подробности? Влепили кучу соединений срезов (совместимость 8,2)
Для "подробностей" могу рекомендовать "курс эксперта" Виктора Богачева. (Огромная ему благодарность за развитие и знания).
По хорошему программировать нужно под определенную СУБД, учитывая все ее особенности. Любая логическая задача может быть реализована тысячами способов. Проблемный запрос может и должен быть перестроен так, как конкретной СУБД легче его переварить.
Оптимизатор MSSQL прощает миллионы "ошибок" дилетантов, легко выполняя то, чего не сможет правильно понять/переварить, например, PG. Но при небольшой оптимизации PG в состоянии показать нужную производительность (а в алгоритмах работы с дисками и большую, особенно на линухе).
Получается что пока мы не будем идеально программировать и обслуживать базы, мы будет сравнивать в первую очередь встроенные оптимизаторы, будем спотыкаться о протухшую статистику и плохие планы выполнения.
Как правило, такие знания избыточны, когда задача ставится очень быстро реализовать учет. Практически невозможно в момент разработки нового решения думать о тонкостях. Безусловно, многое держим в уме. Но настоящая оптимизация нужна, когда разработка устаканилась и набралось достаточное количество данных.

ПС: Для любопытствующих могу порекомендовать интересную статью про то как UBER с PG на MySql перезжал и подробное повествование причин переезда.
109. Sergey Andreev (starik-2005) 1041 15.08.17 00:02 Сейчас в теме
(108)
Для любопытствующих могу порекомендовать интересную статью про то как UBER с PG на MySql перезжал
С учетом того, что в MySQL нет оптимизатора запросов (как некоторые привыкли его понимать).
110. Uladzimir - (nvv1970) 15.08.17 00:06 Сейчас в теме
(109) это статья не касающаяся данного обсуждения)) просто интересная подноготная внутреннего мира СУБД
Оставьте свое сообщение