Математика *

Наглядное доказательство того, что a² – b² = (a + b)(a – b).

Софи Жермен писала: «Говорят, что алгебра – это всего лишь записанная геометрия, а геометрия – это всего лишь диаграммная алгебра».

Попробуйте найти минимальное количество DDoS-атак, которое нужно выполнить, чтобы найти предел устойчивости сервера.

Условие

Инженер отдела информационной безопасности Иван разработал новую систему защиты от DDoS-атак. Ему выдали два сервера для тестов. На каждый из них Иван может отправить одновременно от 1 000 до 100 000 запросов (их количество всегда кратно тысяче). Если их окажется слишком много, сервер выйдет из строя и его больше нельзя будет использовать для тестов. Если сервер выдержит, эксперимент можно будет продолжить.

Задача

Какое минимальное количество DDoS-атак необходимо, чтобы гарантированно определить порог уязвимости системы защиты?

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

Большинство университетских профессоров в мире - ленивые. Как выдумали в 1970-е годы преподавать дизайн конечных автоматов примером FSM для светофора (Traffic Light Controller FSM), так и тянут эту бодягу и по 21-му веку. При том, что современные дизайнеры чипов не светофоры конструируют, а ускорители тренировки нейросетей.

Короче мы на Школе Синтеза Цифровых Схем решили преломить эту дурную традицию (которая встречается от Южной Америки до Средней Азии и Филиппин, с провинциальными вузами в Штатах включительно) и ввести в преподавание современный хардкор. То есть сделать домашку с конструированием FSM для управления блоками FPU выдранными из современного реального открытого RISC-V процессора.

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

Пример домашки: сконструировать FSM (а потом и конвейер) для вычисления такого-то ряда Маклорена (для синуса, экспоненты итд), имея в наличии N блоков умножения, M сложения и R деления с плавающей точкой - с разными латентностями.

При обсуждении такой домашки возник вопрос нужно ли для операций с плавающей точкой устанавливать флаг error для нечисел и бесконечностей. Конечно нужно, потому что это удобный повод рассказать про концепцию NaN и Infinity. Полез в википедию и в шоке обнаружил, что статья IEEE_754 на русском отсутствует, хотя есть на украинском. Это непорядок, нужно срочно поправить!

Never gonna give Differential Calculus up или решаем уравнение Лапласа на теле Рика Эстли в пару строчек 🕺🏼

Пример создания и использования граничной сетки для решения уравнений на её основе в WLJS Notebook

Улыбочку! 📸

img = (* Drag n drop фотографию Рика *);  

Применяем фильтр, чтобы оставить только силуэт

MeanShiftFilter[%, 5, 1] // Binarize // ColorNegate

Делаем сетку для решения уравнения из ч/б изображения

ξ = ImageMesh[%]

Ищем собственные значения и векторы (первые 6) оператора Лапласа aka решаем волновое уравнение

{vals, funs} = NDEigensystem[ {
  -Laplacian[u[x, y], {x, y}], 
  DirichletCondition[u[x, y] == 0, True]
}, 
u[x, y], Element[{x, y}, ξ], 6];

Рисуем первые 6 решений и их "энергии"

Grid@
 Partition[
  Table[ContourPlot[
    funs[[i]], Element[{x, y}, ξ], 
    PlotRange -> All, ImageSize->300, 
    PerformanceGoal->"Speed", PlotLabel -> vals[[i]] 
  ], {i, Length[vals]}], 3]

Результат

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

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

Медианное сглаживание, с периодом 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, для практического решения задачи, условия получения результирующей выборки можно сильно упростить.

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

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

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

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

Дополнение

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