PGConf.Russia 2025

Каждый день тысячи инженеров прилагают нечеловеческие усилия, чтобы сделать наши данные более достоверными, точными и актуальными. Однако, иногда необходимо поступить наоборот — испортить их. 

Например, скрыть или заменить чувствительные данные, а иногда даже сгенерировать их с чистого листа, сохранив при этом бизнес-свойства данных. Это может понадобиться для тестирования систем, передачи данных третьим лицам и в других случаях. И, оказывается, это тоже достаточно сложная задача (учитывая сложность схемы данных и нетривиальные бизнес-требования).

В докладе рассмотрим основные проблемы искусственных данных и попробуем их решить разными способами, используя встроенные возможности PostgreSQL и сторонние расширения

Два года назад я рассказывал про запросы на получение данных — здесь библиотека 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 в крупный проект.

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

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

На одном из моих прошлых мест работы мы довели ElasticSearch до предела его возможностей. Нам потребовалась еще более масштабируемая альтернатива для системы с высокой нагрузкой на запись и редкими чтениями. Мы построили такую систему на PostgreSQL. Теперь многие из нас работают над ее преемником как над опенсорсным проектом.

Этот доклад расскажет о дизайне Bagger (названного в честь гигантских горнодобывающих машин), который способен управлять логами объёмом в десятки и сотни петабайт. Помимо обзора архитектуры, расскажем о причинах выбора решений и компромиссах, которые пришлось учитывать при проектировании.

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