ADG Оставить заявку
Блог Данные и аналитика 4 мин чтения

PostgreSQL 12 вышел: тестировали бету, апгрейдаем GA - что дало в продакшне

PostgreSQL 12 GA вышел 3 октября. Рассказываем, что inline CTE и JSON Path дали нам в реальных DWH-запросах после месяцев тестирования беты.

Контекст момента

PostgreSQL 12 вышел 3 октября 2019: улучшенное партиционирование с индексами на секциях, inline CTE по умолчанию, generated columns, JSON Path.

3 октября PostgreSQL Global Development Group выпустила PostgreSQL 12 GA. Для нас это не сюрприз - мы тестировали беты с июля, последний нагрузочный прогон сделали на Beta 3 в конце сентября. Аудит CTE-запросов закончен, вопросы с партиционированием понятны. Осталось принять решение про апгрейд и посмотреть, что GA добавил поверх того, что мы уже щупали.

Что нового в релизе относительно бет

Сами бреши в поведении, с которыми мы разбирались летом, в GA не изменились. Зато появились несколько вещей, которые в бетах были либо сырыми, либо вовсе отсутствовали.

JSON Path - нормальный, не черновой. В Beta 1 JSON Path был там, но слабо задокументирован и местами вёл себя непредсказуемо. В GA реализация RFC-стандарта jsonpath полная: операторы фильтрации, методы .type(), .size(), .ceiling(), поддержка рекурсивного спуска .**.field. Нас это интересует напрямую - в нескольких DWH-клиентских базах часть данных живёт в JSONB-полях (события, атрибуты продуктов), и поиск по этим полям сейчас делается либо через ->>-операторы в навороченных условиях, либо через GIN-индекс с @>. JSON Path даёт возможность формулировать такие запросы читаемо, а главное - индексировать результат выражения.

Партиционирование закрыло последние дырки. Из того, что нас беспокоило в Beta 1: DEFAULT партиция теперь нормально работает с partition pruning, внешние ключи на партиционированных таблицах поддерживаются полностью. В нагрузочных тестах мы этого не трогали - но схема клиентской базы как раз задействует FK на секционированную таблицу фактов, так что это важно.

Что реально изменится в продакшне

С DWH и BI у нас несколько активных баз на PostgreSQL 11. По итогам тестирования беты картина примерно такая.

Inline CTE. Это главное изменение, которое мы уже прожевали на стенде. Большинство аналитических запросов стали быстрее или не изменились. Два запроса получили деградацию плана, оба починились через MATERIALIZED. Новых сюрпризов от GA здесь не ожидаем - механика та же, что в бете. Аудит запросов сделан, правки внесены в репозиторий, скрипты нагрузочного тестирования готовы к прогону уже на GA.

Побочный эффект, который мы оценили чуть позже: несколько CTE-запросов, написанных когда-то с избыточными обходными приёмами именно потому, что планировщик не мог зайти внутрь - теперь можно переписать проще. Один из них - двухэтажный WITH, где внешний CTE собирал результат внутреннего и применял к нему ещё один фильтр. Раньше это был вынужденный паттерн. Теперь это просто два вложенных подзапроса с одним условием. Меньше кода, тот же результат, читаемее.

Индексы на партиционированных таблицах. Здесь улучшение конкретное и бытовое: скрипт, который у нас добавлял партиции и отдельным шагом создавал на каждой индексы, стал проще. Один CREATE INDEX на родителе - и всё. Новые партиции наследуют индекс автоматически. Меньше мест, где можно забыть.

JSON Path - только начинаем смотреть. На двух клиентских базах в схеме есть JSONB-поля с событийными данными. Запросы по ним сейчас не самые изящные. JSON Path обещает позволить делать такие вещи:

SELECT id, data
FROM events
WHERE data @@ '$.tags[*] == "critical" && $.severity > 3';

Вместо нынешнего нагромождения jsonb_array_elements и условий через ->>. Пока это в категории "надо пробовать на стенде" - семантика правильная, индексирование jsonpath-выражений через функциональные индексы тоже работает в теории. Но как это поведёт себя на реальных объёмах - посмотрим.

Про апгрейд

Решение принято: берём одну из клиентских баз, которая была у нас на стенде всё лето, и в ноябре апгрейдаем на PostgreSQL 12. База средняя по размеру, нагрузка предсказуемая, аудит запросов уже сделан. Хороший кандидат для первого GA-апгрейда.

Большая DWH-база - та, что под триста гигабайт с шестью десятками партиций - пока остаётся на 11-й версии. Не потому что боимся, а потому что для неё нужно отдельное окно обслуживания и отдельный нагрузочный прогон уже на GA-сборке. Запланировали на декабрь.

Вывод по итогам нескольких месяцев тестирования: PostgreSQL 12 - это не "много всего нового", а несколько хорошо доделанных вещей, которые в 11-й версии были либо неполными, либо требовали обходных путей. Для DWH-нагрузки это ровно то, что нужно: предсказуемость, управляемость, чуть меньше магии в планировщике.

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.