Математика *

А ведь объяснение причины излома графика скользящей дисперсии не простое, а очень простое. Элементарное.

Ответ - в описании способа получения значения:

Медианное сглаживание, с периодом 1 час.

...

По каждой точке t вычисляется дисперсия по выборке для входных значений (квадрат отклонения по выборке) за период [ t; t-60 минут].

Дисперсия и корреляция при анализе производительности разнородных СУБД. Точки излома графиков / Хабр

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

Нагрузка начинает расти => мера разброса производительности СУБД меняется, в зависимости от способности данной конкретной СУБД обрабатывать прилагаемую нагрузку. Нагрузка растет , график скользящей дисперсии выглядит уже совсем не как логарифмическая кривая . Но это совсем другая история.

В статьи вносятся дополнения. Вопрос на Хабр Q/A и мат. форуме - закрыт.

Не пришлось придумывать и проверять новую метрику и критерий оценки производительности СУБД. Это очень хорошо 👍

P.S. В принципе статьи можно и удалить, как не обладающие новизной. Но с другой стороны , интересные моменты все таки есть. В первой статье - точно.Очень важная особенность выявилась и уже необходимые изменения в расчёты - внесены. Так, что пусть останутся . На память. Разве, что убрать уровень сложности .

Мысли вслух, на подумать и поэкспериментировать, в самое ближайшее время.

1) Постоянная нагрузка на СУБД, тестовый сценарий pgbench. Облачная инфраструктура .

2) Изменение параметра .

Что является признаком влияния параметра на производительность ?

Если смотреть дельту производительности , есть шанс попасть на шум инфраструктуры .

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

В любом случае период сравнительного анализа - час , не меньше .

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

А тем временем, постепенно, складывается вполне себе стройная концепция применения мат. статистики и методов оптимизации при сопровождении СУБД.

1) Оптимизация конфигурационных параметров СУБД при разворачивании нового кластера PostgreSQL - метод покоординатного спуска .

2) Стресс тестирование - определение предельной нагрузки на инфраструктуру СУБД при выполнении тестового сценария.

3) Бенчмарк - фиксация базовых показателей производительности

4) Передача СУБД в разработку приложения

5) Нагрузочное тестирование и корреляционный анализ производительности в процессе разработки ПО.

6) Передача СУБД в опытную эксплуатацию

7) Стресс тестирование - определение предельной нагрузки на инфраструктуру СУБД при выполнении продуктивного сценария . Протоколирование значений для использования в качестве граничных при мониторинге .

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

9) Передача СУБД в промышленную эксплуатацию. Протоколирование граничных значений для мониторинга .

10) Корреляционный анализ производительности СУБД. Управление инцидентами , проблемами , изменениями .

Цели ясны, задачи определены . За работу товарищи!

Хорошо, когда идёшь по маршруту с заранее заданными контрольными точками.

Давайте посмотрим, как в 9 уникальных технических кодов можно уместить пространственное положение матрицы третьего порядка.

Имеем подобное, как на картинке выше, представление подпространственности. У нас есть 1, 2, 3 (нижние границы отрезка или оси), 4, 5, 6 (верхние) и 7, 8 и 9 (сами пространственные отрезки). Кодируем 1, как 1, 2, как 12, 3, как 123, 4, как 1234, 5, как 12345 и тд., финализируя в тринарные значения матрицы 3х3, ПРОСТРАНСТВЕННО же разводя нашу десятку. Надеюсь данное не трудно. В следующих постах расскажу, как матрицу 3х3, формируя суммарные, и, используя же прямое и обратное пространственное ориентирование для входных и выходных значений, запрограммировать к итоговым 3³. Не скучайте.

Ваш ребёнок — школьник, который разбирается в математике? Тогда скорее участвуйте в олимпиаде по криптографии имени И.Я. Верченко!

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

Отборочный этап проходит онлайн, поэтому можно участвовать из любого города.
Скорее регистрируйтесь!

Иван Яковлевич Верченко — советский математик, криптограф, педагог, доктор физико-математических наук.

Чем дольше копаю тему статистического анализа производительности СУБД, тем больше удивляюсь - почему никто не занимался/не занимается использованием математических методов в DBA ? Статей и материалов практически - нет. По performance engineering - можно найти, по DBA в общем то тишина.

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

Это же так просто и в общем то лежит на поверхности - сделал изменение , собери статистику влияния и оцени характер полученных результатов по совокупности опытов. Нужно подчеркнуть - не картинки, не "кажется" , "наверное" , "скорее всего", "может быть" , а цифры. И цифры взятые не с потолка , а рассчитанные математически. И даже не надо ничего нового придумывать и изобретать - медиана, мода , стандартное отклонение , дисперсия , корреляция - 3й курс КАИ, если не ошибаюсь. Вполне достаточно , для получения объективных результатов анализа, а не гаданий и шаманских танцев с бубнами.

Почему DBA не используют математику ? Риторический вопрос ....

Мысли вслух.

В развитии темы:

Производительность СУБД — расчет метрики, временной анализ, параметрическая оптимизация https://habr.com/p/850106/

Какую метрику лучше/правильнее применить для расчетов модулей векторов , используемых для расчета производительности - Евклидову или Манхеттенскую?

Вектор "операционная скорость":

• QPS: Количество запросов в секунду.

• TPS: Количество транзакций в секунду.

• RPS: Количество строк в секунду.

Вектор "объёмная скорость":

1. RSBS : Прочитанные разделяемые блоки в секунду.

2. DSBS : "Загрязнённые" разделяемые блоки в секунду.

3. WSBS : Записанные разделяемые блоки в секунду.

4. RLBS : Прочитанные локальные блоки в секунду.

5. DLBS : "Загрязнённые" локальные блоки в секунду.

6. WLBS : Записанные локальные блоки в секунду.

7. RTBS : Прочитанные временные блоки в секунду.

8. WSBS: Записанные временные блоки в секунду.

А ведь, первоначально для расчета модуля векторов планировалось просто суммировать компоненты . Оказывается это и есть Манхэттенская метрика.

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

Спасибо Хабру и адекватному читателю   @MichaelBorisov за полезный комментарий, подсказавшему , что компоненты векторов использующих для расчета производительности СУБД, вряд ли независимы и лучше использовать Манхеттенскую метрику .

Теперь вопрос - как изменится итоговый результат после изменения расчета модуля векторов ?

🧮 Математик из Рутгерса решил две давние задачи, которые мучили учёных десятилетиями.

Профессор Фам Тьеп из Университета Рутгерса сделал два значительных прорыва в математике. Он решил задачи, которые оставались нерешёнными на протяжении десятилетий. Эти открытия могут улучшить понимание симметрии в природе и науке, а также повлиять на изучение случайных процессов в физике, инженерии, экономике и компьютерных науках.

Первый прорыв — доказательство Гипотезы о нулевой высоте 1955 года, выдвинутой Ричардом Брауэром. Эта гипотеза, являющаяся одной из самых сложных проблем в теории представлений конечных групп, опубликована в журнале Annals of Mathematics. Тьеп работал над решением этой задачи более десяти лет.

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

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

📜 Подробнее:

• Brauer's Height Zero Conjecture (2024). DOI: 10.4007/annals.2024.200.2.4

• Character levels and character bounds for finite classical groups (2023). DOI: 10.100

• Uniform character bounds for finite classical groups (2024). DOI: 10.4007/annals.2024.200.1.1

  TG.

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

Ну например - какая нагрузка в виде количества одновременных пользователей является критичной для данной СУБД ? А если характер нагрузки не равномерный ? А если инфраструктура нестабильна ? И т.д. и т.п. Интересных вопросов - масса.

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

Пока, упоминаний о подобных разработках не встречал. Было бы интересно .

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

Хотя, возможно потребные вычислительные мощности окажутся слишком высоки. Что делает решение задачи совершенно бессмысленной для практического применения.

Имеется набор конфигурационных параметров СУБД .

Задача - определить комбинацию параметров дающих наибольший прирост производительности .

На текущий момент, первое, что сразу приходит в голову - использовать метод покоординатного спуска (в данном случае - подъёма )

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

P. S.Если удастся установить корреляцию между ожиданиями СУБД и значением тестируемого параметра, то возможно можно будет подготовить методику оптимизации набора и параметров для общей/продуктивной нагрузки. А там и до адаптивной оптимизации параметров СУБД - рукой подать . Поживём-увидим.

Update

Идея была абсолютно правильная ! Работает ! Все идет к тому, что скоро будет готова методика по автоматической настройке параметров СУБД.

Задал вопрос на парочке математических форумов:

Имеется ,вполне стандартная задача - необходимо сравнить результаты экспериментов. И выявить имеется ли влияние некоторого параметра на итоговый результат.
Начальная гипотеза - при постоянной нагрузке на систему и минимальном влиянии внешних факторов распределение показаний будет нормальным.
Для определения результата экспериментам применяется следующий подход:

1. Результаты наблюдений- сглаживаются

2. За период наблюдений определяется отрезок в котором распределение наиболее близко к нормальному: -мода = медиана -унимодально -коэффициент симметрии и эксцесса минимальный

3. Значение моды/медианы в найденном отрезке будет считаться результатом эксперимента .

Вопрос к более опытным математикам - является ли описанный подход допустимым для корректного получения статистически достоверный результатов эксперимента ?

Интересно , будет ли ответ ? На Хабре с обратной связью не очень.

Проблема в том, что DBA не помнят/не знают математики , а математики не особо интересуются вопросами СУБД. Очень мало так называемых best practics имеют хоть какое то экспериментальное обоснование , все на интуиции. А уж математического анализа пока ни разу не встретил. В итоге сообщество DBA выглядит не как сообщество инженеров и ученых, стремящихся познать и улучшить мир и всё подвергающих сомнению , а как средневековый цех со своим уставом, догмами и мастерами и только с одной задачей - выудить побольше денег у сюзерена/герцога/короля. Ну или как алхимики :-)

Мысли вслух.

Размещать в хабе "PostgreSQL" статьи на тему статистического анализа - не имеет практического смысла. Перенес в хаб "Математика". Может быть от математиков удастся получить более-менее полезную обратную связь. Есть надежда, что хоть, что-то не на эмоциях и IMHO-х , а на цифрах и фактах , все таки получится дождаться в комментариях. Поживём увидим.

P.S. Зарегистрировался на математических форумах . Может там ответят ....

P.P.S. Ответили и на математическом форуме и в комментариях к посту в хабе "Математика". Стиль комментариев , по сравнению с хабом "PostgreSQL" различается принципиально и очень кардинально. Все следующие статьи и посты будут размещены только в хабе "Математика" и на математических форумах. Эх, сколько времени было потрачено на пустой флейм с ремесленниками или просто флудерами :-( Надо было сразу , тему статистического анализа начинать обсуждать с математиками, а не с DBA.

Update.

Математики - читают больше.

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

Но можно гораздо проще. У нас есть значения A (B, C - свои тех. переменные) и 1 (1,1 те же уникальные тех. переменные из определнных в количестве 10) и 0 (00). Всего 9. 10 последнее испольуем как условную функцию равенства. Теперь аппаратным программированием строим тринарную матрицу 3х3 с 9 возможными значениями для строки. Это по часовой стрелке (A=B=C=(A)?(1)?(0), BCA, CAB или 3 строки). Программируем для столбца, - против. Далее описываем все возможные варианты значений квадратной матрицы третьего порядка. Индекс строки, индекс столбца, матричное значение выражаем линейно распределенными равенствами (предварительно выделив оперативное пространство в параллельной логике: I + ∑I+ ∑∑II + ∑∑∑I,II + ∑∑∑∑II,I + ∑∑∑∑∑III повторяем копированием полностью каждый раз предшествующую запись ∑ и запоминаем вновь образованные входные переменные, банальным равенством f=(₃3³), удов-им О.О.Ф. или 10ой тех-ой переменной из 13 битов) и обрабатываем запросы элеткронно-вычислительной машины, создав таблицы истинности, логические операторы и, конечно, перепроверку USB устройством 3 из 5 каждого посланного и принятого в такте битов (5 тактов для обработки 1 бита). Либо Y - 3 матр. значения, Y - 3 индекса матрицы, Y - вход., вых. приравнивания, переменная.

В продолжении https://habr.com/ru/posts/837954/

А если для проверки нормальности распределения выборки использовать функцию normal_rand ?

——————————————

normal_rand 

normal_rand(int numvals, float8 mean, float8 stddev) returns setof float8

Функция normal_rand выдаёт набор случайных значений, имеющих нормальное распределение (распределение Гаусса).

Параметр numvals задаёт количество значений, которое выдаст эта функция. Параметр mean задаёт медиану нормального распределения, а stddev — стандартное отклонение.

—————————————

Параметры - из проверяемой выборки .

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

Можно предположить, что время на проверку нормальности распределения выборки очень сильно сократится .

В продолжении темы https://habr.com/ru/posts/837710/

Все идет к тому, что для решения задачи о выборе результатов тестирования , в общем виде, придётся проверять на эффективность использования критерии нормальности.

Проблема в том , что со статистическими функциями в PostgreSQL не очень, а критериев много :

• критерий Шапиро-Уилка,

• критерий асимметрии и эксцесса,

• критерий Дарбина,

• критерий Д'Агостино,

• критерий эксцесса,

• критерий Васичека,

• критерий Дэвида-Хартли-Пирсона,

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

• критерий Андерсона-Дарлинга,

• критерий Филлибена.

Идея следующая - выборки максимально близкие к нормальному распределению, будут считаться статистически значимыми.

В развитии темы

Нагрузочное тестирование СУБД в облачной среде — часть 2. Итоги и результат https://habr.com/p/837462/

Методика проведения нагрузочного тестирования .

Задача

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

Проблема

На производительность СУБД влияет множество случайных факторов.

Гипотеза

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

Из гипотезы следует решение задачи:

1. Из непрерывной серии наблюдений сформировать выборку, максимально удовлетворяющую критерию нормального распределения .

2. Статистические результаты найденной выборки - будут решением задачи.

Дополнение по итогам анализа результатов проведенных экспериментов

В связи с трудоемкостью реализации стандартных статистических тестов Колмогорова -Смирнова и Шапиро –Уилка в PostgreSQL, для практического решения задачи, условия получения результирующей выборки можно сильно упростить.

Достаточно выполнение условия симметричность распределения: Медиана = Мода.

Полученные средние значения ( медиана/моде) производительности будут исходным набором данных.

Для уменьшения объёма выборки , набор данных необходимо отсортировать и отфильтровать по значению дисперсии, исключив результаты выходящие за заданную погрешность измерения.

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

Дополнение

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

pgbench для получения результирующих значений tps использует среднее арифметическое - это серьезная проблема , потенциально способная сильно исказить результат.

Математики говорят, что среднее арифметическое не является робастным. Это значит, что оно не устойчиво к выбросам. Хватит одного-единственного экстремально большого значения, чтобы полностью испортить результат.

Описательная статистика перформанс-распределений https://habr.com/p/722342/

А производительность СУБД есть случайная функция.

Вывод - не стоит использовать результаты pgbench для анализа влияния каких либо изменений и сравнения производительности СУБД.

Как инструмент создания нагрузки - да, как инструмент анализа результатов - нет.

Насколько СУБД подвержено случайным факторам, например облачной среды, показано:

Нагрузочное тестирование СУБД в облачной среде — часть 1 https://habr.com/p/837216/

Нагрузочное тестирование СУБД в облачной среде — часть 2. Итоги и результат https://habr.com/p/837462/

Математическая задача про кофейню

Привет, Хабровчане! Делимся интересной задачей. Попробуете решить? Пишите варианты ответов в комментариях.

Условия: Аня выбирает напиток в кофейне. В меню:

• 7 видов кофе,

• 2 вида горячего шоколада,

• 5 видов чая.

Кофе и горячий шоколад готовят на обычном, соевом или овсяном молоке. Кофе может быть и без молока (а горячий шоколад всегда с молоком). Ещё в кофейне есть 8 сиропов, по желанию можно 1 или 2 разных добавить в кофе.

Вопросы:

1. Аня берёт каждый день разные варианты напитков. Сможет ли она за три года перепробовать все возможные?

2. Бариста сказал, что теперь любой из напитков можно сделать горячим или холодным. Сколько времени теперь понадобится Ане, чтобы попробовать все варианты?

Решение задачи опубликуем в комментариях :)

→ Больше подобных задач в бесплатном тренажере «Основы математики для цифровых профессий».

В новом видео Brick Technology представлены более мощные и продвинутые строительные машины из компонентов Lego, разработанные для того, чтобы сносить всё более высокие башни из Lego.

Эта тема даже совсем не о Lego. Фактически это просто игровая зацепка, которая поможет вам создавать необычные вещи из игрушек. Это на самом деле о науке и инженерии — пробах и ошибках, повторяющихся неудачах, итерациях, небольших достижениях, смене тактики при столкновении с тупиками, о том, как инновации могут привести к значительным преимуществам. Конечно, ничто из этого не уникально для инженерии; все это факторы любого творческого начинания: рисования, спорта, фотографии, письма, программирования. Но настоящее волшебство здесь в том, чтобы увидеть, как все это происходит всего за несколько минут.

Матфей 10:8

Итоговое.

Имеем 5и этажную пирамиду из кубов: 9 (+16), 7 (+9), 5 (+4), 3 (+1), 1.

Видим числовой ряд: "1, 2, 3, 4, 8, 9, 27", в нем геометрическая прогрессия со знаменателем 2 или "1, 2, 4, 8" или грань "/".

1 приравняем к условной грани a (верхний, единственный куб) или 2⁰

2 к aa (кубы этажом ниже, 2шт) или 2¹

4 к aab (кубы еще этажом ниже, 4шт) или 2²

8 к aaba (8 кубов последовательных от начального перебора) или 2³

Следующий шаг прогрессия со знаменателем 3 или "1, 3, 9", а число "27" у нас не умещается. 1, 3 и 9 выразим двойными гранями "/\".

1 приравняем к aabab (единственный, верхний куб, но на сей раз новые грани) или 3₁⁰

3 к aababc (кубы этажом ниже, 3шт) или 3₁¹

9 к aababca (все кубы третьего этажа, 9шт) или 3₁²

Но размещено на 5 этажах, посему продолжаем. Закодировано: 1, 2, 3, 4, 8, 9. Рассмотрим 27, как члена в геометрической прогрессии, необходимого быть выраженным. Попробуем задать, описав тройными гранями в форме "П":

1 к aababcab (свободный куб четвертого этажа) или степень 3₂⁰

3 к aababcabc (свободные 3 куба предпоследнего этажа) или степень 3₂¹

9 приравняем к aababcabcd (свободные 9 кубов последнего этажа) или степень 3₂²

Кодируем: 2¹ (3₁⁰, 3₂⁰), 2² (3₁¹, 3₂¹), 2³ (3₁², 3₂²)

aa или первое матричное итерирование по а (aabab +3 обращения, aababcab +3), aab или второе итерирование (aababc +3, aababcabc +3), aaba или третье итерирование (aababca +3, aababcabcd +3). Получаем (9)+(9)+(9) =27 =3³!

Выразив 3³ можем уже бескомпиляторно программировать таблицу 3х3.