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

23.06.17

База данных - HighLoad оптимизация

Многие интересуются PostgreSQL, но не знают, насколько хорошо будет она работать с уже существующими системами. «Инфософт» - одна из первых компаний, кто опробовал PostgreSQL на Windows. О своем опыте перехода рассказывает руководитель отдела информационных технологий компании.      

Сейчас, действительно, настал момент, когда надо задуматься о переходе на PostgreSQL. Компания «Инфософт», как интегратор, давно интересуется этой темой, причем, следит за связкой PostgreSQL именно с 1С.

Все давно слышат, что системе 20 лет, она удачно работает как на маленьких инсталляциях, так и на огромных базах данных. Но как она работает совместно с 1С – большой вопрос. До сих пор есть опасения, что система долго и сложно настраивается.

Все эти сложности из-за информационного вакуума. Знающих людей достаточно мало, даже в рамках страны, и тем более, в рамках партнерского сообщества 1С. Людей, которые конкретно могут подсказать настройки, – единицы.

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

 

Подготовка к переходу и первый опыт

Непосредственно перед переходом придется решить один вопрос: на какой операционной системе это делать. Большинство переходов, осуществленных компанией «Инфософт», было совершено на ОС Windows. И вот почему.

Несмотря на то, что PostgreSQL разрабатывался под Linux-системы переход сам по себе с наиболее популярной системы в 1С на MS SQL на PostgreSQL – это риск. Риск, связанный с тем, что база данных работает совсем по-другому, и в большинстве случаев ее особенности малоизвестны. Поэтому если одновременно поменять операционную систему и перейти на Linux, то риск увеличивается в степень. Придется обучить администраторов с нуля, сломать все их стереотипы. Они всю жизнь работали на Windows. Более того, мир 1С – это 99% Windows. Конечно, есть энтузиасты, и их достаточно много, которые удачно ставят систему на Linux, но если что-то менять, то лучше постепенно.

Поэтому пока компания «Инфософт» проводит инсталляции на Windows. И тесты производительности 1С не выявляют особых кардинальных отличий на одной и той же скорости и конфигурации. Разница в реальных, не синтетических, нагрузках составляет 1-2% и не является критичной.

 

Первый опыт «Инфософта» – перевод базы данных Microsoft на PostgreSQL в самой компании. Что это за базы данных? Это полностью переписанные ПП1.3 (? Время: 3.56) на неуправляемых формах с интегрированной телефонией, рабочим кол-центром и т.д. до типовой бухгалтерии 3.0 уже на управляемых формах. Нагрузка составляет примерно 150 пользователей в пике.

Главным результатом перехода на PostgreSQL стало то, что пользователи ничего не заметили. Это один из самых положительных результатов, которые можно достичь при переходе. Какие-то процедуры стали немного быстрее, но в основном все работает точно так же. PostgreSQL позволяет спокойно спать администраторам ночью, и при этом не имеет никаких дополнительных расходов на покупку программного обеспечения, как сегодня MS SQL.

Поэкспериментировав на локальных серверах, мы перевели наш облачный сервис на PostgreSQL. Раньше он также работал на MS SQL.

1С Fresh в фирме 1С тоже частично работает на PostgreSQL. Мы полностью перевели наш сервис. Тут нагрузки серьезнее – 200 с лишним баз данных. Согласитесь,  большая разница: администрирование 1 базы данных на 1,5 терабайта и 200 баз на 1,5 терабайта. Отличаются требования к отказу устойчивости сервиса, к работе на 24/7/366 (? Время: 5:20). Кроме того, клиенты находятся по России, технологических окон практически нет, так что требования очень жесткие.

Что тут нас ждало? Очень приятный сюрприз: типовые конфигурации 1С хорошо справляются со своими действиями после перехода. Никаких значительных переписок кода нет.

Ничего не надо делать с массовыми типовыми конфигурациями, если они выпущены после 2015-го года. Фирма 1С сделала большие шаги с точки зрения платформы и с точки зрения переписывания кода в типовых конфигурациях, поэтому  от очень тонких моментов мы были избавлены.

Выход на рынок

После того, как все свои системы компания «Инфософт» перевела, было решено выйти на широкий рынок. Самым большим проектом по переводу с MS SQL на PostgreSQL был проект с крупным федеральным обувным ритейлером, который хотел перевести на систему PostgreSQL базы розницы.

Сложность перехода в данном случае заключалась в том, что необходимо брать в расчет сразу несколько сотен точек по всей стране, и все это должно реплицироваться. Это 40 баз общим объемом 6 терабайт. Это тысяча пользователей в онлайне. Очень жесткие требования к отказу устойчивости на уровне транзакций, при этом требования ужесточаются еще и тем, что никакого общего хранилища данных быть не должно. Все должно быть максимально независимо.

Тут очень сильно порадовала репликация PostgreSQL, работающая из коробки, плюс каскадная репликация, просто супер вещь, которая решает очень много задач. Фактически это полный аналог Microsoft, только полностью бесплатный.

Еще одним интересным проектом был перевод базы бухгалтерского учета федерального оператора экспресс доставки на PostgreSQL. Этот проект запомнился тем, что клиента перевели на новую систему за одну ночь. Представьте, 150 бухгалтеров ушли вечером, закрыв 1С в MS SQL, а утром пришли и открыли его в PostgreSQL. Ничего не поменялось в худшую сторону, некоторые операции стали работать лучше, некоторые продолжили работать точно так же. Клиент был настолько доволен результатом, что принял решение перевести все свои базы 1С, как существующие, так и проектируемые, на PostgreSQL. Он  даже он готов рискнуть перейти на Linux в 2017 году.

Технические стороны перехода

Какие особенности нужно учитывать, чтобы угодить клиенту при переходе на PostgreSQL? В принципе имеется 3 этапа. На первом надо настроить код 1С, на втором – подкорректировать настройки самого PostgreSQL, а на последнем – заняться подбором железа. Рассмотрим подробно каждый из них.

Код 1С. На этом этапе больше всего проблем, но когда они решаются, получаем огромный эффект. Конкретный пример: возьмем номенклатуру 300 тысяч позиций и попытаемся сформировать ценники и этикетки на все позиции. У конкретного заказчика MS SQL справлялся с этой задачей за 15 минут. Полностью настроенный PostgreSQL на Windows на том же железе, к сожалению, пришлось ждать 6,5 часов. Он справился, но с большой задержкой. Еще один пример: номенклатура 10 тысяч характеристик. Открывая позицию номенклатуры, заказчик хочет видеть не только 10 тысяч характеристик, но еще и остатки по каждой характеристике, да еще и в разрезе складов. Опять же MS SQL справлялся за 30 минут, а PostgreSQL пришлось ждать 12 часов. Но все гениальное – просто. Более того, написано на ИТС фирмы 1С. Основной причиной такого поведения было левое соединение с виртуальной таблицей последних средств. Здесь главная рекомендация – выносите срез последних виртуальных таблиц в отдельную временную таблицу и затем уже делайте соединение, как требует бизнес-логика  клиента. После этих изменений в коде (дольше их было искать, чем менять), скорости стали следующими: вместо 6,5 часов печать ценников производится за 13 секунд, вместо 12 часов открытие номенклатуры стало занимать 10 минут. Это совершенно приемлемые условия.

Еще одна рекомендация, правда, ее сложнее выполнить. Попробуйте избавиться от полного соединения. Тут уж если бизнес-логика позволит.

Никаких других рекомендаций нет.

Еще раз подчеркну, что все массовые конфигурации 1С прекрасно показывают себя на PostgreSQL. Не бойтесь переводить типовые инсталляции на PostgreSQL. Все отлично. Никаких задержек даже у такой тяжелой конфигурации как Комплексная 2.0 (там только запуск первого соединения к  базе занимает около 1,5-2 минуты и минус 2 гигабайта на сервере 1С оперативки).

Перейдем ко второму этапу – настройки самого PostgreSQL. Как наточить нашу систему в связке с 1С?

Для 1С используются (? Время: 12:00). Одним из главных патчей, которые влияют именно на быстродействие, является online_analyze. Обратите внимание: на сайте 1С последняя релизная версия PostgreSQL вышла 1,5 года назад, новее нет. Она содержит критичную ошибку в конфигурации PostgreSQL.  Этот патч (online_analyze) отключен. То есть мало того, что 1С и так любит временные таблицы, а PostgreSQL их недолюбливает, в конфигурации еще и патч отключен. Конкретно эта ошибка заставила нашу компанию отказаться от использования PostgreSQL на полгода. Мы поставили, попробовали, ужаснулись, но времени разбираться не было. А когда еще раз все перечитали, поменяли off на on, все поехало. Дальше остаются тонкости.

Еще несколько важных настроек.

1.      Не отключайте autovacuum. Единственный оправданный случай, когда можно отключить «автовакуумное» время, - это загрузка DT (? Время:13:40) в базу. Тогда, действительно, он будет создавать лишние блокировки. Загрузка – монопольная операция, в базу больше никто не заходит. Вы отключаете autovacuum, все спокойно создается, а затем включаете обратно.  Но чтобы autovacuum еще и плодотворно трудился и не сильно нагружал систему, количество worker-ов должно быть как минимум  4, а в идеале – 25% всех ядер, которые выделены серверу базы данных для работы с PostgreSQL.

2.      Оnline_analyze.enaible обязательно on. Кто  пробовал, и не устроило быстродействие, пересмотрите настройки в PostgreSQL. В самом конце, в самом неприметном месте, может быть такое «чудо».

3.      synchronous_commit = off. Эту настройку могу порекомендовать, только если fsync включен. Тогда мы экономим время записи транзакции. Она записывает только валы, и дальше идем, не ждем записи базы.

4.      В PostgreSQL имеется еще одно ограничение: здесь нет инструмента, похожего на профайлер. И чтобы собирать статистику, помимо технологического журнала 1С, рекомендую включать статистику logging_collector (оn).

5.      Следующий параметр позволит ограничить запросы 10 секундами. Все, что быстрее 10 секунд, не надо собирать, иначе соберёте гигабайт, а все что выше – собирать. Параметр log_min_duration_statement варьируете, как хотите, собираете сначала пики, когда десятисекундные пики срезали, собираете трехсекундные и так далее.

6.      Еще один параметр – update_process_title. Недавно появилась статья о результатах синтетического теста именно на Windows. Отключая параметр «обновление ID процесса», люди получили производительность в 2 раза выше. Но это только на очень серьезных нагрузках. В эксперименте тест начинал оправдывать себя только после 2 тысяч одновременных соединений. При этом на маленьких нагрузках это тоже не приводит ни к чему плохому. Все работало как раньше. Но на всякий случай включите, вдруг к вам зайдут 2 тысячи человек, а у вас система не выдержит.

Переходим к последнему этапу – подбор железа. Тут есть пара особенностей.

Во-первых, PostgreSQL не умеет работать многопоточно на много запросов. Один запрос – одно ядро. Поэтому количество ядер является достаточно критичным параметром при подборе железа сервера. Заставить PostgreSQL работать по-другому в нашей компании пока не знают как.

Второе ограничение. Мы живем в эпоху твердотельных накопителей. Нам повезло, они стали доступны и в то же время настолько надежны, что их можно использовать для баз данных. Единственное отличие: PostgreSQL в отличие от MS SQL всегда-всегда пишет в новое место, всегда создает рядом файл, неважно обновление это или нет. MS SQL создает файлик mdf, когда он пометил строчку на удаление, он пишет туда же. Это с одной стороны влияет на скорость, с другой – очень быстро наступит деградация ssd, если ваша операционная система и raid контроллеры не поддерживают команду TRIM. Иначе ssd (даже терабайтные) серверной версии «умрут» очень быстро, даже на 20 гигабайтной базе. На это обратите особое внимание. TRIM надо поддерживать. Обязательно.

Чтобы уменьшить требования к дисковой системе оборудования, можно воспользоваться несколькими трюками. Первый – директорию статистики перенести в диск оперативной памяти. Чем это хорошо? Это никогда не занимает много места – 256 мегабайт выделили, создали диск, перенесли. Даже если неожиданно каталог исчезнет, PostgreSQL не остановится. Просто будет появляться ошибка, что некуда записывать статистику. Тогда достаточно создать каталог заново, и статистика продолжит собираться. Несмотря на то, что директория не занимает много места, туда каждый процесс пишет очень много потоков, сильно нагружает диски. Очень рекомендую перенести директорию.

Первый трюк – это, можно сказать, must have. А второй – требует внимательности и аккуратности. Речь идет о переносе каталога журнала транзакций в оперативную память. В нашей компании это есть. Но я вам рекомендую это делать только в том случае, если у вас есть постоянный автоматический мониторинг репликаций, лучше еще и репликация каскадная. Если вдруг что-то пойдет не так, база встанет. Обратите внимание, если рискнете, нужно протестировать пиковые нагрузки на свои системы, чтобы понять, какой объем вала будет занят в оперативной памяти, чтобы выделить место заранее с запасом. Иначе, неожиданно сервер может остановиться.

Разработчики PostgreSQL, наверное, будут против такого решения, но оно очень помогает снизить нагрузку на дисковую подсистему. И в принципе где-то имеет право на жизнь. Наша компания пользуется таким решением год, и пока все хорошо.

 

Фичи

У PostgreSQL есть несколько неприятных особенностей, некоторые из них можно «пережить», другие – достаточно сложно.

Первая: PostgreSQL не умеет делать дифференциальное резервное копирование. Только полный backup. Казалось бы, ну и что? А то, что теперь место на резервном сервере, если вы хотите хранить информацию месяц (стандартный режим хранения), должно быть почти в 20 раз больше чем при использовании MS SQL.

Вторая: технологическое окно каждый день должно быть достаточно большим, чтобы спокойно сливать резервные копии. Как это обойти? Опять же с помощью репликаций. Настраиваете реплику, сливаете копии с  серверов реплик и все прекрасно. Production CD работает, сервер реплики может иметь на борту любое сетевое хранилище данных, а там сливаете и сливаете.

Еще один момент – гораздо более серьезный: PostgreSQL не имеет средств валидации файлов backup. Совсем. Вы сняли backup и никогда не узнаете, можно ли из него восстановиться. Казалось бы, ладно, восстанавливайся, проверяй, что база целая. Отлично. А если база в 15 терабайт и восстанавливается 3 дня? Я трое суток не буду знать, у меня на тот день база живая или нет? Здесь разработчики нам обещают, что в версии 9.6 либо 9.7 появится средство валидации, а также дифференциальные backup. Но пока их нет. На это надо обратить внимание. Резервная копия – спокойный сон для админов. Такого тут нет.

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

Поэтому рекомендуем настраивать средства мониторинга. Можно писать свои, использовать известные, например, Zaibix. Надо мониторить параметры железа, параметры баз данных, дополнительно мониторить еще лог, и вытаскивать из него ошибки...

В компании «Инфософт» решили проблему валидации backup-ов следующим образом: на 1С мы написали специальный веб-сервис (его можно увидеть на картинке). Что он делает? Посмертно проверить файл backup невозможно, но в процессе создания backup утилита (? Время 22:38) пишет лог ошибок. Мы анализируем во время создания backup лог, выводим в отдельный файл лог ошибок, и если файл пустой, значит, backup создался удачно. Если хотя бы что-то помешало это сделать, файл будет содержать текст ошибки. Далее достаточно администраторам выдать само сообщение, что какой-то backup ошибочный. Они уже разберутся, проверят все логи и остальное.

 

В завершении хочется подчеркнуть, что PostgreSQL позволяет не только жить в парадигме «денег нет, но вы там держитесь», но еще и жить комфортно и безопасно. А все ограничения, которые есть, в принципе удачно решаются.

Отдельное спасибо команде Postgres Pro за то, что они очень быстро делают сборки для 1С. Фактически спустя месяц после появления релиза PostgreSQL на сайте уже есть сборка для Linux и Windows. Пожалуйста, тестируйте. Причем, сборка для Windows крайне удачна, setup делает за вас 90% настроек, остается буквально чуть-чуть «подшаманить» и все.

Пробуйте, дерзайте, у вас точно получится. У нас же получилось!

 

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2016 DEVELOPER.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Поинтегрируем: сервисы интеграции – новый стандарт или просто коннектор?

Обмен между базами 1C Администрирование СУБД Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)

В платформе 8.3.17 появился замечательный механизм «Сервисы интеграции». Многие считают, что это просто коннектор 1С:Шины. Так ли это?

11.03.2024    4527    dsdred    53    

72

Анализируем SQL сервер глазами 1С-ника

HighLoad оптимизация Инструменты администратора БД Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих зааросов на sql, ожиданий, конвертация запроса в 1с и рекомендации где может тормозить

1 стартмани

15.02.2024    7641    158    ZAOSTG    68    

96

Удаление строк из таблицы значений различными способами с замером производительности

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024    5978    doom2good    48    

63

Опыт оптимизации 1С на PostgreSQL

HighLoad оптимизация Бесплатно (free)

При переводе типовой конфигурации 1C ERP/УТ/КА на PostgreSQL придется вложить ресурсы в доработку и оптимизацию запросов. Расскажем, на что обратить внимание при потерях производительности и какие инструменты/подходы помогут расследовать проблемы после перехода.

20.11.2023    8871    ivanov660    6    

76

ТОП проблем/задач у владельцев КОРП лицензий 1С на основе опыта РКЛ

HighLoad оптимизация Бесплатно (free)

Казалось бы, КОРП-системы должны быть устойчивы, быстры и надёжны. Но, работая в рамках РКЛ, мы видим немного другую картину. Об основных болевых точках КОРП-систем и подходах к их решению пойдет речь в статье.

15.11.2023    5105    a.doroshkevich    20    

72

Мигрируем с MS SQL на PostgreSQL

Администрирование СУБД Бесплатно (free)

Переход с MS SQL на PostgreSQL сопряжен с рисками для бизнеса и неизбежно вызывает множество вопросов. Статья посвящена тому, как заранее подготовиться к предстоящей миграции, провести нагрузочное тестирование, выявить возможные проблемы перехода и провести необходимую оптимизацию.

13.11.2023    10821    ivanov660    31    

73

Неочевидный баг Истории данных, убивающий rphost

Администрирование СУБД Платформа 1С v8.3 Бесплатно (free)

Расследование о том, почему команда ИсторияДанных.ОбновитьИсторию() убивала rphost.

08.11.2023    6114    dsdred    48    

72

Начните уже использовать хранилище запросов

HighLoad оптимизация Запросы

Очень немногие из тех, кто занимается поддержкой MS SQL, работают с хранилищем запросов. А ведь хранилище запросов – это очень удобный, мощный и, главное, бесплатный инструмент, позволяющий быстро найти и локализовать проблему производительности и потребления ресурсов запросами. В статье расскажем о том, как использовать хранилище запросов в MS SQL и какие плюсы и минусы у него есть.

11.10.2023    16186    skovpin_sa    14    

98
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
98. Stan 33 30.06.17 12:30 Сейчас в теме
Не совсем понял, какая модель работы СУБД быстрее убьет SSD postgres или mssql? Хотелось бы побольше подробностей.
99. starik-2005 3033 30.06.17 13:08 Сейчас в теме
(98) Если fsync выключите, то точно постгри SSD убивать будет дольше, а вот с fsync неизвестно, но надежность будет выше. И тут спасает репликация.
103. NoRazum 29 11.07.17 18:49 Сейчас в теме
(98)
Если 1с сервер поставить на Линукс то убъёт быстрее полнотекстовый поиск.
УТ 11
25-30 пользователей. Нагрузка на диски создавал сам сервер 1с, а потом postgresql
на рам диск пришлось выкинуть. благо в линукс это проще сделать
100. omut 02.07.17 12:54 Сейчас в теме
Прочитал и, честно говоря, ничего не понял. В том смысле, что не понял, где в статье находится полезная информация. Сплошная реклама в стиле "возможно все, приходите, мы вам покажем". Самое главное: нет анализа в каких конкретно случаях переход на такую загадочную (для меня во всяком случае) конструкцию, как Win+Psgr имеет смысл. ОК, у вас есть специалисты по настройке самой БД, есть специалисты и возможность переписывать код типовых конфигураций. Но почему тогда не перевести БД на linux? Что помешало или какие недостатки у подобного решения?
P.S. используем полностью "традиционное" win-решение для "больших" и "специфических" баз (некоторые в принципе не могут работать под linux. Для разработки и собственных "самописных" есть linux-сервер с postgre. Админам постоянно подкидываю статьи по оптимизации СУБД. Особых изменений не вижу. Вот что реально и грандиозно оптимизирует быстродействие, так это переписывание запросов, алгоритмов в самой 1С. Тут реально куча возможностей для оптимизации. И по текстам запросов, и по серверным вызовам, и по использованию объектной модели. И прирост производительности за счет подобных настроек на 1-2 порядка обычное дело. Но запиливать это именно ради СУБД... ну извините. Это совсем уж нужно быть фанатом-героем. И учитывая стоимость поддержки подобных решений (в течении срока жизни конфигурации/БД), особенное, если конфигураций несколько... Проще взять админа на широко знакомые решения. И проще, и дешевле. Потенциал у решения есть. Но реализовывать его нужно на уровне платформы (1С). Иначе практический смысл теряется. Вот авторы сколько возьмут за повышение производительности моего сервера до (или выше) уровня работы MSSQL? Авторы, вы нереально круты, но вот где ваше место в промышленной эксплуатации того, что есть мне не совсем ясно. ;)
104. nvv1970 13.08.17 00:44 Сейчас в теме
"Нельзя просто так взять и перейти на Постгрес" (С)
Огромное спасибо автору за материал. Безусловно есть крупнейшие применения постгреса, с 1с и не только.
Однако следует вставить пару жирных НО...
На постгрес нельзя просто так перевести любую конфу. Внедрений на автоматических блокировках пруд пруди... Они наверно в еще долго будут в большинстве. ((( И что любопытно, до сих пор продолжают внедряться. Постгрес умрет не приходя в сознание.
На постгрес нельзя просто так взять и сделать "сложный" отчет. Например отчет, успешно работающий на десятках внедрений на точно такой же конфе вдруг вообще намертво виснет при почти отсутствующих данных на постргресе... В чем дело? Ах да... Слишком много соединений виртуальных таблиц (>10 шт). Но MS с этим вообще не заморачивался, а элефант не осилил построить план выполнения запроса. Эпик фейл.
Даже не подлежит сомнению, что все может быть переделано в лучшем виде (код переписан, скуль настроен) и postgres в состоянии утереть нос ms, но какой ценой? Конфигурации должны быть оптимизированы, говнокод не пройдет. Это автоматически обозначает, что 80-90% разработчиков (ниже уровня эксперта) нужно не допускать к проекту на постгресе. Что с ними делать? Увольнять? Не всегда у заказчика есть бюджет на экспертизу и оптимизацию проекта.
А что касается администраторов sql ? Где их взять? С MS худо-бедно все справляются. Да там и из коробки все хорошо, а регламент обслуживания поможет настроить франч-программист. Простая арифметика показывает, что в подавляющем большинстве допрасходы на спеца по постгресу превышают стоимость лицензии ms за год. При этом лицуху можно украсть, а зп админа - нет.
Вот такая жизненная грусть...
105. СергейК 51 13.08.17 14:28 Сейчас в теме
(104)
...Слишком много соединений виртуальных таблиц (>10 шт). Но MS с этим вообще не заморачивался, а элефант не осилил построить план выполнения запроса. ...

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

ПС: Для любопытствующих могу порекомендовать интересную статью про то как UBER с PG на MySql перезжал и подробное повествование причин переезда.
109. starik-2005 3033 15.08.17 00:02 Сейчас в теме
(108)
Для любопытствующих могу порекомендовать интересную статью про то как UBER с PG на MySql перезжал
С учетом того, что в MySQL нет оптимизатора запросов (как некоторые привыкли его понимать).
110. nvv1970 15.08.17 00:06 Сейчас в теме
(109) это статья не касающаяся данного обсуждения)) просто интересная подноготная внутреннего мира СУБД
111. 2tvad 70 11.01.19 13:55 Сейчас в теме
Уважаемые господа, забывают, что за стоимость MSSQL на серьезную конфигурацию, можно купить очень хорошее железо. Сравнивать производительность MSSQL и Postgre на одном железе - нонсенс.

Вы сравните производительность на бюждете. Вот вам 500 000 на ПО + Железо. Давайте сравним =))))
112. starik-2005 3033 11.01.19 14:35 Сейчас в теме
(111)
Вот вам 500 000 на ПО + Железо. Давайте сравним
MS SQL сдох на пентиуме III, купленном на барахолке за полцены.
113. 2tvad 70 11.01.19 15:48 Сейчас в теме
(112)

Ну справедливости ради, можно купить вполне себе хороший БУ сервер за 15-20 тыс. Если вам повезет (как мне) вы купить оборудование из банка который лопнул =)))

HDD я не брал не рискнул. Но сервера очень даже хорошие (от 8 до 12 мес. от даты производства).
Оставьте свое сообщение