Инструменты Оптимизации Запросов в PostgreSQL. Часть 11
11. Советник в AWS Redshift
Что даёт: рекомендации по оптимизации, специфичные для Redshift.
Тип: Встроенный сервис AWS
Стоимость: Бесплатно (входит в Redshift)
Зачем нужен
Redshift предъявляет уникальные требования к оптимизации: ключи распределения, ключи сортировки, сжатие. Советник анализирует шаблоны запросов и рекомендует оптимизации.
Использование
Панель управления AWS: Redshift → Advisor recommendations
Либо CLI:
aws redshift describe-cluster-recommendations \
--cluster-identifier my-cluster
Либо SQL:
SELECT * FROM svv_redshift_advisor_recommendations;
Примеры рекомендаций
1. Добавить сжатие
Таблица: orders
Колонка: customer_notes (VARCHAR)
Текущее: Нет
Рекомендованное: LZO
Влияние: экономия места 65%
Планируемая экономия: $450/мес
Сгенерированный SQL:
ALTER TABLE orders
ALTER COLUMN customer_notes ENCODE LZO;
2. Ключ Сортировки
Таблица: orders
Текущий: Нет
Рекомендованный: (order_date, customer_id)
Причина: 87% запросов фильтруют/сортируют по order_date
Влияние: ускорение запросов на 40%
Планируемое улучшение: сокращение времени запросов на 2.3 часа в день
Сгенерированный SQL:
CREATE TABLE orders_new (LIKE orders)
SORTKEY (order_date, customer_id);
INSERT INTO orders_new SELECT * FROM orders;
DROP TABLE orders;
ALTER TABLE orders_new RENAME TO orders;
3. Ключ распределения
Таблица: order_items
Текущий: DISTSTYLE EVEN
Рекомендованный: DISTKEY (order_id)
Причина: Частые объединения с orders по order_id
Влияние: Ускорение объединений в 3 раза
Сгенерированный SQL:
CREATE TABLE order_items_new (LIKE order_items)
DISTKEY (order_id);
INSERT INTO order_items_new SELECT * FROM order_items;
-- …
4. Обслуживание таблицы
Таблица: customers
Проблема: Замечено разбухание таблицы (75% данных на 2 узлах)
Действие: Требуются VACUUM и ANALYZE
Влияние: Улучшение производительности запросов
Сгенерированный SQL:
VACUUM SORT ONLY customers;
ANALYZE customers;
Когда использовать
- Используете AWS Redshift;
- Хотите оптимизацию специально для Redshift;
- Неясно, какие оптимизации лучше;
- Необходимо обосновать затраты на инфраструктуру (показать потенциал оптимизации).
Когда отказаться
- Не используете Redshift;
- Невозможность выполнить рекомендации (требуют перестроения таблиц).
Скрытая функция
Рекомендации по очереди запросов.
Рекомендация: Управление рабочей нагрузкой (WLM)
Текущая конфигурация: по умолчанию (1 очередь, все запросы имеют одинаковый приоритет).
Обнаруженные закономерности:
- Короткие запросы (<1 с): 85%.
- Средние запросы (1–60с): 10%.
- Длинные запросы (>60 с): 5%.
Рекомендуемая модификация WLM:
Очередь 1 (короткие): 40% памяти, параллелизм 15.
Фильтр: query_execution_time < 1с.
Очередь 2 (средняя): 40% памяти, параллелизм 5.
Фильтр: query_execution_time 1–60с.
Очередь 3 (длинная): 20% памяти, параллелизм 2.
Фильтр: query_execution_time > 60с.
Влияние:
- Короткие запросы не будут ждать длинных.
- Общее увеличение пропускной способности в 3 раза
- Снижение задержки p95: 80%
С осторожностью
Некоторые рекомендации требуют пересоздания таблиц. Изменение DISTKEY или SORTKEY требует перестроения таблицы. В таблице размером 1 ТБ это может занять несколько часов и заблокировать запись.
Более безопасный подход: использовать окно обслуживания. Назначаем на время с наименьшей нагрузкой. Сначала тестируем в среде разработки.
BEGIN;
-- 1. Создаём таблицу с оптимизациями
CREATE TABLE orders_new (LIKE orders)
SORTKEY (order_date, customer_id)
DISTKEY (customer_id);
-- 2. Копируем данные (может занять часы)
INSERT INTO orders_new SELECT * FROM orders;
-- 3. Меняем таблицы (атомарно)
ALTER TABLE orders RENAME TO orders_old;
ALTER TABLE orders_new RENAME TO orders;
-- 4. Удаляем старую (после проверки)
DROP TABLE orders_old;
COMMIT;
Отслеживаем прогресс с помощью:
SELECT * FROM svv_vacuum_progress;
Источник: https://medium.com/@reliabledataengineering/15-sql-optimization-tools-that-make-queries-10x-faster-8629ac451d97