Постгрессовый планнер с памятью

Постгрес умеет строить оптимальные планы запросов для большинства практических случаев. Однако иногда, по объективным причинам, для сложных запросов или из-за ошибок в самом планнере, он может ошибаться и выдавать неоптимальный план. Из-за этого, время выполнения такого запроса может возрастать в десятки раз. Если запрос выполняется часто, то из раза в раз этот запрос выполняется дольше, чем мог бы, и СУБД в целом выдает меньший TPS. Если планнер сможет фиксировать свои ошибки и учитывать их при последующем планировании того же запроса, то это позволит улучшать характеристики СУБД в процессе её эксплуатациии. Мы представляем результаты разработки расширения для СУБД PostgreSQL, которое хранит историю выполнения запросов и реализует рекомендательный механизм для планнера. Показываем, как знание о ранее выполнявшихся запросах позволяет улучшить выполнение последующих.

Неочевидные моменты процесса копирования и переноса баз данных и кластеров PostgreSQL

Копирование и перенос баз данных и кластеров PostgreSQL, казалось бы, что может быть проще?

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

Жизнь DBA в онлайн-кинотеатре "OKKO"

Okko — один из самых больших легальных онлайн-кинотеатров в России. В нашем каталоге представлено 60 000 фильмов, мультфильмов и сериалов. С момента запуска сервис посетили более 20 млн пользователей. Ежемесячная аудитория составляет 2,8 млн человек Все эти цифры говорят о надежном высоконагруженном сервисе.

В своем докладе я, как DBA, буду говорить преимущественно о базах данных (PostgreSQL, Cassandra, Redis), которые используются в компании. Подробно рассмотрим PostgreSQL на темы высоких нагрузок, мониторинга, оптимизации, резервного копирования и восстановления.

Повреждение данных: как его избежать, обнаружить и обеспечить восстановление

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