Доклады

Два года назад я рассказывал про запросы на получение данных — здесь библиотека LINQ to DB дает почти неограниченные возможности.
Этот доклад — об операциях модификации данных. LINQ to DB позволяет выполнять запросы UPDATE + JOIN, INSERT FROM SELECT, поддерживает оператор MERGE, блокировку на уровне строк SELECT FOR UPDATE, создание временных таблиц, имеет механизм скоростной вставки больших объемов данных.
Также расскажу про проект linq2db. EntityFrameworkCore — решение для тех, кто не готов уходить с EF Core и при этом хочет получить возможности LINQ to DB. Поделюсь опытом внедрения LINQ to DB в крупный проект.

Консолей администратора существует множество — от старорежимного DBeaver до всепроникающего pgAdmin. Тем не менее, мы решили сделать ещё одну. Зачем?

Из доклада вы узнаете:

— Как одна инсталляция может обслуживать несколько десятков тысяч экземпляров БД 

— Сколько пользователей может поддержать консоль 

— Как провести инвентаризацию инфраструктуры и не сойти с ума

— Как вписаться в привычное окружение, не заставляя переделывать всё с нуля

— Как построить модель безопасности, чтобы тебе доверяли ведущие банки и телеком-операторы

— И наконец — как потрогать всё это руками

Многие разработчики часто сталкиваются с проблемами производительности разрабатываемых систем. Одно из распространенных решений для оптимизации медленного бизнес-процесса — его распараллеливание. Однако что делать, если узким местом становится вставка данных в БД, требующая сохранения своей атомарности?

В докладе расскажу, как можно ускорить вставку данных при помощи распараллеливания этого процесса в Spring, а также как сохранить атомарность всей операции. Затронем batch update в Spring и PostgreSQL, обсудим, почему обновление — это тяжелая операция и как можно ускориться в текущем технологическом стеке. Кроме того, рассмотрю другие подходы к сохранению атомарности и покажу различия между ними в бенчмарках.

Будет полезно практикующим инженерам.

С собой необходимо иметь ноутбук! 

На мастерклассе будет показано как горизонтально масштабировать данные на примере базы Авиаперевозок (https://github.com/hettie-d/postgres_air)  с использованием sharman-а. Преимущества и недостатки различных подходов.
Требования к участникам

    Базовые знания linux
    Базовые знания postgresql
    Написание простых запросов
    Чтение планов запросов
    Умение запустить pgbench
    Знание команды copy

Проблема долгого закрытия месяца и расчета себестоимости на PostgreSQL остро стоит давно. В ходе доклада рассмотрим, что нам предлагают современные версии PostgreSQL в этом плане, а также ответим на вопрос: «Тормозят ли реплики работу мастера?».

Посмотрим в этом разрезе на разные типы физической репликации и на десерт посмакуем рецепт быстрого, безболезненного закрытия месяца в 1С без влияния на оперативную работу пользователей.

Расскажу, какие трудности будут на вашем пути, если захотите реализовать новый TableAM. Что выбрать: Generic XLog или Custom RMGR? Зачем Custom SMGR? Как подключить постгресовые аллокаторы в стороннюю либу, даже если она этого вообще не поддерживает? Чего не хватает для колоночного движка (в том числе про векторизацию и позднюю материализацию) и как обойти ограничения?

Во второй части расскажу о внутренностях pgpro_tam — нового нативного табличного движка для OLAP, который поддерживает общепринятые форматы данных, различные SMGR, а если потребуется, то и сторонние планировщики и движки исполнения, находясь в рамках ACID. Всё это для получения самой быстрой аналитики на Postgres (не просто прикрутить DuckDB).

Карта видимости в PostgreSQL — это важный механизм для оптимизации работы с базой данных, который ускоряет операции чтения, очистки данных и индексации. Несмотря на некоторые ограничения, такие как потребление памяти и фрагментация, её использование позволяет значительно повысить производительность в высоконагруженных системах. Эффективное использование карты видимости требует правильной настройки и мониторинга, что особенно важно в системах с большим объёмом данных и высокой параллельностью транзакций.

Проведем обзор возможностей утилиты резервного копирования pg_probackup3. 

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

НЕОБХОДИМО С СОБОЙ ИМЕТЬ НОУТБУК! Мастер-класс по созданию и конфигурированию отказоустойчивого кластера BiHA.

Столько слов было сказано о PostgreSQL как о результате работы его программного кода. Но Postgres — это не только код. Это люди, которые его создают, развивают и... Оставляют в нём частичку себя через комментарии.

Какие истории нам могут рассказать комментарии к коду PostgreSQL? Узнаем, какое слово самое популярное, какие комментарии остались в коде с самого первого публичного коммита,  как меняется стиль общения с развитием продукта и как за строчками кода и комментариев увидеть человека.

В этом докладе я буду ломать архитектурные стереотипы о недопустимости коммуникации с внешним миром прямо из СУБД. PostgreSQL обладает огромными коммуникационными возможностями, просто нужно знать, какие расширения использовать.

А когда расширений не хватает — можно написать своё. Для проекта Luxms BI нам понадобилось общение с NATS, и мы создали своё расширение на языке Rust. Поделюсь ссылкой на GitHub и впечатлениями о разработке расширения для PostgreSQL на Rust в этом докладе.

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

При переходе с Oracle и других проприетарных систем на PostgreSQL разработчикам приходится адаптировать существующую кодовую PL/SQL-базу под PL/pgSQL. Несмотря на сходство этих двух процедурных языков, значительные различия в их синтаксисе, характеристиках производительности и особенностях экосистемы требуют продуманного подхода к миграции и оптимизации.

В этом докладе сфокусируемся на ключевых различиях между PL/SQL Oracle и PL/pgSQL PostgreSQL, поделимся инсайтами о том, как эффективно адаптировать код во время миграции. 

Особое внимание уделим следующим аспектам:

• Методология компиляции
• Отладка кода
• Обработка исключений
• work_mem
• Массовая загрузка данных

В прошлом году мы сделали встроенную поддержку отказоустойчивости в Postgres Pro Enterprise — BiHA. Наше решение позволяет разворачивать отказоустойчивый кластер Postgres, в котором в случае сбоя пишущего узла новый пишущий узел (лидер) будет выбран автоматически.

При этом возникает проблема перенаправления трафика на нового лидера. Её можно решить с помощью нашего расширения Proxima или внешнего TCP-прокси сервера. И первое, и второе решение были вынуждены периодически опрашивать кластер BiHA для определения пишущего узла.

Как альтернатива, в новой версии BiHA появилась возможность зарегистрировать пользовательские функции, которые будут вызваны при возникновении таких событий в кластере, как смена лидера, добавление/удаление ноды и других. Этот механизм мы назвали пользовательские колбэки. В докладе мы расскажем, как реализованы колбэки и обсудим особенности их использования

Небольшой доклад про различные расширения, которые помогут при оптимизации.

Иногда возникают проблемы работы СУБД в ОС Linux. Определим классификацию таких сценариев и пути решения от простых до сложных. Какие сбои приводят к порче данных? Какие сценарии опаснее других, и на что стоит обращать внимание, мониторить? Рассмотрим примеры логирования в МБД.П Скала-Р и разберем сценарии отладки состава библиотек ОС, ядра Linux, драйверов и модулей ядра для поиска причин ошибок и их устранения.

Какой способ выборки данных в PostgreSQL работает быстрее: несколько простых SQL-запросов, ORM (Hibernate, jOOQ) или единый запрос с JSON-агрегацией? В этом докладе мы разберём несколько стратегий извлечения данных, сравним их производительность и обсудим подводные камни. Рассмотрим, как ORM-инструменты (Hibernate, jOOQ) справляются с one-to-one- и one-to-many-связями, какие накладные расходы возникают при использовании JOIN'ов, и почему выборка в JSON-формате может оказаться самым эффективным решением. Реальные бенчмарки, плюсы и минусы каждого подхода — всё это в нашем исследовании.

С СОБОЙ НЕОБХОДИМО ИМЕТЬ НОУТБУК! 1. Интеграция с Haproxy 1.1 Опрос с помощью скриптов валидации 1.2 Изменение конфигурации с помощью функций-обработчиков 2. Резервное копирование с помощью pg_probackup 2.1 Настройка копирования с выделенного узла 2.2 Восстановление лидера по резервной копии ведомого 2.3 Восстановление любого ведомого узла 2.4 Восстановление при сбое всего кластера

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

Доклад, скорее всего, будет интересен сетевым провайдерам, которые к своим крутым фичам могут добавить что-то в синтаксис, чтоб упростить администрирование, а также всем, кто интересуется машинным обучением. Будет рассмотрен механизм разбора SQL, что, где и как поменять, чтобы внедрить новые синтаксические конструкции. Также продемонстрирую возможности машинного обучения на табличных данных не выходя из базы с использованием нового синтаксиса.

Обсудим, что такое кодировки и сортировки. Расскажу о проблемах, которые могут быть вызваны сортировкой (COLLATION) в базах данных, и представлю, как эти проблемы можно решить с помощью COLLATION PROVIDER = ICU.

Мастер-класс с демонстрацией работы pg_probackup3

Уже больше года в выпусках Postgres Pro доступны расширенные статистики вакуума, которые отражают его работу на уровне отдельных отношений.

 К нам начали попадать наблюдения, полученные на «боевых» базах клиентов с этими статистиками. Получилось удачно, в 2024 году мы активно начали продвигать статистики вакуума в PostgreSQL, а пока на примере данных, полученных с «живых» систем, рассмотрим, что могут рассказать нам эти статистики о непростой жизни вакуума.

Greenmask — это open source утилита для анонимизации баз данных и генерации синтетических данных. Классическая задача в разработке — создание тестовых окружений, которые максимально похожи на продакшен. Рассмотрим, как можно применить различные фичи Greenmask для подготовки тестового контура без боли. Обсудим его архитектуру, database subset, типы трансформаций, причины интеграции с драйвером PostgreSQL и портирования некоторых pg-библиотек. Обсудим, как наша технология позволяет бизнесу решать проблемы быстро, качественно и безопасно.

Although we often don't like to talk about it, database administration carries with it a large amount of stress. This is particularly true when we have to take on late night support duties. In this talk you will learn: 1. The basics of the physiology of stress. This is not a physiology lecture, but as engineers we need enough to build a mental model. 2. What kinds of mistakes we make when under stress. 3. How to measure stress in your own life and recognize it in others. 4. What tools are helpful to manage short- and long-term stressors. Managing short-term stress is important in avoiding becoming overwhelmed when problems occur, but managing longer-term stressors is just as important in avoiding problems in the first place.

В центре внимания — проблемы построения прикладного решения на PostgreSQL, а именно высоконагруженного аналитического хранилища данных. На примере кейса компании ЕВРАЗ покажем эффект применения методологии Data Vault на СУБД PostgreSQL и Greenplum для разработки единой системы производственных показателей.

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

Это будет интересно всем, кто планирует использовать или уже сталкивается со сложностями применения методологии Data Vault и проблемами производительности DWH на стеке open source. Сравним варианты технической реализации модельного слоя business vault с учётом специфики PostgreSQL и Greenplum. Рассмотрим 5 реальных проблем, возникающих при эксплуатации DWH и их решение:

1.     Перенос логики сборки объектов Business Vault с PostgreSQL на Greenplum.

2.     Замедление ETL при сборке текущего состояния Business Vault в PostgreSQL.

3.     Замедление построения Data Lineage в PostgreSQL и Greenplum.

4.     Медленная работа при запросе сателлита в Greenplum.

5.     Медленные запросы с «in» или «or» при обращении к слою Business Vault.

Внесение изменений в таблицы под «боевой» нагрузкой — это всегда нетривиальная задача. Например, если нужно сменить тип колонки (int —>bigint, timestamp —> timestamptz) или переместить таблицу в другой tablespace, не потеряв изменения, которые происходили во время переливки данных.

А если таких таблиц сотни? С pg-transparent-alter-table это больше не проблема, и такие задачи решаются одной простой командой: $ pg_tat -h 0.0.0.0 -d mydb -c "alter table mytable alter column id bigint"

Возможности:

— можно указать любое количество команд alter table за раз; 

— можно менять партицированные таблицы, поддерживается старый механизм через наследование, новое декларативное партицирование, многоуровневое партицирование; 

— можно прервать выполнение на любой стадии и продолжить позже, не теряя прогресс предыдущих стадий;

— можно в любой момент передумать, остановить выполнение, выполнить "pg_tat --clean" и вернуться к первоначальному состоянию; 

— есть кастомная команда смены порядка колонок; 

— поддержка версий PostgreSQL 11–17.

За более чем 5 лет существования (раньше назывался transparent-alter-type) проект стал надежным инструментом, который активно используется в продакшене. Хочу поделиться опытом и рассказать про его возможности.

В докладе на примере реального проекта рассматриваются проблемы миграции прикладной системы из среды Oracle в Postgres. Подробно освещена логическая репликация данных из Postgres для обеспечения возможности возврата обратно на Oracle и поддержки работоспособности старой отчётности и интеграции.

Работа DBA бывает очень многогранной: бэкапы, обновления версий, проблемы с производительностью, — перечислять можно долго. Но иногда из-за занятости мы не обращаем должного внимания на нововведения, которые не относятся напрямую к тому, что мы делаем каждый день. Так получилось и с логической репликацией.

Конечно, каждый из нас обладает какими-то навыками работы с этим инструментом, но PostgreSQL — очень динамично развивающаяся СУБД. И иногда нужно просто посмотреть вокруг свежим взглядом — можно увидеть что-то новое.

На этом и будет основан мой доклад: мы начнём с теории (как всегда, подход — меньше теории, больше практики) и простых примеров, затем перейдём к более сложным примерам работы. Обратим особое внимание на то, что изменилось в современных версиях PostgreSQL.

Доклад будет полезен тем, кто хочет познакомиться с логической репликацией или обновить свои знания по этому инструменту.

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

Эти проблемы касались поддержки автономных транзакций, пакетных переменных и ряда других особенностей. В чём особенность pg_settings? Почему нам необходимы именно автономные транзакции и причём тут HOLD-курсоры? Это и многое другое мы расскажем в нашем докладе, а также поделимся своим опытом внедрения Postgres Pro Enterprise.