PgConf.Russia 2016

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

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

Все говорят, что для максимальной производительности работы из Java с базой данных нужно использовать PreparedStatements и Batch DML. Практика показывает, что нельзя слепо идти на поводу у прописных истин. Нужно понимать особенности конкретной базы и характера передаваемых данных. В докладе мы рассмотрим то, как эффективное использование протокола PostgreSQL позволяет добиться высокой производительности при выборке и сохранении данных. На примерах увидим как простые изменения в коде приложения и JDBC драйвера на порядок ускоряют запросы. Мы увидим как задействовать механизм server prepared statements из клиенсткого кода и узнаем его узкие места. Обсудим средства эффективной передачи данных в базу. Многие обсуждаемые доработки недавно вошли в состав официального JDBC драйвера. Доклад будет полезен не только Java программистам, т.к. многие подводные грабли вытекают из самого протокола общения PostgreSQL с внешним миром.

Механизм секционирования в Postgres имеет ряд ограничений, которые не позволяют использовать концепцию секционирования в полной мере. Среди таких ограничений можно выделить неэффективность планирования запросов для секционированных таблиц (линейный рост времени планирования при увеличении количества секций), отсутствие HASH-секционирования, необходимость ручного управления секциями. Однако, средства расширяемости Postgres предоставляют разработчику широкие возможности, позволяющие обойти некоторые ограничения. В докладе будет рассказано, как внедрившись в код планировщика удалось оптимизировать время планирования запросов. Так метод бинарного поиска позволяет добиться логарифмического роста времени планирования для RANGE-секционированных таблиц. Поэтому использование даже тысяч секций не будет приводить к существенным накладным расходам. Также удалось реализовать HASH-секционирование с близким к константному времени планирования.

Менеджер буферов Postgresql разработан достаточно давно и его возраст даёт о себе знать в некоторых аспектах. Мы обсудим, как он работает сейчас, каковы его недостатки, и что делается сейчас, чтобы их исправить.

• Поиск в кеше обходится дорого
• Таблица сопоставлений буфера организована в виде хеш-таблицы, что затрудняет эффективную реализацию предвыборки, совмещение операция записи и очистки содержимого кеша
• Расширение отношений плохо масштабируется
• Вытеснение из кеша неэффективно
• При вытеснении из кеша замещаются неправильные буферы