PGConf.Russia 2018

Однажды вот Питон и Слон
Вести тестирование взялись.
И вместе все в него впряглись!

В нашей компании (Postges Professional) разрабатываются разные проекты: multimaster, pg_probackup, pg_pathman, pg_shardman, RUM, и другие. Совладать со всей этой оравой весьма непросто, поэтому нам необходим инструмент, который способен облегчить и ускорить написание всевозможных тестов.

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

Вы узнаете, как при помощи нескольких строчек кода запускать узлы PostgreSQL, настраивать всевозможную репликацию и создавать бекапы, меняя параметры на лету, и про многое другое. Также мы расскажем, как эти возможности позволяют нам проверять "самые труднодоступные места" и улучшать качество наших продуктов.

Мы стремимся сделать testgres фреймворком для проведения функциональных тестов пользовательских запросов, хранимых процедур и прочей серверной логики, привнося практику TDD на уровнь разработки БД.

Кнопка, крупнейший аутсорсинг бухгалтерии, расскажет о своем опыте перевода 500Gb баз 1С Fresh на PostgreSQL. В докладе затронуты темы выбора СУБД и борьбу со стереотипами, с чего мы начали и как развивали использование PostgreSQL, подходы к резервированию и восстановлению ИБ, наши текущие показатели работы СУБД и 1С, взгляд в будущее. Поделимся, почему мы считаем, что 1С+PostgreSQL это просто, надежно и быстро.

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

Такой призыв часто возникает, когда в PostgreSQL возникают проблемы, и главным подозреваемым оказывается vacuum. По опыту, многие наступают на эти грабли, и мне с коллегам по Data Egret нередко приходится разгребать последствия, так как потом всё становится ещё хуже. Но если обратить внимание на сам vacuum, то, пожалуй, нет такого человека, который бы использовал Postgres, и при этом ничего не знал про вакуум. Ведь история вакуума начинается относительно давно, и в интернете можно найти массу как старых, так и новых постов про вакуум, объемные дискуссии в списках рассылки. Несмотря на то, что тема вакуума подробно описана в официальной документации к PostgreSQL, новые посты и новые дискуссии будут появляться и дальше. Возможно, поэтому с вакуумом связано очень много мифов, баек, страшилок и заблуждений. Между тем, вакуум является одним из важнейших компонентов PostgreSQL, и его работа напрямую сказывается на производительности. В одном докладе невозможно рассказать про вакуум абсолютно всё, но я бы хотел раскрыть ключевые моменты, связанные с вакуумом, такие как его внутреннее устройство, основные подходы к его настройке, наблюдение за производительностью, мониторинг, и что делать в случае, когда вакуум - главный подозреваемый во всех бедах. Ну и, конечно же, хочется развеять распространенные мифы и заблуждения, связанные с вакуумом.