Доклады

Современные архитектуры Data Lakehouse обещают передовую производительность, но скрывают один неудобный секрет. Чтобы гарантировать ACID-транзакции поверх объектных хранилищ, форматам вроде Apache Iceberg приходится опираться на внешние сервисы-каталоги, которые под капотом всё равно используют классические реляционные СУБД. Это приводит к масштабному разрастанию инфраструктуры, заставляя инженеров поддерживать избыточные слои абстракций. В ответ на этот парадокс авторы DuckLake Manifesto предложили элегантное решение: использовать саму базу данных как нативный каталог и хранилище метаданных. В этом докладе мы проследим эволюцию аналитики от классических DWH до Lakehouse и разберем, как строить такие системы с помощью открытых расширений PostgreSQL. Мы представим Postgres Pro AXE — быструю, надежную и DuckLake-совместимую платформу — и погрузимся в ее технологические решения.

OpenTelemetry становится стандартом для сбора телеметрии, но как применить его к PostgreSQL в production? В этом воркшопе мы разберем pgpro-otel-collector — готовый, мощный и "бесшовный" сборщик метрик и журналов от PostgresPro. Мы не будем останавливаться на теории. На протяжении сессии вы на практике развернете полноценный стек мониторинга: от настройки агента на сервере СУБД до получения наглядных дашбордов в Grafana. Вы узнаете не только "как сделать", но, "на что смотреть в первую очередь" и "как интерпретировать данные". Для кого этот воркшоп. Для администраторов PostgreSQL и системных администраторов, которые хотят перейти от теорий и общих концепций Observability к готовой, работающей системе мониторинга своей СУБД. Чему вы научитесь: 1. Понимать архитектуру: Зачем нужен otel-collector и какие у него преимущества. 2. Настраивать сбор данных: Интеграция с PostgreSQL/PostgresPro для сбора метрик (активность, ожидания, репликация, использование ресурсов) и структурированных журналов (логов). 3. Строить pipeline: Направление потока метрик в VictoriaMetrics (Prometheus-совместимое хранилище), а логов — в VictoriaLogs. 4. Визуализировать и анализировать: Создание информативных дашбордов в Grafana для оперативного контроля и глубокого анализа проблем (ожидания, медленные запросы, аномалии нагрузки). Формат и практическая польза. Это интенсивный воркшоп. Каждый участник получит возможность развернуть окружение и шаг за шагом пройти путь от нуля до работающей системы, на каждом шагу разбирая конфигурационные файлы, ошибки и best practices. К концу сессии у вас будет готовый, переносимый конфигурационный набор и четкое понимание для его адаптации в своей инфраструктуре. Требования к участникам: Базовый опыт администрирования PostgreSQL и знакомство с основами Linux и Docker. Желательно (но не обязательно) общее понимание концепций Prometheus и Grafana.

Мастер-класс включает в себя теорию, демонстрацию и самостоятельные практические упражнения на виртуальной среде (170 минут) Слушатели узнают: - как найти неоптимальные запросы, выполняющиеся в СУБД в текущий момент - как вручную управлять планом запроса - как зафиксировать план запроса для использования в будущем - как настроить автоматическое адаптивное выполнения запросов по триггерам - как использовать адаптивную оптимизацию запросов на основе машинного обучения - о недавних изменениях в функционале

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

 - Новое расширение auto_dump

- Доработку алгоритма, ускоряющая ANALYZE для "широких" таблиц

- Пропуск инвалидации и других операций для временных таблиц

- Новый тип статистики - мультиколоночную статистику

- Хранение данных небольших временных таблиц в памяти

- Теневой системный каталог для метаданных

Мы много лет занимаемся разработкой бекенда на Java и Postgresql За это время мы видели много проектов. Разработчики разные, а проблемы одинаковые. Так получается из-за того программисты представляют себе Postgresql как черный ящик, который просто работает, а на самом деле у Постгреса есть внутренняя структура, подробности которой неплохо бы понимать. Мы расскажем о том, к чему приводит непонимание разработчиками того, как работают базы данных, к каким проблемам это приводит и как писать код, чтобы эти проблемы не возникали. И заодно возможно покажем специалистам по базам данных, почему часто код джава разработчика выгляди так, как будто он писал его с закрытыми глазами. База данных это не просто так, надо понимать как она работает. Хотя бы немного.

Odyssey - масштабируемый и производительный пулер соединений для PostgreSQL, предназначенный для использования в крупных инсталляциях, подобных тем, что разворачивают в Yandex Cloud.

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

Привычное многим разделение нагрузки на OLTP и OLAP, кажется, даёт исчерпывающую классификацию. На практике, однако, между чёрным и белым есть ещё много интересных оттенков. И в нашем случае это запросы, имеющие черты обоих сценариев. Я расскажу, с какими запросами мы часто имеем дело, какие вызовы они приносят, и — самое главное — как их можно оптимизировать.

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

Описание: 

Описание:

1. Как PostgreSQL хранит данные на диске? 

2. Что такое форки, бэкенды и процессы в PostgreSQL?

3. Что такое буферный кэш и почему страницы там пачкаются?

4. Какие бэкенды могут записывать страницы на диск?

5. Как и где работает CFS?

6. Почему в CFS нужно убирать мусор и какие бэкенды этим занимаются?

7. Что такое физические и логические резервные копии?

8. Зачем еще нужно хранить архив WAL?

9. Что происходит с PostgreSQL и CFS, когда вы начинаете делать резервную копию?

10. Почему возникали проблемы при снятии бэкапов с CFS?

11. Как бы эти проблемы решили?

12. Что еще оптимизировано в связке pg_probackup + CFS?

13. Можно ли делать резервные копии другими инструментами?

14. Что такое TDE и можно ли использовать его совместно с CFS?

Если купить много-много лотерейных билетов — можно выиграть водокачку. А если эксплуатировать много-много баз разными-разными способами можно выиграть коррупцию. В 99% сам виноват сам себе злобный буратино, fsync крутил не туда, или pg_resetwal запустил не с теми параметрами, libc обновил с наскоку. Но, вообще, бывает правда в Postgres ошибочка вышла. Надо чинить. Вот об этом расскажу.

Мы разрабатывали модуль распределённого управления настройками в крупной системе. Согласно требованиям, приложение запускалось в нескольких экземплярах (pods) с использованием одного экземпляра Postgres. При внесении изменений на любом из подов остальные должны оперативно получать уведомление. Ещё одно требование — использовать существующую инфраструктуру системы, которая не включала брокер с режимом fanout. Выход был найден — для синхронизации решили использовать... Postgres! Расскажу, что конкретно мы сделали с примерами кода бэкенда.

Системные пакеты DBMS_XMLDOM, DBMS_XSLPROCESSOR и другие для обработки XML-данных — одна из типичных сложностей при миграции процедурного кода из Oracle в PostgreSQL. В докладе рассмотрим, как при помощи одного лишь расширения plv8 можно написать (почти) полный аналог системных пакетов DBMS_XMLDOM, DBMS_XSLPROCESSOR из СУБД Oracle. Рассмотрим возможности этого расширения и расскажем, как его можно применить для запуска готовых библиотек (не только JavaScript).

Когда вы знакомитесь с документацией по какой-то системе в части базы данных, то обычно характер нагрузки определяется исходно в архитектуре проекта. Но если система определена архитектором как OLTP, но в действительности может вести себя в некоторые периоды времени как OLAP. Нормально ли такое поведение, и каким образом мы можем определить фактический профиль системы именно сейчас? Для чего это нужно? Прежде всего для диагностики наличия проблем в системе. Возможно, система была изначально задумана именно с таким смешанным поведением, и архитектор сообщит о допустимости таких отклонений. Но если этого быть не должно, и вы имеете профиль нагрузки отличный от того, что должно быть – это может говорить о том, что где-то мы просчитались... Возможно, недостаточно ресурсов для работы БД, где-то нет нужных индексов или потребуются архитектурные изменения: нормализации/денормализации или секционирование. Так же я хотел бы показать, в чем особенности других профилей нагрузки. Например, если База Данных переведена в Архив, но выясняется, что в действительности ведет себя как скрытый ПРОД и активно используется. Как это выявить по метрикам?

Расширение Apache Age позволяет хранить графы и выполнять запросы cypher внутри PostgreSQL, совмещая реляционную и графовую модели. Насколько это решение готово к реальным нагрузкам? В докладе поделимся результатами нагрузочного тестирования Apache Age. О чем пойдет речь:

•   производительность чтения и записи при росте объема данных
•   планы выполнения запросов и особенности работы планировщика
•   влияние хранения свойств вершин и ребер в jsonb на точечные и диапазонные запросы
•  архитектурные ограничениям текущей версии Apache Age

Отдельно остановимся на том, какие workarounds сейчас существуют и в каких сценариях Apache Age уже можно использовать, а где его применение пока сопряжено с рисками. 

Доклад будет полезен инженерам PostgreSQL и командам, рассматривающим графовые модели в СУБД.

Классическая ситуация: в часы пик база данных захлебывается, CPU загружен на 100%, диски простаивают, а в топе запросов висит «мелочь». Привычный мониторинг бессилен: ни долгих транзакций, ни тяжелых выборок, ни очевидных блокировок. Истинная причина просадки остается невидимой Иногда виновником оказываются «горячие блоки». Проблема возникает, когда множество процессов одновременно конкурируют за доступ к одному и тому же блоку. Данные находятся в кэше и читаются быстро, но механизмы защиты памяти не рассчитаны на такой ажиотаж. В итоге время тратится не на полезную работу, а на борьбу за право доступа к странице. Стандартные инструменты Postgres не позволяют локализовать проблему до конкретного объекта базы данных, ставшего узким горлышком. В этом докладе я расскажу: 1. Как возникают «горячие блоки» и почему стандартный мониторинг слеп к этой проблеме; 2. Как я написала собственное расширение, чтобы заглянуть «под капот» базы и увидеть скрытую механику работы с памятью; 3. Как найти таблицу-виновника за пару минут и спасти производительность.

В архитектуре «PostgreSQL для OLTP + ClickHouse для OLAP» команда неизбежно сталкивается с фрагментацией: разные подключения в BI, разные диалекты SQL, ручные JOIN между системами через ETL и дублирование витрин. В докладе разберём практический опыт EGAR по внедрению расширения pg_clickhouse — PostgreSQL extension/FDW, который позволяет выполнять аналитические запросы на ClickHouse прямо из PostgreSQL с поддержкой pushdown (WHERE/JOIN/AGG и др.) и прозрачным подключением для BI-инструментов. Покажу архитектуру, принципы pushdown, типовые сценарии (профиль компании, отрасли, регионы, скоринг), а также ограничения и «правила безопасного применения»  (как проверять pushdown через EXPLAIN/ANALYZE, как выбирать витрины, где эффект максимален). В результате — единая точка входа в данные и ускорение дашбордов с десятков секунд до нескольких секунд на больших объёмах.

Что общего между репликой, которая внезапно зависает в ожидании IPC/MultixactCreation, и командой MERGE, которая генерирует дублирующиеся значения? Оба случая — это редкие, но критические баги в PostgreSQL, которые годами оставались незамеченными. И оба были обнаружены одной командой инженеров, которые просто запустили синтетические тесты на своей инфраструктуре. В этом докладе пойдет рассказ о том, как мы столкнулись с необычными проблемами при использовании PostgreSQL 17, какие методы использовали для их воспроизведения, и как наши отчеты привели к крупным исправлениям в коде PostgreSQL:

1. Некорректные обновления в MERGE: Как команда MERGE в конкурентной среде могла генерировать дублирующиеся значения, нарушая монотонность последовательностей, и почему эта проблема была связана с неправильным использованием TM_FailureData.

2. Проблема с multixact на standby-сервере: Как репликация начинала зависать при высокой нагрузке с генерацией multixact ID, и почему это было связано с редким "corner case", который существовал потенциально с момента введения multitransactions.

Для кого: DBA, разработчики приложений с высокими требованиями к надежности, участники сообщества PostgreSQL.

"Бизнес-логика в базе данных - это антипаттерн". Эта мантра передаётся разработчиками из поколения в поколение уже более 20 лет. Причины очевидны: реляционные СУБД плохо масштабируются, а реализовывать сложную бизнес-логику с их помощью неудобно и немодно. Однако у такого подхода есть и сильные стороны: мощь и выразительность языка SQL (и его процедурных расширений при необходимости), а также возможность выполнять вычисления прямо не отходя от данных. Кроме того, в последние годы правила игры начали меняться - особенно с популяризацией распределённых реляционных СУБД и AI-агентов. В докладе попробуем ответить на вопрос: действительно ли бизнес-логике не место в базе данных - или это устаревший архитектурный догмат?

Новые возможности отказоустойчивого кластера Postgres Pro BiHA.

«Алгоритмы + Структуры данных = Программы», сказал почти полвека назад Николаус Вирт и актуальность этого утверждения только нарастает. Postgres — это не только таблицы, массивы и JSON. Набор структур данных и подходов к их организации и использованию, которые могут пригодиться разработчику, гораздо шире. В докладе рассматриваются некоторые структуры данных Postgres и приёмы работы с ними: от самых компактных - битовых структур в стиле Си или типа bit(n), до коллекций из вложенных сложных типов и кустарной кластеризации данных. В докладе, как обычно, много работоспособных примеров на SQL или PL/pgSQL.

Представьте, что у вас есть огромная активная база, живущая без резервной копии... И внешние силы, которые вручную удаляют старые "ненужные" файлы и аварийно останавливают сервер БД. Вроде бы вполне привычная история, но стандартные методы диагностики не работают, попытка воспользоваться pg_dump приводит к зависанию.

Неужели это точка невозврата?

• Какими инструментами мониторинга можно воспользоваться, когда ничего не помогает: gdb, crash_info...

• Плюсы работы с open source: хакнуть код pg_dump ради всеобщего блага!

Увлекательная история о том, как мы помогали спасти данные в экстренных условиях.

Всем известно, что самый быстрый способ сделать обновление кластера PostrgeSQL на новую версию — это воспользоваться либо логической репликацией, если база данных у вас небольшая, либо использовать утилиту pg_upgrade. Однако, у обоих есть недостатки: первый способ требует первоначальную переливку данных, что сильно влияет на работающий публикатор, второй способ почти никак не подходит, если у вас база данных содержит больше десяти тысяч таблиц. Нужен какой-то комбинированный способ. С 17 версии PostrgeSQL появился такой способ — это использовать pg_createsubscriber. Но как быть, если у вас версия PostrgeSQL младше 17 версии. О таком подходе я и расскажу в докладе, также покажу, как мы сделали большое обновление с десяток серверов с суммарным количеством таблиц больше 10 миллионов.

Провел сравнительное исследование поиска подстроки разными способами с использованием разных индексов и подходов к хранению. Хочу поделиться результатами.

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

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