Я в обработке цифровых сигналов от детекторов, чтобы вычесть подложку использую медиану, она в этом плане очень устойчива.
Спасибо за комментарий. Я пока для статистического анализа производительности СУБД так же использую медиану.
А вот для статистического анализа результатов бенчмарков , подсказывают правильнее использовать среднее. Хотя, честно говоря, пока не могу уловить принципиальную разницу. Если между бенчмарками есть разница то она проявится и для среднего и для медианы.
график с выбросом показывает отрезок от 2989 до 4989+ по оси OY. Сглаженные графики показывают отрезки 4727-4757 и 4877-4927. Их же невозможно так сравнивать. Стоило привести их к одному масштабу.
Да мысль вполне понятна. Замечание принимается. Дополню графики, и добавлю еще показания и на рабочей нагрузке тоже. Там значения скачут очень существенно.
Ну манипуляция то вполне себе заметна. Я давно на это внимание обратил.
В общем то проблем никаких, так, очередной казус на тему "Еслибыотвыборовчто-тозависело, тонамбынепозволиливнихучаствовать "(c)
Если посчитать процент отклика(отношение голосов к количеству просмотров) то цифры получаются порядка 0.05% ;-) В основном читателям глубоко фиолетово и они вообще никак не реагируют на любые статьи.
У вас на графиках разные точки отсчета. Ну нельзя же так.
Спасибо за комментарий!
Если на одном графике смотреть - то картина получается сильно другая. Особей разницы на одном масштабе между скользящей средней и скользящей медианой - нет.
Но в данном случае дисперсия значений не сильно меняется по ходу наблюдений. А вот если данные сильно скачут, то картина в разнице будет сильнее заметна.
Прошу , прощения , просьба уточнить . Что значить "разные точки отчёта "?
Еще медиану в окне немного сложнее считать.
В чем сложность отсортировать набор данных ?
Медиана в статистике — это значение, которое делит упорядоченный набор данных на две равные части. Другими словами, половина значений в наборе данных меньше медианы, а другая половина — больше. 1
Чтобы вычислить медиану, сначала нужно упорядочить данные. Затем, если количество значений в наборе данных нечётное, медианой будет значение, которое находится ровно посередине. Если количество значений чётное, медианой будет среднее арифметическое двух центральных значений. 1
Пример вычисления медианы: предположим, есть следующий набор данных: {1, 2, -2, 4, -3}. Чтобы найти медиану, сначала упорядочивают данные: {-3, -2, 1, 2, 4}. Так как количество значений в наборе данных нечётное (5), медианой будет значение, которое находится ровно посередине, то есть 1.
Чтобы найти медиану в PostgreSQL, можно использовать функцию percentile_cont.
Пример запроса:
SELECT percentile_cont (0.5) WITHIN GROUP (ORDER BY sales) FROM table;
Спасибо за информацию. Принято, посмотрю внимательнее , наверняка будут вопросы для уточнения. А пока
Задача не очень понятна
...
Ну и цель надо поконкретнее ставить
Задача - имеется СУБД в облачной инфраструктуре , влияние внешних факторов и посторонней нагрузки на производительность существенно , постоянно и случайно. Необходим анализ тенденции , а не реагирование на постоянные аномалии, вызванные как внутренними так и внешними причинами.
Если же ставить вопрос более широко - есть 2 задачи:
1) Статистический анализ бенчмарков (постоянная нагрузка в условиях нестабильной инфраструктуры).
2) Корреляционный анализ ожиданий СУБД (случайная нагрузка в условиях нестабильной инфраструктуры).
И в первом и во втором случае анализируются сглаженные данные . Как выглядят неслаженные данные для второй задачи, наверное представляете .
Мы у себя (не СУБД!) просто исключаем выбросы
Что является критерием выброса ? Z-оценка ? Превышение среднего ? Что то еще ?
Но тут важна физика: в чем причина выбросов?
Эх.... Если бы это удалось установить . Период сбора данных = 1 минута. Период семплирования ожиданий СУБД =10ms. У меня пока нет инструментов для сбора статистики для периода менее 1 минуты.
ORM не согласен. Да, запросы вида SELECT id; SELECT * WHERE id IN (1,2,3) — они не самые оптимальные, но, как правило, далеко не критично влияют на производительность
А если IN ( 1,2,3.... 1000, 1001)?
Я такие запросы и удивление разрабов - "ну почему ваш postgres так медленно работает ? " - видел.
Предлагаю проверить, как формируются входные данные до медианного сглаживания. Как они рассчитываются? Может ли так быть, что входные данные в ходе вычислений грубо округляются? Или по каким-то другим причинам принимают только значения из небольшого дискретного множества?
Ок, принято. Исходные данные есть , функции построения скользящих средних - в наличии. Осталось построить график скользящих средних и сравнить скользящими медианами на одинаковых входных данных.
Первый вопрос: какая ожидается зависимость, линейная или нелинейная?
Гипотеза- зависимость производительности от значения конфигурационного параметра носит логарифмический характер .
Сейчас набираю данные .
Я так подозреваю, что либо исследуемый параметр нельзя увеличивать до бесконечности и тем самым добиваться бесконечного роста производительности, так?
Изменять значение можно практически до бесконечности . и тут 2 варианта - либо начиная с какого то значения изменение не будет влиять на производительность , либо будет обратная зависимость и есть наиболее оптимальное значение . Пока неизвестно , работ по математическому анализу производительности СУБД не встречал , а своих данных маловато.
Впрочем, на начальном своем участке ее, вероятно, можно приближенно считать линейной.
Скорее всего да .
Проблема в том, что математической модели СУБД - нет .
А сбор наблюдений экспериментов требует время. Но работа идёт .
По крайней мере сейчас есть механизм сбора и анализа статистических данных .
Стало быть поторопился. Просто уже столько раз натыкался на попытки перенести логику СУБД на уровень приложения , что уже стойкая настороженность возникает.
Ок. Попробую дочитать.
Эх , если бы современные разрабы это читали и руководствовались затем в реальной жизни
Что бы вы ни выбрали, обязательно проводите нагрузочные тесты, чтобы увидеть, как ваш код работает под нагрузкой. Это поможет избежать неприятных сюрпризов в продакшене, когда резко возрастет трафик.
По личному опыту - "неприятные сюрпризы в продакшене" возникают в 100% . Если нагрузка на информационную систему средняя или высокая.
обратите внимание на добавленный оператор FOR UPDATE в SELECT. Он блокирует строку, чтобы другие SELECT запросы ждали завершения транзакции. Это позволяет правильно обрабатывать параллельные запросы.
И получить High load и "мы упёрлись в СУБД" на ровном месте .
Сорри, но дальше не стал читать . Потому, что на обсуждение с разрабами темы "вы зачем используете select for update и потом приходите в отдел администрирования баз данных с жалобами "у нас все тормозит" ? ", было потрачено сколько нервов , времени и бесполезных разговоров, что не хочется опять вспоминать.
если применить любой из критериев сравнения (Стьюдента или Вилкоксона) - то будет получен явно положительный результат, подтверждающий влияние исследуемого параметра на данные. Но при таких явных результатах применять какие-то критерии излишне. Разве только для отчета.
То, что изменение параметра оказывает качественное влияние это понятно изначально. Хотелось бы оценить влияние количественно. Например - изменение параметра на 50% приведет к росту производительности на 10%. Что, то типа такого, в идеале.
если составить выборку из данных приведенного вами графика - то нормального распределения не получилось бы.
Да это именно так. Именно поэтому я начал анализировать не всю выборку в целом за весь период эксперимента а искать фрагменты в течении которых влияние внешних факторов минимально и распределение будет максимально близко в нормальному.
На этом этапе допустимо принимать произвольные решения по отбрасыванию кусков данных без строгого обоснования.
Проблема , вот в чем - для данной ситуации график выглядит так, для других входных данных будет несколько по другому. Поэтому оценки на глаз очень не хотелось бы использовать.
Решения принимаются чисто интуитивно, на основе прошлого опыта.
В этом то и проблема - нет никакого прошлого опыта. Работ по статистическому анализу производительности СУБД , я пока не нашел. Поэтому все эти опыты и эксперименты это наугад. Ну например до недавнего времени графики выглядели сильно иначе. Например так:
Пример сглаженные данных
Но там была проблема в сценарии теста. Хотя , в итоге используя описанную методику ( поиск интервалов с "нормальным" распределением) результаты были вполне ожидаемые.
Ну, а если отбрасывание данных не поможет - то вернуть все назад и думать дальше.
Если бы еще обосновать критерий отброса данных ? То данное предложение не вызвало бы вообще никаких сомнений.
"Округление не проводится" - где-то проводится, иначе не было бы тенденции к формированию горизонтальных линий на графике. Возможно, это исходные (несглаженные) данные округляются.
...
Можно проверить, как формируются исходные данные. Нет ли там излишних округлений?
Данные округляются например , при расчете медианы
percentile_cont ( fraction double precision ) WITHIN GROUP ( ORDER BY double precision ) → double precision
Или использовать для сглаживания скользящее среднее, а не медиану. Там на выходе будут промежуточные значения.
В самом начале работ именно скользящее среднее и использовалось. Отказался, очень много выбросов . Проанализировать тенденцию практически невозможно.
Ну и то, что мы наблюдаем в ваших графиках: если исходные данные принимали только значения из небольшого дискретного множества - то только такие останутся и после медианы;
Именно это и хотелось получить на этапе анализа . Задача проанализировать тенденции, а не получить оповещение о аномалии.
Например: наличие явных выбросов в данных, которые сильно портят результаты на скользящем среднем.
Ок. Принято. Попробую найти старые данные или сгенерирую новые используя скользящее среднее. Например - 2 одинаковых эксперимента с одинаковыми входными данными но разным сглаживанием - по скользящей средней и по медиана.
Спасибо за комментарий. Я пока для статистического анализа производительности СУБД так же использую медиану.
А вот для статистического анализа результатов бенчмарков , подсказывают правильнее использовать среднее. Хотя, честно говоря, пока не могу уловить принципиальную разницу. Если между бенчмарками есть разница то она проявится и для среднего и для медианы.
Добавил график реальных данных , с реальными выбросами.
Да мысль вполне понятна. Замечание принимается. Дополню графики, и добавлю еще показания и на рабочей нагрузке тоже. Там значения скачут очень существенно.
Ну манипуляция то вполне себе заметна. Я давно на это внимание обратил.
В общем то проблем никаких, так, очередной казус на тему "Если бы от выборов что-то зависело, то нам бы не позволили в них участвовать "(c)
Если посчитать процент отклика(отношение голосов к количеству просмотров) то цифры получаются порядка 0.05% ;-) В основном читателям глубоко фиолетово и они вообще никак не реагируют на любые статьи.
Так, что очередная цифра ниочем.
Ясно, примерно так и предполагал. "Все равны, но некоторые равны более других "(с)
Спасибо за комментарий!
Если на одном графике смотреть - то картина получается сильно другая. Особей разницы на одном масштабе между скользящей средней и скользящей медианой - нет.
Но в данном случае дисперсия значений не сильно меняется по ходу наблюдений. А вот если данные сильно скачут, то картина в разнице будет сильнее заметна.
Дополню статью. Спасибо.
Прошу , прощения , просьба уточнить . Что значить "разные точки отчёта "?
В чем сложность отсортировать набор данных ?
Спасибо за информацию. Принято, посмотрю внимательнее , наверняка будут вопросы для уточнения. А пока
Задача - имеется СУБД в облачной инфраструктуре , влияние внешних факторов и посторонней нагрузки на производительность существенно , постоянно и случайно. Необходим анализ тенденции , а не реагирование на постоянные аномалии, вызванные как внутренними так и внешними причинами.
Если же ставить вопрос более широко - есть 2 задачи:
1) Статистический анализ бенчмарков (постоянная нагрузка в условиях нестабильной инфраструктуры).
2) Корреляционный анализ ожиданий СУБД (случайная нагрузка в условиях нестабильной инфраструктуры).
И в первом и во втором случае анализируются сглаженные данные . Как выглядят неслаженные данные для второй задачи, наверное представляете .
Что является критерием выброса ? Z-оценка ? Превышение среднего ? Что то еще ?
Эх.... Если бы это удалось установить . Период сбора данных = 1 минута. Период семплирования ожиданий СУБД =10ms. У меня пока нет инструментов для сбора статистики для периода менее 1 минуты.
Ещё рас спасибо за наводку . Буду смотреть .
А если IN ( 1,2,3.... 1000, 1001)?
Я такие запросы и удивление разрабов - "ну почему ваш postgres так медленно работает ? " - видел.
Обычно лог продуктивной СУБД это мегабайты . Как искать проблемную строку?
И самое главное .
Это ведь искусственный пример. В реальности так не бывает.
Как искать проблемный запрос ?
Пример формирования скользящей средней и медианного сглаживания
https://habr.com/p/848818/
Было такое . Давно правда во времена пандемии , подозреваю после дискуссий с антиваксерами . Слишком уж совпало по времени .
Делал - ничего . Отключил уведомления в службе смс , а ночью у меня по расписанию телефон на режиме "не беспокоить". Так, что проблем не было.
Не стал жаловаться и вообще сообщать об инциденте на форумах, пабликах. Может поэтому уроды сдулись через денек, другой .
Ок, принято. Исходные данные есть , функции построения скользящих средних - в наличии. Осталось построить график скользящих средних и сравнить скользящими медианами на одинаковых входных данных.
Гипотеза- зависимость производительности от значения конфигурационного параметра носит логарифмический характер .
Сейчас набираю данные .
Изменять значение можно практически до бесконечности . и тут 2 варианта - либо начиная с какого то значения изменение не будет влиять на производительность , либо будет обратная зависимость и есть наиболее оптимальное значение . Пока неизвестно , работ по математическому анализу производительности СУБД не встречал , а своих данных маловато.
Скорее всего да .
Проблема в том, что математической модели СУБД - нет .
А сбор наблюдений экспериментов требует время. Но работа идёт .
По крайней мере сейчас есть механизм сбора и анализа статистических данных .
Стало быть поторопился. Просто уже столько раз натыкался на попытки перенести логику СУБД на уровень приложения , что уже стойкая настороженность возникает.
Ок. Попробую дочитать.
Эх , если бы современные разрабы это читали и руководствовались затем в реальной жизни
По личному опыту - "неприятные сюрпризы в продакшене" возникают в 100% . Если нагрузка на информационную систему средняя или высокая.
1) А уровни изоляции зачем придумали ?
2)
И получить High load и "мы упёрлись в СУБД" на ровном месте .
Сорри, но дальше не стал читать . Потому, что на обсуждение с разрабами темы "вы зачем используете select for update и потом приходите в отдел администрирования баз данных с жалобами "у нас все тормозит" ? ", было потрачено сколько нервов , времени и бесполезных разговоров, что не хочется опять вспоминать.
Именно так и гордо назвать это - "мы теперь используем микросервисную архитектуру "
И даже ещё чуть чуть , невозможного.
Поначалу удивляло, потом смешило. Теперь просто не обращаю внимания.
Ибо:
https://youtu.be/F2skk6RFFos?si=v1AFho3PWGfTSUX7
https://youtu.be/ir5rj2yYH_8?si=v1RzSMz83jlGQAYS
То, что изменение параметра оказывает качественное влияние это понятно изначально. Хотелось бы оценить влияние количественно. Например - изменение параметра на 50% приведет к росту производительности на 10%. Что, то типа такого, в идеале.
Да это именно так. Именно поэтому я начал анализировать не всю выборку в целом за весь период эксперимента а искать фрагменты в течении которых влияние внешних факторов минимально и распределение будет максимально близко в нормальному.
Проблема , вот в чем - для данной ситуации график выглядит так, для других входных данных будет несколько по другому. Поэтому оценки на глаз очень не хотелось бы использовать.
В этом то и проблема - нет никакого прошлого опыта. Работ по статистическому анализу производительности СУБД , я пока не нашел. Поэтому все эти опыты и эксперименты это наугад. Ну например до недавнего времени графики выглядели сильно иначе. Например так:
Но там была проблема в сценарии теста. Хотя , в итоге используя описанную методику ( поиск интервалов с "нормальным" распределением) результаты были вполне ожидаемые.
Если бы еще обосновать критерий отброса данных ? То данное предложение не вызвало бы вообще никаких сомнений.
Данные округляются например , при расчете медианы
В самом начале работ именно скользящее среднее и использовалось. Отказался, очень много выбросов . Проанализировать тенденцию практически невозможно.
Именно это и хотелось получить на этапе анализа . Задача проанализировать тенденции, а не получить оповещение о аномалии.
Ок. Принято. Попробую найти старые данные или сгенерирую новые используя скользящее среднее. Например - 2 одинаковых эксперимента с одинаковыми входными данными но разным сглаживанием - по скользящей средней и по медиана.