Доклады

WatchDog: применение Prophet и Scikit-learn (SKLearn) в прогнозировании роста объёмов баз данных PostgreSQL.

В докладе, осветим актуальность темы прогнозирования роста баз данных PostgreSQL. Коснёмся факторов, которые влияют на рост баз данных PostgreSQL. Сравним Prophet и Scikit-learn - для решения задачи прогнозирования роста БД. Подробно расскажем о шагах, реализованных в WatchDog, по решению этой задачи, и - полученных результатах.

PostgreSQL 17

Рассмотрим наиболее интересные изменения 17-й версии PostgreSQL.

Бета-версия этого доклада была представлена на апрельской конференции PgConf.Russia. На тот момент о PostgreSQL 17 было известно многое, но не всё. Да и автор не со всеми изменениями успел разобраться. На этот раз будет представлена расширенная и дополненная версия, включаяющая, но не ограниченная новинками в следующих областях: - инкрементальное резервное копирование; - оптимизация очистки (VACUUM), куда же без этого; - новые возможности MERGE; - слияние/разделение секций у секционированной таблицы; - изменения в логической и физической репликации; - улучшения в мониторинге и сопровождении системы.

Необычные возможности системы резервного копирования WAL-G

Типичный рабочий процесс любого решения для резервного копирования относительно прост: настройте архив для восстановления на определенный момент времени, создайте расписание ротации резервных копий и время от времени проверяйте процесс восстановления. Однако WAL-G предоставляет несколько полезных функций, которые могут пригодиться администраторам баз данных в критической ситуации:
1. Настройка троттлинга для изменения обычного режима "дешевое резервное копирование - быстрое восстановление".
2. Расширенные возможности мониторинга согласованности для обеспечения надёжности резервных копий.
3. Catchup для быстроого сокращения лага и другие функции кластера высокой доступности.
4. Различные методы извлечения набора изменений для инкрементного резервного копирования. Кроме того, я расскажу о планах на будущее, включая создание согласованных резервных копий для шардированных кластеров и использование расширенных возможностей S3.

pg_uprobe: Профилируем Си-шные функции PostgreSQL без боли и печали

Профилировать программы с помощью gdb/perf/ebpf/whatever бывает накладно по ряду причин. ebpf/perf выполняются в пространстве ядра, PostgreSQL работает в пользовательском пространстве, а переключение между пространстами может сильно ухудшить производительность. Также профилирование требует специальных привелегий, которых часто не хватает, и может сильно отличаться на разных операционных системах. Расширение pg_uprobe для PostgreSQL решает выше перечисленные проблемы: -не содержит внешних зависимостей аля ebpf/perf/whatever -легко установить (как и любое другое расширение) -профилирует отдельные бекенды и не только это... Приходить на наш доклад чтобы узнать как этим можно пользоваться, как оно реализовано внутри.

Как мы тестировали Postgres Pro BiHA

"Сад разложенных граблей" или что мы хотели получить;
"Сделать хотел сеппуку, а вышло опять харакири" или что мы получили;
"Я изоленту принёс" или как нам жить дальше.

Безопасность отрасли СУБД-строения в России на примере PostgreSQL

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

Инструменты Postgres Pro для исправления, фиксации и миграции планов проблемных запросов.

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

Дело о пропавшей производительности в PostgreSQL: руководство по поимке и обезвреживанию проблемных запросов

Город спит, даже не догадываясь, как мужественно администраторы баз данных ради всеобщего блага сражаются за ускорение выполнения запросов на даже долю секунды. Используем встроенные инструменты PostgreSQL, чтобы • вычислять неоптимальные запросы, • избегать проблем с ними в будущем • и даже принимать решения на ходу, без остановки их выполнения.

Использование JSONB полей вместо EAV в PostgreSQL

Успешный кейс использования JSONB полей, как основных для хранения всей бизнес информации в высоконагруженной CRM системе.

Адаптивный исполнитель запросов

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

Лучшие практики по оптимальной работе базы данных на примере PostgreSQL

cgroup V2 - Ограничение ресурсов PostgreSQL

Как в условиях работы нескольких экземпляров PostgreSQL на одной физической или виртуальной машине распределить ресурсы.

Выбор репликационного протокола при разработке pg_probackup3

Декларативное партиционирование

Наш опыт перехода, преимущества и ограничения использования

Generic plan и потребление памяти запросов к секционированным таблицам

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

Сжатие данных с CFS

В этом докладе мы рассмотрим:
1. Что такое CFS и как она устроена
2. Какие есть настройки и параметры
3. Особенности и сюрпризы при работе с CFS CFS и встроенная компрессия PostgreSQL
4. Ограничениия CFS

Проверка на прочность. Утилиты для анализа и оптимизации PostgreSQL

Внедрение и эксплуатация PostgreSQL могут быть сложными задачами, особенно когда речь идет о поддержании здоровья и производительности базы данных. Однако, использование специализированных утилит для проверки состояния системы позволяет облегчить их решение. В ходе выступления мы поговорим об инструментах, которые помогают администраторам и разработчикам эффективно конфигурировать и искать проблемы PostgreSQL, рассмотрим утилиты проверки баз данных, такие как postgresqltuner, postgres-checkup, pgdsat, PG Collector, а также поделимся собственным опытом и подходами к поиску проблем, возникающих при внедрении и эксплуатации PostgreSQL.

Cиквел и приквел: занимательная археология

Предлагаю совершить небольшое путешествие на полвека назад и посмотреть, чем жили наши коллеги. Я расскажу, как работали с базами данных до Кодда и что изменилось с изобретением реляционной теории; поговорим о зарождении первых реляционных систем — System R и Ingres; о том, как появился и завоевал популярность язык SQL; о людях, которые определили наше настоящее и в какой-то степени будущее.