опыты 1) и 2) проводились в одно и то же время суток - то можно вычесть второй график из первого. Если предположить, что суточные колебания одинаково действовали на результат в случаях 1) и 2) - то их разность не должна иметь ярко выраженного тренда
Разница между показателями первого и второго опыта
Я работаю в другой области знаний, и поэтому многие вещи, очевидные для СУБДшника, для меня неочевидны. Отвечаю вам лишь в рамках своих скромных познаний общей теории обработки данных и статистики. Так что прошу простить, если где-то что-то очевидное для вас не усмотрел.
Самое главное большое спасибо за комментарии. Первая статья на тему статистического анализа была опубликована 8-го июля. И сегодня первый день когда были получены действительно полезные комментарии и обратная связь. Проблема в том, что DBA забыли/или не знают математики и не используют математический аппарат в своей работе. Я когда начал копать очень удивился , что практически ничего не удавалось найти. Почему, так, наверное тема другого исследования и других исследователей.
Вернемся к теме.
что есть горизонтальная ось? Это время?
Да это время. Или если совсем точнее номер минуты когда были получены данные по производительности СУБД .
Если так, то очевидно наличие тренда в ваших данных.
Это в общем то было и понятно, даже есть отдельны индикатор тренда. Именно с этого и начались проблемы в свое время. Я делаю замеры в разное время и получаю совершенно разные изменения производительности в зависимости от изменения параметра.
Вопрос - как влияет параметр на производительность ?
Моделировать его линейной функцией вряд ли поможет.
Именно к такому выводы я и пришел. Хотя больше на основе наблюдений, а не теоретических изысканий.
Если опыты 1) и 2) проводились в одно и то же время суток - то можно вычесть второй график из первого.
Опыты всегда проводятся в одно и тоже время. Хорошо этот вариант проверить проще всего, таблицы Excel под рукой . Прям сейчас почитаю и дополню комментарий.
Судя по рисункам, до горизонтальной отметки 100 возможно наличие остаточного тренда в разности. Этот участок можно просто обрезать, если остальная часть данных будет в порядке.
Извините , но мне этот подход непонятен. Что значить обрезать? Почему обрезать 100, не 150, не 200 не 50 ? Как решать - какие данные обрезать и сколько ?
Что мне еще бросилось в глаза на ваших рисунках - точки имеют тенденцию собираться в горизонтальные линии. Это обычно означает, что данные в ходе расчетов чрезмерно округляются, загрубляются.
Округления не проводится. Проводится медианное сглаживание. Т.е. Значением за точку T считается медиана отрезка (T , T - период сглаживания) . С целью как раз таки, исключить влияние выбросов. По моему это вполне нормально - среднее вероятное значение не сильно меняется и необходимы существенные причины для изменения значения. Шум не оказывает сильного влияния.
Математики говорят, что среднее арифметическое не является робастным. Это значит, что оно не устойчиво к выбросам. Хватит одного-единственного экстремально большого значения, чтобы полностью испортить результат.
При обсуждении этой проблемы классическое простое решение заключается в использовании медианы.
Если вы берете как элементы выборки (для критерия Стьюдента) усредненные данные за 1 час - то для устранения влияния суточных колебаний вся выборка (из 10 значений) должна содержать только элементы, полученные от измерений в одно и то же время суток. Скажем, 18:00-19:00.
Здесь вопросов нет. Есть промежуток времени 10 часов между - 19:00 - 09:00. Подготовлю таблицу c усредненными значениями результатов эксперимента 1 и эксперимента 2 . за одинаковые часы. Т.е 19:00-20:00 , 20:00-21:00 ... 08:00 - 09:00
У вас на сглаженных графиках наблюдаются суточные колебания?
Конечно. Это же работающая инфраструктура, к тому же в облаке. Не отдельно стоящий физический сервер на котором кроме ОС и СУБД ничего нет.
Вот сглаженные данные по эксперименту 1
Эксперимент 1
Вот сглаженные данные по эксперименту 2
Эксперимент 2
Наличие в данных тренда убивает многие статистические методы. Поэтому важно обеспечить отсутствие тренда.
Судя по всему, если я правильно понимаю - тренд есть и это проблема ?
Широко распространены методы моделирования линейного тренда - то есть линейной функции.
Это я пытался сделать в самом начале. Но не довел до результата.
Если не сложно, хотелось бы сверится , что я правильно понимаю предлагаемую идею.
Результаты собираться каждую минуту. Берем период 1 час, считаем среднее арифметическое и принимаем это значение как результат за данный час.
Накопите несколько (скажем, 10) таких усредненных результатов. Это будет первая выборка A. Потом повторите эксперимент при другом значении исследуемого параметра - получите выборку B. К ним уже применим критерий Стьюдента для сравнения.
Это довольно просто сделать, исходные данные экспериментов есть. Достаточно будет простой таблицы Excel. Сегодня проверю.
Предложение в работе . При чем , самое хорошее в том, что особо переделывать ничего не требуется , неслаженные данные у меня уже есть. Нужно просто новый отчет сделать. Результаты будут опубликованы .
Сорри, не могу поставить плюс и в карму . Спасибо , ещё раз.
Сначала вы пишете, что предполагаете распределение показаний нормальным. Потом вы обрабатываете данные, пытаясь установить, является ли распределение нормальным, и далее действуете с учетом этого.
Уточню. Я лишь выдвигаю гипотезу о том, что распределение производительности СУБД в нормальных/идеальных условиях будет нормальным. В условиях реальной облачной инфраструктуры влияние внешних факторов на СУБД - случайно, неуправляемо и непрогнозируемо. Если сравнивать статистические показатели за разные периоды то распределения будут сильно разные - мультимодальные, несимметричные с разными коэффициентами эксцесса . Проблема в том, что нужно выбрать значение которое будет считаться - результатом эксперимента. Следовательно сделан вывод - при минимальном влиянии внешних факторов распределение будет приближаться к нормальному и уже можно сравнивать значения на отрезках при которых распределение похоже на нормальное.
В статистике обычно так не делают. Там или предполагают, что данные распределены нормально
Так не получится. В реальном мире нормального распределения не будет. А сравнивать результаты экспериментов нужно.
Далее, вы выбираете одно число
Это не отдельное число это значение моды(медианы) на отрезке в котором распределение максимально близкое к нормальному по используемым критериям. Возможно в дальнейшем будут использованы классические статистические тесты, пока сильно упрощенно - ищу отрезок с унимодальным распределение, в котором медиана = мода и модуль вектора ( коэффициент симметрии , коэффициент эксцессам ) минимальный.
данные, полученные из опытов, где есть хоть какие-нибудь случайные погрешности, почти всегда (с вероятностью 1) будут не равны между собой. Даже если эксперимент был повторен в полностью идентичных условиях.
Именно так. Но границы этих погрешностей не превышают 1-2% , что для данной практической задачи - полностью устраивает.
Во-первых, я предлагаю отказаться от сглаживания данных. Статистические методы могут извлечь максимум информации именно из несглаженных данных.
Просьба уточнить чуть подробнее почему . Какую информацию можно получить ? Если нужно, могу предоставить графики сглаженных и несглаженных значений. Какая дополнительная информация может быть получена из анализа несглаженных значений ?
Позволяет оценить, влияет ли ваш параметр вообще хоть как-нибудь на поведение вашей системы.
Спасибо за предложение, эта тема есть в планах, но чуть на будущее, для анализа корреляции ожиданий СУБД . В данном случае, задача чуть другая - какие значения будет считаться результатом эксперимента.
Если выяснится, что ваш параметр статистически значимо влияет на результаты измерений
Только есть одна очень серьезная проблема - таких параметром очень много(порядка 400) и на текущем момент не понятно, являются ли все эти параметры независимыми или нет.
Данный подход к определению результатов экспериментов может быть допустимым в определенных случаях
Уже за это - большое человеческое спасибо. Это первый комментарий на Хабре по делу. Спасибо.
стоит учитывать, что использование только одного критерия (мода = медиана)
Это только один из критериев . Второй критерий - минимальное значение модуля вектора ( коэффициент симметрии , коэффициент эксцесса ) .
По поводу статистических методов для проверки нормальности распределения , да , такая мысль была, и пока она не отброшена. Однако очень важный вопрос - данные проверки сравнительно сложны в реализации , по сравнению с используемыми в настоящее время . Имеет ли смысл настолько усложнять , если результат будет такой же? Но соглашусь, надо проверить. С первого раза, да не получилось быстро реализовать, результат нужен был как можно быстрее. Теперь результат получен, можно усовершенствовать.
может привести к недостоверным результата
Что значить недостоверный результат ? Значение полученное по описанной выше методике не может считаться статистически достоверным результатом эксперимента ?
получается два столбца значений: предполагаемое действие фактора и предполагаемый результат.
Чуть уточню. В итоге получается таблица из 2-х столбцов
1) Значение фактора (неизменно в одном эксперименте)
2) Значение результата ( случайная величина , меняется в очень широком диапазоне)
Задача
1) Как сравнить столбец 2 для разных экспериментов с разными значениями фактора.
Т.е. необходимо определить не то действует или нет фактор на результат а как изменение фактора влечет за собой изменение результата? Качественно и количественно.
Статья не про параметр bgwriter_lru_maxpages вообще то.
Статья о том, как выбрать значение которое можно будет считать результатом бенчмарка для дальнейшего сравнительного анализа влияния изменений параметра/параметров на производительность СУБД, в условиях облачной инфраструктуры.
Это лишь метод, конкретный параметр и его влияние - просто для примера. Вполне можно было в тексте статьи изменить "bgwriter_lru_maxpages" на "параметр X". Смысл статьи бы не изменился.
Бывает такое, что на вашем проекте есть эксперт, от которого вам надо получить ОК на документацию, или чтобы он сделал важную работу, которая находится на критическом пути проекта. И, внезапно, этот эксперт делать вашу свою работу и давать вам ОК вообще не торопится. Что с ним делать?
Давным давно, лет 30 назад один друг сказал фразу, смысл и истинность которой , подтверждались и подтверждаются потом регулярно : "когда человек становится незаменимым, от него надо избавляться."
Т.е. если ситуация дошла до описанной в самом начале статьи это косяк и глобальный залёт руководителя .
Что на концептуальном уровне мешает микросервисам использовать общую СУБД?
Всего 3 слова : "конкуренция за ресурсы". Или другими словами один микросервис влияет на все остальные . Если это считается "микросервисной архитектурой", пусть. Для DBA разницы никакой .
Для микрорешений для 1-10 пользователей и десятком TPS , это вполне работает и они это называют "микросервисы" и очень гордятся.
Когда начинается взрослая работа с сотнями активных сессий и тысячами TPS , начинается ожидаемое "спасите помогите , мы уперлись в СУБД".
Появился новый микросервис - появились новые таблицы в общей БД.
Ну и банально, сорри за повторение - вся идея о микросервисах не имеет никакого смысла , если все эти "микросервисы" взаимодействуют с общей СУБД.
Пока , я только такие решения встречал. Возможно , в природе есть и другие решения. Но пока архитекторы просто выделяют отдельную БД все кластере и называют это - "мы реализовали микросервисную архитектуру".
такие приложения легче тестировать и обновлять, так как изменения в одном сервисе не влияют на другие, что делает микросервисную архитектуру идеальным выбором для сложных и динамичных приложений, требующих высокой доступности и адаптивности.
Все это верно только в одном случае - каждый микросервис взаимодействует со своим экземпляром/инстансом СУБД.
Современные архитекторы и разработчики почему то считают микросервисной архитектурой решение когда множество сервисов работает в одной СУБД. Что влечет за собой множество сюрпризов , когда начинается High load.
Это не пародия , это то время когда мы были молоды и счастливы .
Весь мир был спереди...
Программист еще звучало гордо .
А словосочетания "разраб криворукий" , еще не существовало в природе.
Было время ....
Веселись, юноша, в юности твоей, и да вкушает сердце твое радости во дни юности твоей, и ходи по путям сердца твоего и по видению очей твоих; только знай, что за все это Бог приведет тебя на суд (Еккл.11:9).
в статье не приведены ни параметры базы, ни параметры сервера (может у вас там Windows-виртуалка в облаке с 1Гб памяти) , ни схема таблиц и данных, ни тесты
Самое главное большое спасибо за комментарии. Первая статья на тему статистического анализа была опубликована 8-го июля. И сегодня первый день когда были получены действительно полезные комментарии и обратная связь. Проблема в том, что DBA забыли/или не знают математики и не используют математический аппарат в своей работе. Я когда начал копать очень удивился , что практически ничего не удавалось найти. Почему, так, наверное тема другого исследования и других исследователей.
Вернемся к теме.
Да это время. Или если совсем точнее номер минуты когда были получены данные по производительности СУБД .
Это в общем то было и понятно, даже есть отдельны индикатор тренда. Именно с этого и начались проблемы в свое время. Я делаю замеры в разное время и получаю совершенно разные изменения производительности в зависимости от изменения параметра.
Статистический анализ результатов нагрузочного тестирования СУБД в условиях облачной инфраструктуры / Хабр (habr.com)
Именно к такому выводы я и пришел. Хотя больше на основе наблюдений, а не теоретических изысканий.
Опыты всегда проводятся в одно и тоже время. Хорошо этот вариант проверить проще всего, таблицы Excel под рукой . Прям сейчас почитаю и дополню комментарий.
Извините , но мне этот подход непонятен. Что значить обрезать? Почему обрезать 100, не 150, не 200 не 50 ? Как решать - какие данные обрезать и сколько ?
Округления не проводится. Проводится медианное сглаживание. Т.е. Значением за точку T считается медиана отрезка (T , T - период сглаживания) . С целью как раз таки, исключить влияние выбросов. По моему это вполне нормально - среднее вероятное значение не сильно меняется и необходимы существенные причины для изменения значения. Шум не оказывает сильного влияния.
Я опирался вот на эту статью
Описательная статистика перформанс-распределений / Хабр (habr.com)
Здесь вопросов нет. Есть промежуток времени 10 часов между - 19:00 - 09:00. Подготовлю таблицу c усредненными значениями результатов эксперимента 1 и эксперимента 2 . за одинаковые часы. Т.е 19:00-20:00 , 20:00-21:00 ... 08:00 - 09:00
Конечно. Это же работающая инфраструктура, к тому же в облаке. Не отдельно стоящий физический сервер на котором кроме ОС и СУБД ничего нет.
Вот сглаженные данные по эксперименту 1
Вот сглаженные данные по эксперименту 2
Судя по всему, если я правильно понимаю - тренд есть и это проблема ?
Это я пытался сделать в самом начале. Но не довел до результата.
Вообще подробности и реальные цифры и данные здесь Статистический анализ результатов benchmark PostgreSQL / Хабр (habr.com)
Сейчас добавлю графики несглаженных данных для полноты картины.
Да , тесты проводятся в одно время 18:00 - 09:00 каждый день.
Если не сложно, хотелось бы сверится , что я правильно понимаю предлагаемую идею.
Результаты собираться каждую минуту. Берем период 1 час, считаем среднее арифметическое и принимаем это значение как результат за данный час.
Это довольно просто сделать, исходные данные экспериментов есть. Достаточно будет простой таблицы Excel. Сегодня проверю.
Большое человеческое спасибо.
Предложение в работе . При чем , самое хорошее в том, что особо переделывать ничего не требуется , неслаженные данные у меня уже есть. Нужно просто новый отчет сделать. Результаты будут опубликованы .
Сорри, не могу поставить плюс и в карму . Спасибо , ещё раз.
Спасибо за комментарий.
Уточню. Я лишь выдвигаю гипотезу о том, что распределение производительности СУБД в нормальных/идеальных условиях будет нормальным. В условиях реальной облачной инфраструктуры влияние внешних факторов на СУБД - случайно, неуправляемо и непрогнозируемо. Если сравнивать статистические показатели за разные периоды то распределения будут сильно разные - мультимодальные, несимметричные с разными коэффициентами эксцесса . Проблема в том, что нужно выбрать значение которое будет считаться - результатом эксперимента. Следовательно сделан вывод - при минимальном влиянии внешних факторов распределение будет приближаться к нормальному и уже можно сравнивать значения на отрезках при которых распределение похоже на нормальное.
Так не получится. В реальном мире нормального распределения не будет. А сравнивать результаты экспериментов нужно.
Это не отдельное число это значение моды(медианы) на отрезке в котором распределение максимально близкое к нормальному по используемым критериям. Возможно в дальнейшем будут использованы классические статистические тесты, пока сильно упрощенно - ищу отрезок с унимодальным распределение, в котором медиана = мода и модуль вектора ( коэффициент симметрии , коэффициент эксцессам ) минимальный.
Именно так. Но границы этих погрешностей не превышают 1-2% , что для данной практической задачи - полностью устраивает.
Просьба уточнить чуть подробнее почему . Какую информацию можно получить ? Если нужно, могу предоставить графики сглаженных и несглаженных значений. Какая дополнительная информация может быть получена из анализа несглаженных значений ?
Спасибо за предложение, эта тема есть в планах, но чуть на будущее, для анализа корреляции ожиданий СУБД . В данном случае, задача чуть другая - какие значения будет считаться результатом эксперимента.
Только есть одна очень серьезная проблема - таких параметром очень много(порядка 400) и на текущем момент не понятно, являются ли все эти параметры независимыми или нет.
Врядли я один эту тему осилю.
Уже за это - большое человеческое спасибо. Это первый комментарий на Хабре по делу. Спасибо.
Это только один из критериев . Второй критерий - минимальное значение модуля вектора ( коэффициент симметрии , коэффициент эксцесса ) .
По поводу статистических методов для проверки нормальности распределения , да , такая мысль была, и пока она не отброшена. Однако очень важный вопрос - данные проверки сравнительно сложны в реализации , по сравнению с используемыми в настоящее время . Имеет ли смысл настолько усложнять , если результат будет такой же? Но соглашусь, надо проверить. С первого раза, да не получилось быстро реализовать, результат нужен был как можно быстрее. Теперь результат получен, можно усовершенствовать.
Что значить недостоверный результат ? Значение полученное по описанной выше методике не может считаться статистически достоверным результатом эксперимента ?
Большое спасибо за комментарий и ссылку.
Чуть уточню. В итоге получается таблица из 2-х столбцов
1) Значение фактора (неизменно в одном эксперименте)
2) Значение результата ( случайная величина , меняется в очень широком диапазоне)
Задача
1) Как сравнить столбец 2 для разных экспериментов с разными значениями фактора.
Т.е. необходимо определить не то действует или нет фактор на результат а как изменение фактора влечет за собой изменение результата? Качественно и количественно.
Статья не про параметр bgwriter_lru_maxpages вообще то.
Статья о том, как выбрать значение которое можно будет считать результатом бенчмарка для дальнейшего сравнительного анализа влияния изменений параметра/параметров на производительность СУБД, в условиях облачной инфраструктуры.
Это лишь метод, конкретный параметр и его влияние - просто для примера. Вполне можно было в тексте статьи изменить "bgwriter_lru_maxpages" на "параметр X". Смысл статьи бы не изменился.
P.S. В следующей статье, наверное так и сделаю.
Всем спасибо за раскрытие местонахождения!
Я из России.
Давным давно, лет 30 назад один друг сказал фразу, смысл и истинность которой , подтверждались и подтверждаются потом регулярно : "когда человек становится незаменимым, от него надо избавляться."
Т.е. если ситуация дошла до описанной в самом начале статьи это косяк и глобальный залёт руководителя .
Всего 3 слова : "конкуренция за ресурсы". Или другими словами один микросервис влияет на все остальные . Если это считается "микросервисной архитектурой", пусть. Для DBA разницы никакой .
Для микрорешений для 1-10 пользователей и десятком TPS , это вполне работает и они это называют "микросервисы" и очень гордятся.
Когда начинается взрослая работа с сотнями активных сессий и тысячами TPS , начинается ожидаемое "спасите помогите , мы уперлись в СУБД".
:-)
Ну и банально, сорри за повторение - вся идея о микросервисах не имеет никакого смысла , если все эти "микросервисы" взаимодействуют с общей СУБД.
Пока , я только такие решения встречал. Возможно , в природе есть и другие решения. Но пока архитекторы просто выделяют отдельную БД все кластере и называют это - "мы реализовали микросервисную архитектуру".
Это не не вера , это статистически достоверный результат .
Я в IT с 1987 года . Прошел все ступеньки до руководителя направления , год назад ушел с руководства обратно в инженеры .
Мир менеджеров и мир инженеров это разные вселенные с разными законами и разными причинно-следственными связями.
На самом деле вы можете стать именно тем гвоздем , который забьют в первую очередь .
Одно , очень важное уточнение по микросервисам
Все это верно только в одном случае - каждый микросервис взаимодействует со своим экземпляром/инстансом СУБД.
Современные архитекторы и разработчики почему то считают микросервисной архитектурой решение когда множество сервисов работает в одной СУБД. Что влечет за собой множество сюрпризов , когда начинается High load.
А в разговоре фразу "к тебя , что аз упала?" использовал ? В качестве маркера "свой-чужой".
https://youtu.be/EY8Mey846IA?si=8zrEgeUZmH6NtqNT
ДОС , черной пеленой экран заполнил чистый ДОС...
Это не пародия , это то время когда мы были молоды и счастливы .
Весь мир был спереди...
Программист еще звучало гордо .
А словосочетания "разраб криворукий" , еще не существовало в природе.
Было время ....
Веселись, юноша, в юности твоей, и да вкушает сердце твое радости во дни юности твоей, и ходи по путям сердца твоего и по видению очей твоих; только знай, что за все это Бог приведет тебя на суд (Еккл.11:9).
Это не просто звоночек. Это колокол .
Ирония , шутка , гротеск. Понимаю (с)
;-)
Добавлено