Мастер-класс настройки PostgreSQL для 1С

Вас ждёт увлекательное путешествие по настройкам PostgreSQL. Мы поговорим о том что с 1С не так или наоборот так, что под неё надо специально настраивать СУБД. Обсудим подходы к тестирования скорости работы 1С. Рассмотрим различные варианты схем резервного копирования и обеспечения отказоустойчивости. В процессе мы сравним скорость работы 1С на PostgreSQL настроенном по умолчанию со скоростью работы на настроенном для 1С PostgreSQL. Так же мы создадим реплику PostgreSQL, и переключим на неё Сервер 1С "на живую", посмотрим что увидят пользователи 1С при этой операции. И отдельный блок будет посвящён PostgresPro Enterprise Edition, как использование его приемуществ влияет на скорость работы 1С.

Опыт плавной миграции высоконагруженного проекта (20+ млн. пользователей) c MySQL на PostgreSQL

Небольшая история о том, как переход на PostgreSQL увеличил на порядок эффективность работы компании:

1. Программный код сократился в 50 раз, в команде разработки бэкенда вместо 15 человек осталось трое
2. Сроки разработки нового функционала стали измеряться днями, а не месяцами
3. Стоимость владения в расчете на 1 млн. пользователей снизилась в 20 раз
4. Структура данных и документация существенно упростилась: вместо 100 тыс. таблиц со сложными связями стало 20 простых таблиц
5. Повышение безопасности системы за счет запрета внешних SQL команд к базе данных
6. Быстрый сбор аналитики по ключевым параметрам
7. Без остановки работы бизнеса

PostgreSQL cluster высокой доступности под управлением Patroni для 1С. Единая точка входа организована Consul DNS на Windows.

200 баз, несколько кластеров, несколько терабайт данных Поделимся своим опытом настройки и использования patroni cluster Кластер СУБД под Linux, сервер 1С под windows. Используем: Сборка PostgreSQL для 1С, Patroni, Consul, Consul dns, Commvault, Ansible Vagrant файл и Ansible playbook c ролями прилагается.

GraphQl-бэкенд на PostgreSQL и plv8

Недавно мне пришлось поработать над проектом, где для запросов к бэкенду на .NET Core использовали GraphQl, о чём потом пожалели. Дело в том, что GraphQl-запрос представляет собой объект с динамическим набором полей и иерархией любой вложенности. Обрабатывать такие объекты на языке со статической и сильной типизацией, да ещё и через ORM, как это предлагают библиотечные решения – очень неудобно. И тогда мне пришла идея использовать plv8 и разбирать запросы в формате GraphQl прямо на стороне БД. За пару часов я написал работающий прототип, реализующий функционал, который разрабатывали более месяца! Затем было сделано несколько усовершенствований, всё это я собираюсь показать. Тем, кто собирается в своих проектах использовать GraphQl, а не REST, информация из данного доклада может особенно пригодиться и возможно поможет сэкономить уйму времени.