Серия «СУБД PostgreSQL»

Аннотация

Рассматривается опыт применения большой языковой модели DeepSeek в проекте pg_expecto/markov_chain — системе прогнозирования инцидентов производительности СУБД PostgreSQL на основе адаптивной цепи Маркова (версия 26.2.1). Нейросеть использовалась для генерации и рефакторинга PL/pgSQL-кода, формулировки проверяемых гипотез и интерпретации результатов экспериментов. Описаны конкретные задачи, решённые при участии DeepSeek: устранение ошибок типизации (замена REAL на DOUBLE PRECISION в функциях прогноза риска), восстановление пропущенных исторических записей в profile_comparison_log, диагностика систематической ошибки в классификаторе непокрытых инцидентов. Приведены количественные оценки: объём кода превышает 10 000 строк, число итераций для ключевых функций достигает 10, ускорение разработки оценивается в 4–6 раз. Обсуждается модель разделения труда, при которой DBA выполняет роль архитектора и критика, а DeepSeek — высокопроизводительного исполнителя для задач, требующих удержания в контексте сотен строк кода и анализа больших массивов текстовых отчётов.

Ключевые слова: PostgreSQL, цепь Маркова, прогнозирование инцидентов, большие языковые модели, DeepSeek, PL/pgSQL, калибровка вероятностей, анализ производительности.

1. Введение

Задачи анализа производительности СУБД традиционно решаются экспертами-администраторами (DBA) на основе эвристик и интуиции, что затрудняет воспроизводимость результатов и объективную оценку рисков. Проект pg_expecto/markov_chain, развиваемый в открытом репозитории на платформе GitHub, ставит целью формализацию этих задач в терминах вероятностной модели — дискретной цепи Маркова с 189 состояниями, каждое из которых определяется комбинацией корреляции «скорость–ожидания» и знаков трендов этих метрик. Модель обучается в потоковом режиме, ежесекундно обновляя матрицу переходов, и использует механизм адаптивного забывания для учёта нестационарности нагрузки.

Построение подобной системы сопряжено с рядом нетривиальных проблем, выходящих за рамки классической теории цепей Маркова: обеспечение воспроизводимости экспериментов, интерпретация калибровочных кривых, согласование исторических и онлайн-данных, выбор гиперпараметров. Настоящая работа обобщает опыт решения этих проблем с привлечением нейросети DeepSeek, которая выполняла функции генератора кода, поставщика гипотез и аналитика экспериментальных данных. Цель статьи — описать конкретные механизмы взаимодействия DBA и нейросети, оценить эффективность такого симбиоза и сформулировать условия, при которых использование больших языковых моделей в задачах подобного класса даёт значимый эффект.

2. Материалы и методы

2.1. Архитектура системы

К версии 26.2.1 система включает более 80 хранимых функций и процедур на языке PL/pgSQL, организованных в несколько слоёв. Ядро цепи Маркова образуют функции mchain_train_step() (поминутное обучение), update_markov_probabilities() (пересчёт матрицы вероятностей) и mchain_predict_risk_k_v2() (многошаговый прогноз риска). Пространство состояний формируется дискретизацией корреляции (21 уровень от −1.0 до +1.0 с шагом 0.1) и трендов операционной скорости и времени ожиданий (по три уровня), что даёт 189 состояний.

Профилирование нагрузки реализовано через функции calculate_profile_metrics(), compare_profiles_at() и histogram_divergence(). Сравнение текущего окна (обычно 60 минут) с эталонным безынцидентным окном позволяет вычислять JS-дивергенцию гистограмм состояний и присваивать статусы NORMAL, WARNING или CRITICAL. Сигналы предупреждения SICPP и C-only, реализованные в функциях sicpp_calculate_at() и mchain_hybrid_alert_at() соответственно, используют пороги по JS-дивергенции, перцентилю риска (p90) и взвешенной оценке W-score. С версии 26.1.1 введена калибровка вероятностей: сырой риск, выдаваемый цепью Маркова, может быть откалиброван с помощью изотонической регрессии или масштабирования Платта; калибровочная карта хранится в таблице mchain_calibration_map.

2.2. Организация взаимодействия с DeepSeek

Работа с нейросетью строилась по итеративной схеме. DBA формулировал задачу (например, «необходимо выявить причины, по которым часть инцидентов не покрывается сигналом SICPP»), после чего DeepSeek анализировал соответствующие фрагменты кода и данные, предлагал гипотезы и генерировал код для их проверки. Результаты экспериментов (отчёты, логи, метрики) возвращались в диалог для интерпретации. Финальное решение о внедрении изменений принимал DBA. Такая схема позволяла сочетать скорость генерации кода и анализа данных, присущую нейросети, с критической оценкой и предметной экспертизой человека.

3. Результаты

3.1. Разработка исходного кода

Значительная часть PL/pgSQL-кода проекта была создана при участии DeepSeek. Нейросеть генерировала начальные версии сложных хранимых функций объёмом в несколько сотен строк, включая mchain_train_step(), compare_profiles_at(), historical_fill_sicpp() и generate_incident_forecast_report_v2(). В комментариях к функциям сохранились следы итеративной работы: для compare_profiles_at зафиксированы версии v4, v5 и v5-fix1, где v5 содержала критическую ошибку (секции вычисления метрик были заменены заглушкой), а v5-fix1 восстанавливала их. Подобная детализация изменений характерна для кода, прошедшего через несколько циклов генерации и верификации.

Отдельного внимания заслуживает исправление ошибок типизации. В функциях прогноза риска mchain_predict_risk_k_v2() и её варианте с матрицей использование типа REAL для вектора состояний приводило к «антипереполнению» при умножении малых вероятностей. DeepSeek, проанализировав сообщения об ошибках, предложил заменить REAL на DOUBLE PRECISION на всём протяжении вычислений, оставив приведение к REAL только на выходе. Это исправление, задокументированное в комментариях к функциям, позволило повысить точность прогнозов и избежать молчаливого искажения метрик. Аналогичное исправление было перенесено в mchain_predict_risk_k_v2_with_matrix() (версия 17.1.3). Кроме того, в функции evaluate_forgetting_params() зафиксирован переход с сигнатуры REAL на NUMERIC, чтобы вызовы с числовыми литералами не приводили к ошибке «функция не существует».

Целый пласт кода — функции profile_comparison_completeness_report(), diagnose_incidents_without_prior_comparison(), diagnose_profile_comparison_duplicates(), deduplicate_profile_comparison_log() и verify_profile_comparison_dedup() — был написан для решения проблемы рассинхронизации исторических и онлайн-записей в profile_comparison_log. DeepSeek не только сгенерировал код этих функций, но и предложил стратегию идемпотентного дозаполнения с параметром p_skip_existing, что позволило устранить пропуски в данных без перезаписи исторических сигналов.

3.2. Генерация гипотез

Одной из ключевых ролей DeepSeek было порождение гипотез — предложений о том, какие параметры изменить и какие архитектурные решения опробовать. Функция evaluate_forgetting_params() и таблица forgetting_optimization_log предназначены для эмпирического подбора параметров адаптивного забывания (base_alpha, incident_half_life_days, min_alpha, interval_minute). DeepSeek предлагал сетки значений для перебора, а затем анализировал результаты, сохраняемые в лог. В комментариях к функции зафиксировано, что версия 17.1.3 устранила дубликат REAL-сигнатуры, который приводил к вызову не той перегрузки — это пример гипотезы о причине расхождения результатов, которая была проверена и подтверждена.

В конфигурационной таблице incident_forecast_config присутствуют поля hybrid_js_min_threshold, hybrid_p90_min_threshold, hybrid_w_score_min_threshold, а также параметры автоматической настройки (auto_threshold, c_auto_threshold). DeepSeek участвовал в анализе того, какие значения этих порогов обеспечивают наилучший баланс между полнотой и точностью. В комментариях к generate_incident_forecast_report_v2() отмечено, что условие A (PreAlertAdv) было исключено как шумовое (precision 5.9%, recall 17.1%), а условие B не дало уникального вклада — эти выводы были получены в результате серии экспериментов, гипотезы для которых формулировались совместно.

Проблема дублей в profile_comparison_log (одна и та же логическая минута могла быть записана с микросекундами из онлайн-функции и с обнулёнными секундами из исторической) была выявлена при анализе отчётов. DeepSeek предложил разделить метрики на total_rows, recorded_minutes и extra_rows, а также создать функцию diagnose_profile_comparison_duplicates() для детализации. Это позволило не просто констатировать наличие дублей, но и количественно оценить масштаб проблемы и предложить алгоритм дедупликации с сохранением наиболее информативных записей.

3.3. Анализ результатов экспериментов

Третий крупный блок задач — анализ экспериментальных данных. Нейросеть обрабатывала отчёты, содержащие тысячи строк, и выделяла закономерности, которые было бы затруднительно обнаружить вручную. С версии 26.1.1 в системе появились метрики ECE (Expected Calibration Error) и MCE (Maximum Calibration Error). DeepSeek помог сгенерировать код для их расчёта и сформулировать критерии вердикта в функции mchain_calibration_health_report(): GREEN (Brier ≤ raw, ECE ≤ 0.10, MCE для бинов с n ≥ 10 ≤ 0.25), YELLOW (пограничная зона), RED (деградация). В отчёте generate_incident_forecast_report_v2() появилась секция «Качество прогнозов: raw vs calibrated», где для каждой метрики выводится относительное изменение — это позволяет быстро оценить, приносит ли калибровка пользу.

В функции generate_incident_forecast_report_v2() (версия 21.6.6) присутствует секция диагностики C по непокрытым инцидентам, которая классифицирует каждый непокрытый инцидент по причине: in_prev_incident, in_recovery, profile_incident или threshold_fail. DeepSeek участвовал в анализе распределения этих причин и выявлении того, что многие инциденты ошибочно классифицировались как in_incident из-за самодетекции (функция is_ts_inside_incident() для самого инцидента всегда возвращает TRUE). Исправление (проверка пересечения с другим инцидентом, pi2.id <> b.id) было предложено и реализовано в версии 21.6.6. Это пример того, как нейросеть, проанализировав логику классификатора, обнаружила систематическую ошибку и предложила её устранить.

В отчётах generate_incident_forecast_report_v2() присутствуют секции распределения инцидентов по часам и дням недели. DeepSeek использовал эти данные для формулировки гипотез о сезонности нагрузки и о том, какие временные интервалы требуют более агрессивной настройки порогов. Окончательные решения принимались DBA, однако нейросеть обеспечивала первичную фильтрацию и визуализацию, которая ложилась в основу для дальнейшего анализа.

4. Обсуждение

4.1. Модель разделения труда

Опыт проекта подтверждает модель, при которой DeepSeek берёт на себя «черновую» работу, а DBA выполняет стратегические функции. Роль DBA включает постановку целей и ограничений (например, «горизонт прогноза не должен превышать 120 минут», «порог риска для critical_states не увеличивать выше 0.10 без пересмотра эмпирической модели»), критическую оценку гипотез, предложенных нейросетью, принятие финальных решений о внедрении изменений и формулировку «прорывных» идей, которые затем формализовывались с помощью DeepSeek. Роль DeepSeek включает генерацию и рефакторинг SQL-кода объёмом до нескольких сотен строк, анализ экспериментальных данных и подготовку отчётов, выявление скрытых зависимостей и аномалий в логах, документирование кода и ведение истории изменений, а также предложение альтернативных архитектурных решений.

4.2. Оценка эффективности

Количественно оценить вклад DeepSeek можно по следующим показателям. Объём кода превышает 10 000 строк PL/pgSQL, включая определения таблиц, функций, процедур и комментариев. Число итераций развития ключевых функций (судя по комментариям) составляет от 3 до 10, при этом каждая итерация включала генерацию или рефакторинг кода объёмом до нескольких сотен строк. Скорость выполнения этих операций с DeepSeek была в 4–6 раз выше, чем при ручной работе. Качественно нейросеть обеспечила непрерывность документирования (комментарии к каждой версии) и систематичность анализа (регулярные отчёты с фиксированной структурой), что снизило риск потери знаний при переходе между версиями.

По состоянию на версию 26.2.1 достигнуты следующие результаты. Покрытие инцидентов сигналом SICPP составляет 74.6% (50 из 67 инцидентов в тестовом периоде), при этом медианное время упреждения находится в диапазоне 15–60 минут. Качество прогнозов после калибровки: Brier score снижен до 0.0361, ECE (калиброванное) составляет 0.0062, что свидетельствует о высокой надёжности вероятностных оценок. Устранены критические пробелы в исторических данных (патч 26.2.1), что позволило корректно диагностировать причины непокрытия инцидентов и повысить доверие к отчётам.

4.3. Ограничения

Предлагаемый подход имеет ограничения. Во-первых, эффективность DeepSeek существенно зависит от качества постановки задачи: расплывчатые формулировки приводят к генерации нерелевантного кода. Во-вторых, нейросеть склонна к «галлюцинациям» — генерации синтаксически корректных, но семантически неверных конструкций, что требует обязательной верификации человеком. В-третьих, длинные диалоги с нейросетью могут терять контекст, что приводит к повторам и противоречиям. Эти ограничения компенсируются итеративной схемой работы и критической оценкой со стороны DBA.

5. Заключение

Опыт проекта pg_expecto/markov_chain демонстрирует, что синергия DBA и DeepSeek позволяет решать задачи, которые были бы неподъёмны для одного человека в разумные сроки. Нейросеть не заменяет эксперта, а многократно усиливает его возможности, беря на себя рутину и предоставляя материал для критического анализа. Дальнейшее развитие модели связано с автоматизацией выбора гиперпараметров (адаптивное забывание, пороги SICPP и C-only) и расширением набора сигналов предупреждения. Представляется, что описанная модель разделения труда применима не только к анализу производительности СУБД, но и к другим задачам, требующим сочетания предметной экспертизы и масштабной генерации кода.

Представим что база данных PostgreSQL — это большой город. Иногда город работает спокойно: запросы идут ровно, очередей почти нет, ожидания низкие. Иногда «погода» портится: скорость падает, ожидания растут, система начинает вести себя нервно. И в какой-то момент начинается «дождь» — серьёзная проблема производительности.

Задача прогнозирования — не предсказать каждую отдельную каплю и не обещать дождь на сто процентов. Задача скромнее и полезнее: вовремя заметить облака и сказать: «вероятность дождя выросла, стоит приготовиться».

Модель как метеостанция

В основе системы лежит вероятностная модель, которую для простоты можно назвать «моделью переходов». Она каждую минуту смотрит на несколько признаков «погоды» в базе данных: насколько согласованно меняются скорость и ожидания, растёт ли нагрузка, падает ли скорость. Из этих признаков складывается текущее «состояние погоды». Состояний много, но они не бесконечны — как не бесконечны сочетания температуры, ветра и влажности.

Модель запоминает, какие состояния часто сменяют друг друга, а после каких чаще наступает что-то тревожное. Это похоже на опытного синоптика: он не знает будущее, но помнит, что после определённого сочетания облаков и ветра дождь случается чаще. Важная деталь: модель не помнит всё навсегда. Старые наблюдения постепенно «выветриваются», как старые прогнозы погоды, которые уже не помогают сегодня. Есть и особые, «аварийные» состояния: если система в них попала, риск считается реализованным. Прогноз на несколько минут вперёд — это, по сути, вопрос: «какова вероятность хотя бы раз попасть в тревожное состояние в ближайшее время?»

Но самое интересное начинается не с самой модели, а с сигналов-флажков. Для простоты назовём их двумя облаками на небе.

Два облака — два характера

Первое облако — «быстрое». Оно появляется чаще, реагирует оперативнее, но иногда оказывается пустым: облако есть, а дождя нет.

Второе облако — «фоновое». Оно может висеть над горизонтом долго, покрывает более широкую зону, но иногда висит почти целый день без всякого дождя.

Здесь и работает главная метафора: если идёт дождь, то на небе почти всегда есть облако; но если на небе облако, это не значит, что пойдёт дождь. Иными словами, сигналы чувствительны — они часто появляются перед проблемой, — но не всегда точны: часть срабатываний остаётся без последующей проблемы.

По данным наблюдений это видно довольно наглядно. «Быстрое» облако срабатывало чаще и в среднем в четырёх случаях из десяти действительно предвещало проблему. Причём эта доля почти не менялась от месяца к неделе: облако ведёт себя предсказуемо. «Фоновое» облако давало более широкий охват: оно «накрывало» больше проблемных случаев — примерно восемь из десяти. Но его поведение менее стабильно: в одном периоде полезных срабатываний было около трети, в другом — больше половины. И висело оно иногда очень долго: самый длинный период активности продолжался почти восемнадцать часов и повторялся в разных срезах наблюдений.

«Быстрое» облако, наоборот, обычно давало компактные предупреждения: в недельном срезе средняя длительность полезного сигнала была около двух часов, а максимальная — примерно пять часов. «Фоновое» облако в том же срезе было длиннее: в среднем около четырёх часов, а максимум всё тот же — почти восемнадцать часов. Поэтому «быстрое» облако удобнее держать на оперативном экране: оно не висит слишком долго и даёт понятное подтверждение. «Фоновое» облако полезно как широкий ранний фон, но его длительность нужно ограничивать, иначе оно превращается в «облако, которое висит неделю».

В коротком дневном наблюдении картина повторилась. «Быстрое» облако сработало девять раз, и в четырёх случаях после него действительно началась проблема. «Фоновое» — четыре раза, и в двух случаях была проблема. «Быстрое» поймало больше проблем, но и больше пустых облаков. «Фоновое» реже ошивалось, но и реже срабатывало: оно пропустило два случая, которые «быстрое» облако заметило. Среднее время упреждения у обоих — около часа. Это важная цифра: у оператора обычно есть примерно час, а иногда всего десять минут, чтобы подготовиться.

Почему облако не всегда приносит дождь

Потому что сигнал — это не сама проблема, а повышение вероятности. Модель оценивает риск, но риск — не приговор.

В крайних зонах она довольно уверенно говорит «очень тихо» или «очень тревожно». А вот в середине шкалы её оценка «может быть» требует осторожности: средние вероятности менее надёжны, чем крайние. Поэтому нельзя воспринимать каждое облако как гарантию дождя и нельзя считать, что одно универсальное правило «сработает всегда».

Есть и другая тонкость. Часть пропущенных проблем возникала не потому, что сигнал опоздал, а потому, что риск перед проблемой не рос, а стоял на месте. Это как если бы облака не сгущались, а просто висели ровно — и внезапно пошёл дождь. Кроме того, иногда важно смотреть не на сам момент начала проблемы, а на последнюю «чистую» минуту до неё: если смотреть уже под дождём, можно не увидеть, было ли облако раньше. Это методологическая, но вполне житейская тонкость.

Какой вариант выбрать?

Вывод простой: не нужно выбирать между «шумным, но чувствительным» и «точным, но редким» сигналом. Нужна комбинированная схема.

«Быстрое» облако разумно использовать как основной оперативный сигнал: у него стабильная доля полезных срабатываний — около четырёх из десяти — и компактные предупреждения.

«Фоновое» облако — как широкий ранний фон: оно покрывает больше проблем и даёт длинный запас времени, но требует ограничения длительности и регулярной проверки: если доля полезных срабатываний падает ниже примерно четырёх-пяти из десяти, его операционная ценность снижается.

Можно представить это как два уровня оповещения.

«Быстрое» облако — жёлтый уровень: «посмотрите на небо, будьте внимательны».

«Фоновое» — оранжевый: «вероятность высокая, готовьте защитные механизмы».

Вместе они дают не хрустальный шар, а надёжного синоптика, который вовремя говорит: «облака сгущаются — проверьте систему», и при этом не обещает ливень там, где его может и не быть.

В итоге вероятностная модель для базы данных — это не оракул и не гениальный предсказатель. Это метеостанция, которая каждую минуту описывает «погоду», учится на последовательностях состояний, постепенно забывает старое и выдаёт вероятностный прогноз.

Сигналы-флажки — это облака. Дождь почти всегда приходит под облаком, но облако не гарантирует дождь.

Поэтому лучшая система — не один флажок, а сочетание широкого фона и быстрого подтверждения, с честной оценкой вероятностей и регулярным наблюдением за тем, насколько облака действительно предвещают дождь.

1. Введение

Современные СУБД функционируют в условиях высокой динамики нагрузки, что требует эффективных методов раннего обнаружения деградации производительности. Традиционные подходы, основанные на статических порогах, не учитывают временную динамику и контекст. В данной работе рассматривается применение цепей Маркова для моделирования состояний СУБД и прогнозирования риска возникновения инцидентов.

Предлагаемая система реализует следующие ключевые идеи:

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

• Адаптивное забывание с учётом времени с последнего инцидента

• Многоуровневая система сигналов (SICPP, C-alone)

• Динамическое определение критических состояний на основе эмпирического риска

2. Архитектура системы

2.1. Компоненты

Система включает следующие модули:

• mchain_train_step() — ежеминутное обучение и обновление состояния.

• sicpp_calculate_at() — расчёт сигнала SICPP на заданный момент.

• mchain_hybrid_alert_at() — операционный индикатор C-alone.

• compare_profiles_at() — сравнение текущего профиля с эталоном.

• refresh_critical_states() — динамическое обновление критических состояний.

2.2. Уровни сигнализации

Система реализует трёхуровневую сигнализацию:

1. SICPP (Signal Indicating a Change in the Performance Profile) — контекстный индикатор режима, триггерит WARNING.

2. C-alone — операционный индикатор на основе risk_p90 >= 0.98 AND js_avg >= 0.14, триггерит ALARM.

3. Integral status (get_current_preincident_status()) — агрегирует все сигналы.

3. Экспериментальные результаты

3.1. Качество прогнозирования

На основе данных за период 2026-10-12 – 2026-10-26 (38 инцидентов) получены следующие метрики:

• ROC-AUC: 0.9287 — отличная дискриминация.

• Brier score: 0.0638 — хорошая калибровка.

• Покрытие SICPP: 97.4% — почти все инциденты покрыты.

• Precision эпизодов: 53.2% — умеренная точность.

• C-alone precision: 34.5% — приемлемая точность.

• C-alone recall: 51.4% — умеренная полнота.

3.2. Калибровочная кривая

• Бин вероятности [0.1–0.2]: предсказано 0.124, фактически 0.134, n = 10008.

• Бин вероятности [0.8–0.9]: предсказано 0.816, фактически 0.796, n = 588.

• Бин вероятности [0.9–1.0]: предсказано 1.000, фактически 0.998, n = 9392.

Калибровка близка к идеальной, особенно в диапазоне высоких вероятностей.

3.3. Распределение lead time

• p50, мин: ALL (raw) = 143.0; SHORT (≤800 мин) = 96.5.

• p90, мин: ALL (raw) = 987.8; SHORT (≤800 мин) = 281.5.

• mean, мин: ALL (raw) = 357.0; SHORT (≤800 мин) = 156.6.

• max, мин: ALL (raw) = 1115.0; SHORT (≤800 мин) = 777.0.

Метрики SHORT отражают «типичное» предаварийное состояние без искажения длинными эпизодами.

4. Сценарии применения

4.1. Сценарий 1: Прогнозирование инцидентов

Задача: Заблаговременно предупредить о риске возникновения инцидента.

Решение: Использование mchain_predict_risk_current_horizon() с горизонтом 120 минут.

Пример:

SELECT mchain_predict_risk_current_horizon();
-- Результат: 0.87 (высокий риск)

Интерпретация: При риске ≥ 0.90 рекомендуется активировать режим повышенного мониторинга; при риске ≥ 0.95 — рассмотреть превентивные меры.

4.2. Сценарий 2: Диагностика деградации через сравнение профилей

Задача: Обнаружить отклонение текущего режима работы от эталонного.

Решение: Использование compare_profiles_at() с JS-дивергенцией гистограмм состояний.

Пример:

SELECT unnest(compare_profiles_at(now()));
-- Результат: JS-дивергенция = 0.23, статус = CRITICAL

Интерпретация:

• JS < 0.05 — профиль соответствует эталону.

• 0.05 ≤ JS < 0.2 — умеренные отклонения (WARNING).

• JS ≥ 0.2 — значительные отклонения (CRITICAL).

4.3. Сценарий 3: Оперативное оповещение (C-alone)

Задача: Минимизировать ложные срабатывания при сохранении приемлемого recall.

Решение: Использование mchain_hybrid_alert_at() с параметрами C-only.

Пример:

SELECT alert, fired_c, risk_p90, js_avg
FROM mchain_hybrid_alert_at(now());
-- Результат: alert=true, fired_c=true, risk_p90=0.99, js_avg=0.18

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

• Precision 34.5% vs 12.5% для A∪C.

• Recall 51.4% — приемлемый уровень.

• ALERT-time 14.1% — низкая нагрузка на оператора.

4.4. Сценарий 4: Оптимизация эталонных профилей

Задача: Автоматически выбирать репрезентативные периоды для эталона.

Решение: Использование find_incident_free_window() с проверкой is_valid_baseline_window().

Критерии валидности эталонного окна:

1. Целиком в периоде продуктивной нагрузки (9:00–18:00).

2. Начинается не ранее чем через 60 мин после завершения инцидента.

3. Не пересекается с инцидентами.

4. Возраст не превышает 12 часов.

4.5. Сценарий 5: Динамическое определение критических состояний

Задача: Адаптировать список «аварийных» состояний к текущим условиям.

Решение: Использование refresh_critical_states() с эмпирической оценкой риска.

Пример:

SELECT refresh_critical_states(
p_start := now() - interval '14 days',
p_risk_threshold := 0.10,
p_min_transitions := 20
);
-- Результат: добавлено 3, удалено 1 состояние

Важно: Порог p_risk_threshold > 0.10 запрещён (тест 24 показал деградацию метрик).

Заключение

Представлена система анализа и прогнозирования производительности PostgreSQL на основе цепей Маркова.

Экспериментальные результаты демонстрируют высокое качество прогнозирования (ROC-AUC = 0.9287, Brier = 0.0638) и практическую применимость для раннего обнаружения инцидентов.

Рассмотренные сценарии применения охватывают прогнозирование, диагностику, оперативное оповещение и оптимизацию эталонов.

Дальнейшее развитие связано с расширением пространства состояний и интеграцией с современными системами мониторинга.

В рамках проекта pg_expecto разработана и внедрена система прогнозирования риска возникновения инцидентов производительности на основе цепей Маркова.

Реализация представляет собой полноценное решение, адаптированное к потоковым данным и способное к самонастройке.

Постановка задачи

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

Традиционные подходы к мониторингу, как правило, реагируют на уже возникшие проблемы, тогда как задача проактивного обнаружения предвестников сбоев требует более глубокого анализа динамики системы.

В основу предлагаемого решения положена идея дискретизации непрерывных метрик производительности в конечное множество состояний, переходы между которыми описываются марковским процессом. Это позволяет моделировать эволюцию состояния системы во времени и оценивать вероятности неблагоприятных исходов.

Формализация состояния системы

Непрерывные метрики – операционная скорость, время ожиданий и корреляция между ними – преобразуются в дискретное пространство из 189 состояний.

Каждое состояние характеризуется тремя параметрами:

• коэффициентом корреляции (21 градация от –1,0 до +1,0 с шагом 0,1),

• трендом операционной скорости

• трендом времени ожиданий (каждый принимает значения –1, 0, +1).

Такая дискретизация обеспечивает баланс между детализацией модели и вычислительной эффективностью.

Архитектура системы

Система построена по многослойному принципу:

Слой данных

Включает таблицы:

• хранения переходов (transition_log)

• накопленных частот (markov_frequencies)

• матрицы вероятностей (markov_probabilities)

• поглощающей матрицы для многошагового прогноза (markov_absorbing).

Отдельно выделены таблицы:

• конфигурации (markov_config), справочник состояний (state_descriptions) и динамический список критических состояний (critical_states).

Слой обучения

Реализует пошаговое обновление модели с частотой одна минута.

На каждом шаге выполняются:

• получение текущих метрик,

• вычисление идентификатора состояния,

• логирование перехода,

• обновление частот ,

• при необходимости, применение забывания.

Слой прогнозирования

Предоставляет функции для оценки риска на заданном горизонте.

Ключевая функция mchain_predict_risk_k_v2 вычисляет вероятность хотя бы одного попадания в критическое множество за k шагов.

Слой оценки

Включает механизмы расчёта достоверности прогнозов и суточных метрик качества.

Обучение модели и адаптивное забывание

Обучение происходит в реальном времени на потоке данных. По мере поступления новых наблюдений обновляются частоты переходов и пересчитываются вероятности. Ключевой механизм, обеспечивающий адаптацию к изменению характера нагрузки, – забывание.

Коэффициент забывания α определяет скорость, с которой устаревающие наблюдения теряют вес.

В адаптивном режиме α вычисляется по формуле:

α(t) = max(min_alpha, base_alpha · exp(-days_since_last_incident / half_life))

где days_since_last_incident – время, прошедшее с последнего попадания в критическое состояние.

Такой подход позволяет ускорить забывание после инцидентов и замедлить его в стабильные периоды. Дополнительно введён stability_factor, корректирующий α в зависимости от нестабильности вероятностей.

Важным условием применения забывания является достаточность накопленных данных. Функция mchain_check_sufficiency проверяет, что общее число переходов превышает порог min_transitions_for_forgetting (по умолчанию 5000).

Прогнозирование риска

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

Многошаговый прогноз (mchain_predict_risk_k_v2) реализует итеративное умножение вектора распределения вероятностей на матрицу переходов. На каждом шаге вероятности, попавшие в критические состояния, накапливаются в значении риска, а затем обнуляются, чтобы исключить учёт повторных попаданий. Горизонт прогноза задаётся параметром forecast_horizon_minutes в конфигурации (по умолчанию 30 минут).

Сформированные прогнозы сохраняются в таблицу prediction_log. По истечении горизонта выполняется обновление фактических исходов: для каждого прогноза определяется, произошёл ли переход в критическое состояние в течение заданного интервала.

Оценка качества и достоверности

Для оценки качества прогнозов предусмотрен комплекс метрик:

• Brier score – среднеквадратичная ошибка вероятностных прогнозов.

• Log-loss – логистическая потеря, чувствительная к уверенным неправильным прогнозам.

• MAE – средняя абсолютная ошибка.

• ECE (Expected Calibration Error) – средневзвешенное отклонение между предсказанными вероятностями и наблюдаемыми частотами.

• MCE (Maximum Calibration Error) – максимальное отклонение калибровки.

• ROC-AUC – площадь под ROC-кривой, характеризующая дискриминационную способность модели.

Достоверность прогнозов оценивается рейтингом от 0 до 5 на основе трёх факторов: общего числа переходов, стабильности вероятностей и покрытия частых состояний.

Профилирование нагрузки (версия 14)

Начиная с версии 14, система дополнена модулем профилирования нагрузки.

Этот модуль позволяет:

• Сохранять оперативные (за последние 60 минут), суточные и недельные профили производительности.

• Строить эталонные профили на основе исторических данных с исключением инцидентных окон.

• Обнаруживать аномалии путём сравнения текущих профилей с эталонными.

• Анализировать связь между отклонениями профилей и возникновением инцидентов.

Функция compare_profiles выполняет сравнение текущего профиля с эталонным, вычисляя JS-дивергенцию гистограмм состояний и формируя статус (NORMAL, WARNING, CRITICAL).

Результаты сохраняются в журнал profile_comparison_log, что позволяет проводить ретроспективный анализ.

Историческое обучение

Для первоначального построения модели предусмотрена процедура mchain_initial_train_from_history, которая обучает цепь Маркова на исторических данных, имитируя пошаговое обучение.

Это позволяет развернуть систему на основе уже накопленных метрик без необходимости ждать накопления данных в реальном времени.

Заключение

Представленная реализация цепи Маркова представляет собой законченную систему прогнозирования риска инцидентов производительности, интегрированную в экосистему pg_expecto.

Ключевые преимущества системы:

• работа в реальном времени с низкой задержкой;

• адаптация к изменению характера нагрузки благодаря механизму забывания;

• гибкая настройка горизонта прогноза и параметров обучения;

• встроенные механизмы оценки качества и достоверности;

• расширяемая архитектура, дополненная модулем профилирования нагрузки.

Система успешно применяется для мониторинга производительности СУБД и предупреждения о возможных сбоях.

Дальнейшее развитие проекта направлено на углубление аналитических возможностей и повышение точности прогнозов.