PG_HAZEL : Стратегии сбора данных уровня SQL-запросов

Данные это основа. Эффективность сбора и обработки данных определяет эффективность системы в целом.

1. Монолитная стратегия

Агрегация и сглаживание данных осуществляется параллельно со cбором исходных данных статистики SQL-запросов.

Устойчив и надежен.

Преимущества(?)

• Самый первый вариант реализации.

Недостатки

• Дополнительная нагрузка на СУБД и ОС.
• Неравномерные данные по статистике уровня SQL при высокой нагрузке(отсутствие детальной статистики по минутам, при высокой нагрузке).
• Большие промежутки между снимками pgpro_pwr при высокой нагрузке.

2. Отложенная стратегия

Сбор исходных данных статистики SQL-запросов одновременно сбором статистики по СУБД в целом.

Агрегация и сглаживание выполняется при подготовке отчетов.

Любое дело можно отложить на потом.

Преимущества

• Отсутствие дополнительной нагрузка на СУБД и ОС.
• Стандартные промежутки для снимков pgpro_pwr.

Недостатки

• Практическая невозможность получения отчетов по статистике SQL для продуктивных СУБД.

3. Раздельная стратегия

Процесс-1 - cбор исходных данных статистики SQL-запросов, одновременно со сбором данных по СУБД.

Процесс-2 - агрегация и сглаживание накопленных данных по отдельным SQL-запросам.

Декомпозиция - старый и проверенный временем, эффективный способ решения больших задач.

Преимущества

• Оперативное получение агрегированных данных.
• Возможность построения детальной истории выполнения и ожиданий по отдельным SQL запросам(поминутно).
• Стандартные промежутки для снимков pgpro_pwr.

Недостатки

• Дополнительные соединения к СУБД (можно настроить и свести к минимуму ).

Итог - "Раздельная стратегия" реализована и проходит тестирование в продуктивном контуре.

Тестирование - как финал долгих исследований и экспериментов.

P.S. Мнение нейросети о сравнении стратегий

1. Монолитная стратегия

Особенности реализации:

• Все процессы сбора, агрегации и сглаживания статистики выполняются в рамках одного модуля
• Минимизируются внешние зависимости и взаимодействия между компонентами
• Данные обрабатываются immediately после сбора

Преимущества:

• ✅ Простота развертывания: Требуется только один скрипт для управления
• ✅ Целостность данных: Все операции выполняются в едином контексте, минимизируя риски потери данных

Недостатки:

• ❌ Высокая нагрузка на систему: Процесс сбора и обработки может потреблять значительные ресурсы CPU и памяти в пиковые периоды
• ❌ Гибкость: Сложность модификации отдельных компонентов без переработки всего модуля

Накладные расходы:

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

2. Отложенная стратегия

Особенности реализации:

• Разделение процесса сбора данных и их последующей обработки
• Сбор данных выполняется в реальном времени, а агрегация откладывается до момента формирования отчетов
• Возможность использования различных алгоритмов сглаживания без изменения процесса сбора

Преимущества:

• ✅ Снижение нагрузки на прод: Основная база данных не подвергается нагрузке от ресурсоемких операций агрегации
• ✅ Гибкость анализа: Различные методы агрегации могут применяться к одним и тем же данным
• ✅ Распределение нагрузки: Обработка может быть перенесена на специализированные серверы или выполнена в непиковое время

Недостатки:

• ❌ Усложнение архитектуры: Требует координации между компонентами сбора и обработки
• ❌ Задержка в отчетности: Данные не доступны в агрегированном виде до выполнения процесса постобработки
• ❌ Требования к хранилищу: Необходимость сохранения данных до момента их обработки

Накладные расходы:

• Дополнительные затраты на хранение необработанных данных
• Периодические пики нагрузки при выполнении агрегации
• Дополнительная нагрузка на координацию между компонентами системы