Отличной всем пятницы! Все меньше времени остается до запуска курса , поэтому сегодня делимся переводом еще одного полезного материала по теме.
В процессе разработки была проделана впечатляющая работа по улучшению секционирования таблиц. Секционирование таблиц — это функция, которая существовала в PostgreSQL достаточно долгое время, но ее, если можно так выразиться, по сути не было до 10 версии, в которой она стала весьма полезной функцией. Ранее мы заявляли, что наследование таблиц — это наша реализация секционирования, и это правда. Только этот способ заставлял вас делать большую часть работы вручную. Например, если вы хотели, чтобы кортежи вставлялись в секции во время INSERTов, вы должны были настроить триггеры делать это за вас. Секционирование с помощью наследования было очень медленным и сложным, чтобы разрабатывать дополнительные функции поверх него.
В PostgreSQL 10 мы увидели рождение «декларативного секционирования» — фичи, предназначенной для решения многих проблем, которые были неразрешимы при использовании старого метода с наследованием. Это привело к появлению гораздо более мощного инструмента, позволяющего нам разделять данные по горизонтали!
Сравнение фич
В PostgreSQL 11 появился впечатляющий набор новых фич, которые помогают повысить производительность и сделать секционированные таблицы более прозрачными для приложений.
1. Используя ограничивающие исключения
2. Добавляет только узлы
3. Только для секционированной таблицы, ссылающейся на несекционированную
4. Индексы должны содержать все ключевые столбцы секции
5. Ограничение на секцию с обеих сторон должны совпадать
Производительность
Здесь у нас также есть хорошие новости! Добавлен новый метод . Этот новый алгоритм может определять подходящие секции, просматривая условие запроса WHERE. Предыдущий алгоритм, в свою очередь, проверял каждую секцию, чтобы определить, может ли она соответствовать условию WHERE. Это приводило к дополнительному увеличению времени планирования по мере роста количества секций.
В 9.6, с секционированием с помощью наследования, маршрутизация кортежей в секции обычно выполнялась путем написания триггерной функции, которая содержала серию операторов IF для вставки кортежа в правильную секцию. Эти функции могли быть очень медленными при выполнении. С декларативным секционированием, добавленным в 10 версии, это стало работать намного быстрее.
Используя секционированную таблицу со 100 секциями, мы можем оценить производительность загрузки 10 миллионов строк в таблицу из 1 столбца BIGINT и 5 столбцов INT.
Производительность запроса к этой таблице для поиска одной индексированной записи и выполнения DML для манипулирования одной записью (используя только 1 процессор):
Здесь мы видим, что производительность каждой операции значительно возросла после PG 9.6. Запросы SELECT выглядят намного лучше, особенно те, которые способны исключать множество секций во время планирования запросов. Это означает, что планировщик может пропустить большую часть работы, которую он должен был делать раньше. Например, больше не строятся пути для ненужных секций.
Заключение
Секционирование таблиц начинает становиться очень мощной функцией в PostgreSQL. Оно позволяет быстро выводить данные в online и переводить их в offline, не дожидаясь завершения медленных массивных операций DML. Это также означает, что связанные данные могут храниться вместе, то есть к требуемым данным можно получить доступ гораздо эффективнее. Улучшения, сделанные в этой версии, были бы невозможны без разработчиков, ревьюеров и коммиттеров, которые неустанно работали над всеми этими фичами.
Спасибо им всем! PostgreSQL 11 выглядит просто фантастически!
Вот такая коротенькая, но довольно интересная статья. Делитесь комментариями, а также не забывайте записываться на , в рамках которого будет подробно изложена программа курса.
Источник: habr.com