Здравствуйте! Хочу рассказать про особенности партиционирования в текущей postgresql 9.х и его улучшении с помощью расширения pg_pathman (и вот), созданного парнями из Postgres Professional. Статья предназначена для знакомых с партиционированием разработчиков, которым понадобилось разбить большую БД в postgres, или для тех, кто хочет оценить сложность переноса уже партиционированной не postgres БД на postgres.

Сначала мы создадим схему БД, затем партиционируем её двумя способами(«штатным» и pg_pathman), после чего наполним данными и проверим, как работают запросы по партиционированным таблицам.

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

Александр Коротков, Дмитрий Иванов (Postgres Professional)

Ведущий: Тяжелая артиллерия в лице Александра и Дмитрия будет рассказывать про важную фичу Postgres. И не то, чтобы фичу, а проблему, с которой сталкиваются люди, работающие с Postgres – это то, как правильно секционировать или партиционировать, как вам более удобно произносить, таблицы. И Александр с Дмитрием уже довольно длительное время трудятся над расширением, которое позволяет это делать гибко, хорошо, удобно и быстро.

Александр Коротков: Как правильно уже сказали, наш доклад будет посвящен расширению pg_pathman, которое реализует продвинутое секционирование в Postgres. Основную часть доклада будет рассказывать мой коллега Дмитрий Иванов, который сейчас очень активно включился в работу над расширением pg_pathman, а я буду время от времени что-то добавлять.

Примерно год назад передо мной и моими коллегами была поставлена задача разобраться с использованием популярной системы мониторинга сетевой инфраструктуры — Zabbix. После изучения документации мы сразу же перешли к нагрузочному тестированию: хотели оценить с каким количеством параметров может работать Zabbix без заметных падений производительности. В качестве СУБД использовали только PostgreSQL.

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

О результатах проделанной работы я и хочу поделиться в данной статье. Статья будет полезна как администраторам Zabbix, так и PostgreSQL DBA, а также всем желающим лучше понять и разобраться в популярной СУБД PosgreSQL.

Небольшой спойлер: на слабой машине при нагрузке в 200 тысяч параметров в минуту нам удалось снизить показатель CPU iowait с 20% до 2%, уменьшить время записи порциями в таблицы первичных данных в 250 раз и в таблицы агрегированных данных в 32 раза, уменьшить размер индексов в 5-10 раз и ускорить получение исторических выборок в некоторых случаях до 18 раз.