PgConf.Russia 2020

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

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

В ходе мастер-класса будет продемонстрировано следующее:

1. Преимущества декларативного программирования. Быстрое создание сложной формы LUI с применением только SQL.
2. Поддержка длинных транзакций и автоматических блокировок. Пример визарда с записью прямо в базу.
3. Управление раскраской данных в полях и столбцах формы. Типичные примеры.
4. Живой поиск в полях ввода на примере ввода адресов.
5. Как настроить LUI на ввод и отображение специфических данных прикладной системы.
6. Разработка формы Мастер-Деталь с извлечением данных из двух разных БД.
7. Как конечный пользователь строит сложные запросы к данным без использования SQL.
8. Как в любом списке группировать данные и строить интерактивные диаграммы (включая 3D) c возможностью “drill down”.

Слушатели по желанию смогут своими руками изготовить WEB-интерфейс для Postgres на LUI (см. презентацию на https://pgconf.ru/2019/118109)

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

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