Является ли СУБД эмерджентной системой ?⁠⁠

Взято с основного технического канала Postgres DBA

Эмердже́нтность или эмерге́нтность (англиц. от emergent «возникающий, неожиданно появляющийся»)[1] в теории систем — наличие у системы свойств, не присущих её компонентам по отдельности; несводимость свойств системы к сумме свойств её компонентов.

В связи с началом тестирования комплекса pg_hazel под продуктивной нагрузкой возникает очень важный вопрос:

Можно ли рассчитывать метрики производительности СУБД суммируя значения метрик отдельных баз данных, составляющих кластер PostgreSQL ?

Словарь терминов оперативно-тактического комплекса "PG_HAZEL".

Экспериментальные данные

В качестве источника данных для расчета метрик производительности кластера , используется представление pgpro_stats_totals

G.4.4.2. Представление pgpro_stats_totals

Агрегированная статистика, собранная модулем, выдаётся через представление pgpro_stats_totals.

Операционная скорость СУБД

Количество ожиданий СУБД

Коэффициент корреляции между операционной скоростью и ожиданиями составляет -0,8736.

Вопрос : является ли ситуация существенного снижения операционной скорости и роста ожиданий СУБД - инцидентом деградации производительности СУБД?

Анализ операционной скорости по отдельным базам данных

Для расчета операционной скорости по отдельному SQL выражению используется представления pgpro_stats_statements

G.4.4.1. Представление pgpro_stats_statements

Статистика, собираемая модулем, выдаётся через представление с именем pgpro_stats_statements. Это представление содержит отдельные строки для каждой комбинации идентификатора базы данных, идентификатора пользователя и идентификатора запроса

Для расчета операционной скорости по базе данных применяется агрегирование .

Для сокращения анализа, рассмотрим только список баз данных с наиболее коррелированными(близкими) значениями операционной скорости со значениями операционной скорости СУБД .

Для простоты достаточно рассмотреть графики операционной скорости для баз данных по которым количество значений наиболее близко к количеству значений по СУБД в целом - test_db-7 , test_db-6 и test_db-4.

Вывод по итогам анализа операционной скорости при работе СУБД под продуктивной нагрузкой

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

Корреляционный анализ на уровне баз данных

Интересные детали

База данных DB-1 имеет значение коэффициента корреляции между значениями операционной скорости и ожиданиями = -0.3985 , но если рассчитать коэффициент корреляции между операционной скоростью и количеством ожиданий конкретного типа, то все значения положительны.

Если посмотреть график истории ожиданий, становится понятно, почему так происходит.

Получается слабая отрицательная корреляция

Однако , если посмотреть графики истории ожиданий по типам ожиданий IO , IPC , LWLock корреляция будет совсем другой :

Вывод

При расчете метрик производительности СУБД как суммы значений метрик производительности по базам данных, входящим в кластер СУБД, возможна ошибка второго рода - анализ инцидента деградации производительности СУБД при отсутствии деградации производительности баз данных.

Необходимо подготовить методику применения корреляционного анализа в условиях продуктивной нагрузки на СУБД.

Таким образом, можно сформулировать гипотезу

Если в состав кластера СУБД входят разнородные базы данных , то СУБД обладает свойством эмерджентности. Нельзя анализировать поведение СУБД в целом. Необходимо анализировать поведение отдельных баз данных.