PostgreSQL не требует лицензионных платежей и официально поддерживается со стороны 1С — но взамен требует внимательного обслуживания. Подбираем параметры под объём памяти вашего сервера, настраиваем репликацию и резервное копирование, оптимизируем медленные запросы, ведём регламент и копии, поднимаем резервный сервер с репликацией, переносим базы с MS SQL и держим PostgreSQL под 1С в рабочей форме.
PostgreSQL действительно устанавливается за несколько минут и сразу начинает принимать подключения. Именно поэтому его часто оставляют в том виде, в каком он приехал из репозитория. А приезжает он с конфигурацией, рассчитанной на то, что запускаться придётся где угодно — в том числе на машине со скромным объёмом памяти. Значения буферов, рабочих областей под сортировки, параметров записи на диск и уборки старых версий строк заданы с большим запасом прочности. На сервере с большим объёмом памяти это означает, что база пользуется малой частью того, за что вы заплатили.
Второе, о чём стоит сказать прямо: PostgreSQL требует более внимательного обслуживания, чем принято думать. Он аккуратно ведёт себя при сбоях и редко теряет данные, но склонен незаметно накапливать мусор — старые версии строк, разросшиеся индексы, устаревшую статистику. Если за этим не следить, база растёт быстрее полезных данных, а запросы постепенно замедляются. Всё это лечится настройкой и регламентом — но кто-то должен их настроить и потом за ними смотреть.
Разворачиваем PostgreSQL и подбираем параметры под объём памяти и дисковую подсистему: буферы, кэш, рабочие области под сортировки и соединения, поведение при записи, лимит подключений.
Отправная точка — сколько на сервере памяти и что ещё на нём живёт.
Настраиваем уборку старых версий строк и её агрессивность, обновление статистики, перестроение разросшихся индексов, контроль размера базы и служебных каталогов.
Настройки уборки по умолчанию отстают от активной базы.
Настраиваем резервное копирование штатными средствами — логические выгрузки и копии на уровне файлов с архивацией журналов, — храним их отдельно и проверяем разворачиванием.
Архивация журналов позволяет вернуться к состоянию до ошибки.
Поднимаем реплику, которая непрерывно повторяет за основным сервером. Её используют как резервный сервер на случай отказа и как площадку для тяжёлых отчётов.
Реплика не заменяет резервные копии: ошибочное удаление повторится и на ней.
Включаем сбор статистики по длительным операциям, смотрим планы выполнения, правим индексы, а то, что не лечится на стороне базы, формулируем разработчикам конкретной задачей.
Ресурсы обычно съедают несколько запросов, а не вся система.
Переносим базы с MS SQL и с других серверов, обновляем PostgreSQL на поддерживаемые версии: тест на копии, окно работ в нерабочее время, возможность вернуться назад.
Старую базу оставляем доступной, пока вы не подтвердите, что всё работает.
Сравнение без религиозных войн: обе СУБД зрелые и надёжные, разница чаще всего в деньгах, экосистеме и в том, кто будет их обслуживать.
| PostgreSQL | MS SQL Server | |
|---|---|---|
| Лицензии | Лицензионных платежей за саму СУБД нет — платите за сервер и обслуживание | Требуются лицензии, стоимость растёт вместе с мощностью сервера |
| Поддержка со стороны 1С | Официально поддерживаемая СУБД, для 1С используются специальные сборки | Поддерживается давно, много накопленного опыта у франчайзи |
| Настройка после установки | Обязательна: значения по умолчанию рассчитаны на скромное оборудование | Тоже нужна, но стартовые значения ближе к возможностям сервера |
| Обслуживание | Нужно следить за уборкой старых версий строк и ростом служебных данных | Нужно следить за фрагментацией индексов и журналом транзакций |
| Операционная система | Живёт и на Linux, и на Windows, привычная среда — Linux | Исторически связан с Windows, что тянет за собой лицензии на неё |
| Когда стоит выбрать | Новый проект, перевод 1С в клиент-серверный режим, сокращение лицензионной нагрузки | Лицензии уже куплены, есть свой специалист или прикладное решение требует именно его |
Мы не переводим на PostgreSQL ради самого перехода. Если лицензии MS SQL уже оплачены, а система работает стабильно, честнее оставить как есть и заняться настройкой того, что имеется.
Клиент-серверный режим 1С без лицензий на СУБД. Здесь есть свои тонкости: для 1С нужна подходящая сборка PostgreSQL, а параметры подбираются с учётом того, как платформа работает с временными таблицами.
Перенос данных — самая понятная часть работы. Сложности обычно возникают там, где приложение опирается на особенности MS SQL, поэтому мы сначала смотрим код и запросы.
Когда простой базы означает остановку работы компании, одного сервера мало. Реплика повторяет изменения за основным и готова принять нагрузку.
Сама СУБД не требует лицензионных платежей — это её главное экономическое преимущество перед MS SQL. Но бесплатной эксплуатация не бывает: остаются сервер, диски, резервное копирование и работа человека, который всё это настроит и будет обслуживать. Экономия реальна, просто она приходится на лицензии, а не на весь бюджет.
Да, это официально поддерживаемая со стороны 1С СУБД, и для многих компаний она стала основным вариантом клиент-серверного режима. Нюанс в том, что для 1С применяются специальные сборки, а параметры нужно подбирать с учётом того, как платформа работает с временными таблицами. Подробности — на странице сервера 1С.
Для 1С это довольно отработанная процедура. Для собственных приложений сложность определяется кодом: если он использует специфичные для MS SQL конструкции и хранимые процедуры, их придётся переписывать. Поэтому мы начинаем не с переноса, а с оценки — и говорим, во что обойдётся переход, до того, как вы примете решение.
Обычно это накопившиеся старые версии строк и разросшиеся индексы: фоновая уборка не справляется с темпом изменений. Лечится настройкой параметров уборки, перестроением проблемных таблиц и индексов, а иногда — пересмотром того, как приложение обновляет данные. После приведения в порядок база часто заметно уменьшается.
Это разные вещи. Копии защищают от потери данных и от ошибок людей, репликация — от простоя при отказе сервера. Если компания может позволить себе паузу на восстановление, достаточно копий. Если остановка базы означает остановку продаж или производства, нужен резервный сервер, и копии при этом всё равно остаются обязательными.
Да, это обычная ситуация. Начинаем с осмотра: версия, конфигурация, состояние обслуживания и копий, журналы ошибок. Дальше сначала закрываем то, что грозит потерей данных, потом занимаемся скоростью. Если найдём решения, с которыми не согласны, объясним причину, а не просто перенастроим по-своему.
Расскажите, какая версия, какого размера база и что беспокоит. Посмотрим конфигурацию, замерим узкие места и предложим план.
PostgreSQL заслуженно считается зрелой и надёжной СУБД: он давно развивается, аккуратен с данными и не преподносит сюрпризов при сбоях. Но у его устройства есть особенности, о которых лучше узнать заранее, а не в момент, когда база выросла втрое без видимых причин.
Значения в базовом конфигурационном файле подобраны так, чтобы PostgreSQL запустился на любой машине. Под кэш выделяется скромный объём, рабочая память под сортировки и соединения задана минимально, планировщик по умолчанию исходит из осторожных предположений о скорости дисков. На сервере с быстрыми дисками и большим объёмом памяти это приводит к тому, что база лишний раз обращается к диску и выбирает не лучшие планы запросов. Правильные значения зависят не от «рекомендованных таблиц из интернета», а от того, сколько памяти на сервере, что на нём ещё работает и какого характера нагрузка.
При изменении строки PostgreSQL не переписывает её на месте, а создаёт новую версию — это то, что позволяет читателям не мешать писателям. Устаревшие версии убирает фоновый процесс, и на активной базе он вполне может не успевать. Тогда файлы данных и индексов раздуваются, чтение замедляется, а место на диске уходит непонятно куда. Настройка агрессивности уборки под конкретную нагрузку — одна из первых вещей, которые мы делаем на нагруженных базах.
Резервный сервер с репликацией спасает от отказа оборудования, но не от ошибки человека: удалённые по ошибке данные исчезнут и на реплике, причём почти мгновенно. Поэтому репликацию мы всегда сочетаем с обычными резервными копиями и архивацией журналов транзакций — это то, что позволяет вернуть базу к состоянию на момент до неверной команды, а не только поднять её после сгоревшего диска.
Платформа 1С активно использует временные таблицы и генерирует специфические запросы, поэтому её сочетание с PostgreSQL требует отдельного внимания: подходящей сборки СУБД, аккуратной работы с памятью и настроенных регламентных заданий на стороне 1С, а не только на стороне базы. Ускорение здесь почти всегда результат совместной настройки, поэтому мы разбираем такие задачи вместе с сервером 1С целиком, а не отдельно взятую СУБД.
Каждая ветка PostgreSQL со временем перестаёт получать исправления, и однажды нужная функциональность или требования прикладного софта заставят обновляться в спешке. Плановое обновление устроено иначе: копию базы разворачивают на новой версии, прогоняют реальные отчёты и операции, сверяют поведение запросов и только потом назначают окно переключения — с сохранением возможности вернуться на прежнюю версию.
Если база обслуживает интернет-магазин, производство или учёт, за ней стоит наблюдать непрерывно: место, длительность запросов, успешность копий, состояние реплики. Настроить это один раз недостаточно — показатели меняются вместе с данными. Такую работу мы ведём в рамках обслуживания баз данных, где PostgreSQL живёт рядом с остальными СУБД компании и общим мониторингом.
