Методика адаптации марковской модели производительности СУБД: механизм «забывания»

Материал полностью подготовлен нейросетью DeepSeek

1. Назначение документа

Настоящая методика детально описывает признаки, критерии и процедуру применения «забывания» (экспоненциального сглаживания частот) в марковской цепи, моделирующей динамику корреляции «операционная скорость – ожидания СУБД».

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

2. Концепция забывания

В основе модели лежит матрица частот переходов C, которая инкрементально наполняется парами состояний (from_state, to_state). С течением времени старые наблюдения могут перестать отражать текущий режим работы системы из-за:

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

Для адаптации используется экспоненциальное забывание:

где α — коэффициент забывания, ΔC^{new} — свежие наблюдения.

На практике удобно периодически умножать все частоты на (1-α) и продолжать инкремент.

Два режима забывания:

• Плановое (регулярное) — выполняется с фиксированным интервалом и малым α (0.005–0.02). Обеспечивает плавную адаптацию.
• Форсированное (внеочередное) — запускается при обнаружении существенных изменений в поведении системы, с повышенным α (0.05–0.5). Быстро «сбрасывает» устаревшие паттерны.

3. Признаки необходимости форсированного забывания

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

3.1. Статистический дрейф распределения состояний

Суть: Сравнивается распределение посещённых состояний за последний короткий период (например, 60 минут) с эталонным распределением, характерным для данного временного интервала (например, 09:00–10:00 за последние 7 рабочих дней).

Метрики:

• Расстояние Кульбака–Лейблера (KL-дивергенция):

Нулевые вероятности в эталоне требуют сглаживания (аддитивное или абсолютное). Значение > 0.3–0.5 свидетельствует о значимом дрейфе.

• Критерий хи-квадрат:

где Oi​ — наблюдаемое число попаданий в состояние i за последний час, Ei​ — ожидаемое на основе эталонного распределения. При степенях свободы n-1 (обычно 188) пороговое значение можно взять 99-й процентили распределения хи-квадрат (например, 220 для 188 ст. св. при p=0.01). Превышение указывает на смену распределения.

Практическая реализация:

• Эталонное распределение рассчитывается агрегацией по дням с разбивкой по часовым слотам.
• Каждые 15 минут вычисляется гистограмма частот состояний за последний час, затем метрика дрейфа.
• Если KL > 0.4 или χ² > критического значения — инициируется форсированное забывание с α = max(0.1, D_{KL}).

3.2. Резкое изменение уровня операционной скорости

Суть: Выход ключевой метрики (сглаженной операционной скорости) за пределы обычного диапазона указывает на смену режима работы системы.

Процедура:

1. Для каждого часа хранится среднее и стандартное отклонение операционной скорости за последние 20 дней.
2. Каждые 5 минут рассчитывается средняя скорость за последние 20 минут (SMA20).
3. Если отклонение |SMA20 - μ_час| / μ_час > 0.30 (30%), фиксируется аномалия.
4. Если отклонение сохраняется более 10 минут, запускается форсированное забывание с α = 0.1 (или пропорционально величине отклонения).

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

3.3. Снижение точности прогнозов

Суть: Оценивается калибровка вероятностных прогнозов, выдаваемых моделью. Если прогнозы становятся неточными, модель устарела.

Метрика: Brier Score (среднеквадратичная ошибка вероятностного прогноза).

Для каждого прогноза на 1 шаг (минуту) фиксируется:

• предсказанная вероятность попасть в аварийное состояние (p),
• фактический исход (o = 1, если переход был в аварийное состояние, иначе 0).

Тогда Brier Score за окно наблюдений (например, 2 часа = 120 минут) равен:

Низкий BS (<0.15) говорит о хорошей калибровке, рост до 0.25–0.3 — о деградации модели.

Действия:

• Вести таблицу forecast_log(from_state, predicted_risk, actual_risk_flag, ts).
• Каждые 30 минут пересчитывать Brier Score по последним 120 наблюдениям.
• При BS > 0.25 выполнять форсированное забывание с α = 0.1–0.2.

3.4. Плановые или аварийные изменения в инфраструктуре

Типовые события:

• Деплой новой версии приложения.
• Изменение конфигурационных параметров PostgreSQL (shared_buffers, work_mem и др.).
• Аппаратный сбой, рестарт сервера, переключение на реплику.
• Обнаружение аномалий, нехарактерных для штатной нагрузки (например, резкий рост числа блокировок).

Реакция:

При получении сигнала от системы управления изменениями (CI/CD, мониторинг) или ручном вводе администратора вызывается принудительное забывание с высоким коэффициентом (0.3–0.5). Это гарантирует, что модель перестанет полагаться на паттерны, свойственные старой конфигурации.

3.5. Внутридневной дрейф

Суть: При обучении на едином интервале 09:00–18:00 модель усредняет поведение утра и вечера, которые могут существенно отличаться. Ближе к вечеру матрица может становиться менее точной.

Мониторинг:

• Раз в час рассчитывается распределение состояний за текущий час и сравнивается с распределением за тот же час, но с начала дня (или за последние 2–3 часа).
• Если KL-дивергенция между текущим часом и утренним эталоном превышает порог (например, 0.2), применяется локальное усиление забывания (α увеличивается на 0.02 аддитивно на следующий час).

В перспективе рекомендуется перейти к множеству временных слотов (отдельные матрицы для 09–11, 11–14, 14–18), но данная методика позволяет обойтись одной матрицей при умеренной нестационарности.

4. Автоматизация: процедура check_and_forget

Рекомендуется реализовать хранимую функцию (или внешний сервис), которая агрегирует все признаки и принимает решение о забывании.

4.1. 📋Алгоритм работы check_and_forget()

Сбор последних переходов

• Из таблицы transition_log (или из текущего состояния) извлекаются последние 60–120 пар (from_state, to_state).

Расчёт гистограммы state_counts_recent

1. Подсчитывается число появлений каждого from_state (или обоих) в окне.

Загрузка эталонного распределения

1. Из таблицы эталонов (state_baseline) для текущего часа и дня недели извлекается ожидаемое распределение частот состояний (в виде вероятностей).

Вычисление метрик дрейфа:

• KL-дивергенция,
• χ²,
• (опционально) проверка отклонения операционной скорости.

Проверка журнала прогнозов

• За последние 2 часа вычисляется Brier Score.
• Определение alpha_effective
• Базовое значение alpha = 0.0.
• Если KL > 0.4 или χ² значим: alpha += 0.1.
• Если отклонение скорости > 30%: alpha += 0.1.

1. Если BS > 0.25: alpha += 0.1.
2. Если было инфраструктурное событие: alpha = max(alpha, 0.3).
3. Итоговое alpha ограничено сверху 0.5.

Выполнение забывания

• Вызов apply_forgetting(alpha_effective):sqlUPDATE markov_frequencies SET frequency = frequency * (1 - alpha_effective);
• DELETE FROM markov_frequencies WHERE frequency < 1e-6;
• После чего перестраиваются markov_probabilities и markov_absorbing.

Логирование

• В таблицу forget_log записывается временная метка, значение alpha, перечень сработавших признаков, KL-дивергенция, BS и т.д.

4.2. Периодичность вызова

• 📋Плановая проверка — каждые 15 минут.
• Внеочередной вызов — по триггеру инфраструктурных событий.

5. Практические рекомендации

• 📋Начальное обучение: До запуска автоматического забывания модель должна быть обучена на исторических данных за 4–6 недель. Это обеспечит стабильную базу, к которой будет применяться адаптация.
• Калибровка порогов: Первые 1–2 недели эксплуатации следует вести мониторинг метрик дрейфа без автоматического вмешательства, чтобы подобрать адекватные пороги для конкретной системы.
• Борьба с ложными срабатываниями: Не применять форсированное забывание по одиночному незначительному превышению порога; использовать подтверждение (например, дрейф сохраняется два цикла подряд).
• Ручное управление: Предусмотреть возможность ручного запуска apply_forgetting(alpha) администратором для немедленной реакции на известные изменения.

6. Пример реализации в PostgreSQL

6.1. Вспомогательные таблицы

-- Журнал забываний

CREATE TABLE forget_log (

ts TIMESTAMPTZ DEFAULT now(),

alpha REAL,

reason TEXT[],

kl_div REAL,

brier_score REAL

);

-- Журнал прогнозов для расчёта Brier Score

CREATE TABLE forecast_log (

ts TIMESTAMPTZ DEFAULT now(),

from_state SMALLINT,

predicted_risk REAL,

actual_risk SMALLINT -- 0 или 1

);

6.2. Функция apply_forgetting

CREATE OR REPLACE FUNCTION apply_forgetting(alpha REAL)

RETURNS void LANGUAGE sql AS $$

UPDATE markov_frequencies SET frequency = frequency * (1.0 - alpha);

DELETE FROM markov_frequencies WHERE frequency < 1e-6;

-- После обновления частот пересчитываем вероятности и поглощающую матрицу

PERFORM rebuild_markov_probabilities(); -- должна быть реализована

PERFORM rebuild_markov_absorbing();

$$;

6.3. Упрощённый скетч check_and_forget

CREATE OR REPLACE FUNCTION check_and_forget()

RETURNS void LANGUAGE plpgsql AS $$

DECLARE

kl REAL;

brier REAL;

os_dev REAL;

alpha_eff REAL := 0.0;

BEGIN

-- 1. Расчет KL-дивергенции (пример для 60 последних переходов)

SELECT COALESCE(kl_divergence(...), 0.0) INTO kl; -- пользовательская агрегатная функция

-- 2. Отклонение скорости (используем внешнее получение)

os_dev := get_os_deviation(); -- может обращаться к таблице метрик

-- 3. Brier Score за последние 2 часа

SELECT AVG((predicted_risk - actual_risk)^2) INTO brier

FROM forecast_log

WHERE ts >= now() - INTERVAL '2 hours';

-- Определяем alpha

IF kl > 0.4 THEN alpha_eff := alpha_eff + 0.1; END IF;

IF os_dev > 0.3 THEN alpha_eff := alpha_eff + 0.1; END IF;

IF brier > 0.25 THEN alpha_eff := alpha_eff + 0.1; END IF;

IF alpha_eff > 0.0 THEN

PERFORM apply_forgetting(LEAST(alpha_eff, 0.5));

INSERT INTO forget_log (alpha, reason, kl_div, brier_score)

VALUES (LEAST(alpha_eff, 0.5),

ARRAY[

CASE WHEN kl>0.4 THEN 'KL' ELSE NULL END,

CASE WHEN os_dev>0.3 THEN 'OS' ELSE NULL END,

CASE WHEN brier>0.25 THEN 'Brier' ELSE NULL END

],

kl, brier);

END IF;

END;

$$;

Конкретная реализация функций kl_divergence и сбор гистограмм оставлены для детальной проработки в зависимости от инфраструктуры.

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

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