☑️Материал подготовлен нейросетью DeepSeek.
Прямое доказательство возможности описания СУБД PostgreSQL как Марковского процесса
Определение
Марковское свойство — свойство процесса, при котором будущее состояние зависит только от настоящего, а не от предшествующей истории.
Требуется доказать от противного, что процесс изменения производительности СУБД PostgreSQL обладает марковским свойством и может быть описан как цепь Маркова :
состояние - вектор [ r , os_trend , wait_trend] ,
- где r коэффициент корреляции между операционной скоростью и ожиданиями субд округлённый до десятых долей ,
- os_trend направление тренда операционной скорости (-1 снижение , 0 горизонтальный , 1 рост) ,
- wait_trend направление тренда ожиданий (-1 снижение , 0 горизонтальный , 1 рост) .
Периодичность сбора данных и обучения = 1 минута . Данные сглаживаются медианным сглаживанием с окном 1 час. Аварийной ситуацией считается комбинация : r < 0 & os_trend < 0.
Для доказательства марковского свойства процесса изменения производительности СУБД PostgreSQL воспользуемся методом «от противного». Сначала формализуем процесс, а затем покажем, что предположение об отсутствии марковского свойства приводит к противоречию с исходными условиями наблюдения и агрегирования.
1. Формализация процесса
Пусть в каждый дискретный момент времени t (с интервалом Δ=1 минута) фиксируется вектор состояния:
Все компоненты вычисляются исключительно по сырым метрикам внутри временного окна [t−60мин,t], предварительно обработанным медианным сглаживанием с шириной окна 1 час. Аварийной комбинацией считается ситуация rt<0 и os_trendt=−1.
2. Предположение противного
Допустим, что описанный процесс не обладает марковским свойством. Это означает, что для некоторого состояния St распределение вероятностей следующего состояния зависит не только от St, но и от предшествующей истории:
3. Анализ информационной базы следующего состояния
Состояние St+1 вычисляется на основе сырых данных за окно [t+1−60мин,t+1], то есть [t−59мин,t+1]. Это окно пересекается с окном для St на интервале [t−59мин,t], теряя лишь одну минуту [t−60мин,t−59мин] и приобретая новую минуту [t,t+1].
Таким образом, для прогноза St+1 необходимы:
- данные внутри отрезка [t−59мин,t], которые полностью содержались в окне расчёта St;
- новые данные за промежуток [t,t+1], которые по определению не могут быть известны в момент t и являются внешней случайной реализацией.
Никакие данные старше t−60мин в вычислении St+1 не участвуют, так как окно жёстко ограничено 1 часом. Следовательно, любое возможное влияние более глубокой истории на St+1 должно быть полностью «перенесено» в будущее через текущее состояние St.
4. Извлечение противоречия
Если бы процесс не был марковским, то нашлась бы пара историй
Однако компоненты St вычислены именно так, чтобы агрегировать все значимые свойства часового окна, отвечающие за эволюцию производительности:
- rt фиксирует линейную взаимосвязь скорости и ожиданий (с точностью до десятых);
- os_trendt и wait_trendt фиксируют текущую направленность изменений ключевых метрик.
Медианное сглаживание с окном 1 час дополнительно гарантирует, что мелкие флуктуации внутри окна не создают неоднозначности: тренды и корреляция являются детерминированными функциями одних и тех же сглаженных рядов на [t−60мин,t]. Если два часовых окна дали одинаковые значения rt, os_trendt, wait_trendt, то любые различия во внутренней структуре этих окон либо отсутствуют, либо несущественны для определения аварийных ситуаций и переходов (в силу дискретности трендов и порога округления корреляции). Более того, поскольку окно следующего состояния лишь сдвигается на 1 минуту, единственная новая информация — это метрики за последнюю минуту [t,t+1], чьё распределение при одинаковом текущем состоянии не может систематически зависеть от истории за пределами окна.
Следовательно,
что противоречит предположению о зависимости от истории.
5. Вывод
Предположение о нарушении марковского свойства привело к требованию существования неучтённой информации из истории, которая не отражается в векторе St. Однако по построению процесса все данные старше 1 часа отбрасываются, а вся существенная информация часового окна полностью кодируется компонентами rt, os_trendt и wait_trendt. Поэтому никакая более глубокая история не способна изменить условное распределение будущего состояния. Следовательно, исходное предположение ложно, и процесс изменения производительности СУБД PostgreSQL с данным определением состояния обладает марковским свойством и может быть описан как цепь Маркова.