Мастер-класс: Больше индексов, хороших и разных

"Не мог он GIN от SP-GiST-а, как мы ни бились, отличить", говорил классик. А вы можете? Этот мастер-класс посвящен индексам, которые хоть и не так часто используются, как обычное B-дерево, но могут сильно выручить в трудную минуту. Мы посмотрим, как устроены эти индексы и в каких случаях они могут быть успешно применены. Заодно поговорим и об особенностях индексного доступа в PostgreSQL. Чтобы провести время с пользой, от слушателей потребуется некоторое знакомство с PostgreSQL и умение читать планы несложных запросов.

Материалы мастер-класса

• Слайды
• Demo 1
• Demo 2
• Demo 3

Резервную копию БД с демонстрационными данными можно скачать тут:

• Восстановление с помощью pg_restore (338 MB)

Как мы распрощались с MongoDB и перешли на PostgreSQL

В своем докладе я поделюсь опытом переноса, конвертацией NoSQL-данных в реляционный вид и расскажу, как нам удалось ускорить приложение в 2 раза.

Изначально для хранения данных мы использовали PosgtgreSQL и MongoDB. На практике мы выяснили, что такое разделение крайне неудобно. Мы тратили уйму времени и внимания.

Расскажу, как с помощью mosql мы перенесли данные из MongoDB в PostgreSQL. Теперь все данные могут быть получены одним запросом, а схема таблиц обеспечивает консистентность данных.

Использование PITR в распределенных cистемах на базе PostgreSQL

В Postgres есть возможность восстановления данных на момент времени (PITR), которая позволяет нам "отправляться" в прошлое. В этом докладе мы обсудим, какие существуют основные сценарии использования этой функциональности, как подготовить базу данных к восстановлению на момент времени, настроив хорошую систему бэкапов и транcляции WAL-файлов, а также рассмотрим конкретные примеры. Мы подробнее остановимся на том, как применять PITR на распределенных системах и кластерах с шардингом, затронув типичные проблемы подобных конфигураций, такие как разница во времени, и предложим возможные способы их решения - например, двухфазный коммит и pg_create_restore_point.

Давайте отключим vacuum?!

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