PostgreSQL *

Раз в год-два мне приходится вспоминать, что Python — не C++.

В этот раз я наткнулся на случай, когда отформатировать и склеить колонки результата запроса на стороне PostgreSQL и распарсить Python-ом оказалось эффективнее, чем запрашивать колонки как отдельные значения.

Конкретнее, при переходе от этого запроса:

SELECT * FROM o_relations ORDER BY id DESC LIMIT %(limit)s

к этому:

SELECT CONCAT(entry_id::text, '|', tag_id::text) AS ids FROM o_relations ORDER BY id DESC LIMIT %(limit)s

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

Причиной тому тяжёлая конвертация данных из формата С в формат Python внутри Psycopg.

За подробностями можно сходить ко мне в блог: https://tiendil.org/ru/posts/fun-case-of-speeding-up-data-retrieval-with-psycopg

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

Условия остановки стресс-теста , по условиям AND / OR:

1. Снижение метрики производительности на X%

2. Увеличение среднего времени отклика на T%

3. Среднее время отклика >= TMax

4. RAM utilization >= R%

5. CPU utilization >= C% . (Только OR)

6. Общее время стресс теста

7. Максимальное количество активных сессий >= AMax

8. Какое то дополнительное условие ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Репликация делается асинхронно — данные записываются на основной сервер и только после этого отправляются на реплики.

В кластер можно объединить 3 или 5 серверов. Доступные для этого регионы: Москва, Санкт-Петербург и Нидерланды.

Стоимость репликации равна стоимости конфигурации одного сервера, умноженной на 3 или 5.

Создать PostgreSQL с репликацией → 

По итогам очередных экспериментов , в ходе отработки методологии стресс тестирования СУБД , в принципе можно было бы подготовить ещё одну статью на тему "Влияние CPU Utilization = 100% на производительность СУБД".

Но, учитывая негативный (слитие кармы) опыт предыдущей статьи на аналогичную тему - нет никакого практического смысла и пользы - делится результатами наблюдений и экспериментов .

Так, что, просто в заметки на память, в качестве промежуточного личного итога:

Событие "предельная утилизация CPU" при отсутствии события "деградации производительности СУБД" - не является стартовым событием для создания инцидента .

А почтовое оповещение мониторинга "CPU High Utilization" , я давно уже фильтрую.

По итогам анализа результатов экспериментов по стресс тестированию, наверняка будет подготовлена метрика "Performance is OK"(есть пара идей) и вот по ней и будет настроено оповещение и создание инцидента по производительности СУБД.

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

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

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

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

Однако, с бенчмарками, всё совсем не просто .

По умолчанию pgbench тестирует сценарий, примерно соответствующий TPC-B, который состоит из пяти команд SELECT, UPDATE и INSERT в одной транзакции.
https://postgrespro.ru/docs/enterprise/16/pgbench

В 1995 году TPC-A и TPC-B были признаны несостоятельными, и появился более совершенный TPC-C.
https://ibs.ru/media/etalonnye-testy-subd-chto-bylo-chto-stalo-chto-budet/

2 варианта дальнейших действий:

1. Продолжать использовать pgbench.

2. Искать реализации TPC-C и/или более новых сценариев.

Вариант самостоятельной реализации TPC-C , в виду ограниченности ресурсов - не рассматривается .

PostgreSQL 17 уже в Облаке Рег.ру

Мы обновили DBaaS, добавив в него две версии PostgreSQL: 16 и 17.  PostgreSQL 17 упрощает работу с большими нагрузками и улучшает безопасность данных. Теперь ваши проекты будут работать еще быстрее и стабильнее.

Официальный релиз PostgreSQL 17 состоялся 26 сентября 2024 года. 

Ключевые моменты версии: 

• Повышена производительность

  Обработка данных стала более быстрой и надежной, особенно под высокой нагрузкой.

• Ускорена работа с массовыми данными

  Новые алгоритмы обработки позволяют значительно сократить время загрузки и экспорта больших объемов информации.

• Упрощенная работа с JSON

  Новая команда SQL/JSON JSON_TABLE делает запросы к данным в формате JSON более гибкими и удобными.

• Улучшены механизмы логической репликации

  Это упрощает управление данными в условиях высокой доступности и делает процесс обновления на новые версии более эффективным.

Попробуйте PostgreSQL 17 в Облаке Рег.ру!

Мысли вслух.

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

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

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

Update.

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

Сергей Ким, руководитель команды разработки WMS и активный пользователь Яндекс Лавки, рассказал, про внутренний мир Лавок. 

Обсудили: 

• как Яндекс управляет лавками, узнаёт о товарных остатках и рассчитывает время курьеров, чтобы вовремя доставлять все заказы; 

• о чём можно узнать с помощью проактивных пушей изменений и периодического пула всего сразу;

• как перекладывать JSON с минимальным лагом. 

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

Интересно , возможно ли определить объем данных ( количество строк * средний размер строк ), сформированных SQL запросом ?

Количество строк определяется тривиально . Но как определить общий размер результирующих строк , идеально конечно мат.ожидание и стандартное отклонение? Сдается , мне , что - никак. По крайней мере, простой гуглеж ничего полезного не дал. К сожалению.

Но это, как раз, тот случай когда хотелось бы ошибиться.

В продолжении 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/

Продолжаем улучшать наш инструмент анализа планов PostgreSQL explain.tensor.ru. Сегодня мы представляем новую подсказку-рекомендацию и расширенный вариант визуального представления хода выполнения (посмотреть пример):

Ловим кривые индексные условия

Периодически приходится разбирать ситуации, когда вроде бы давно уже отлаженный запрос к PostgreSQL начинает "съезжать с катушек" и дико "тупить".

Зачастую оказывается, что виной тому передача в качестве параметра-массива для ключа индекса какого-то заведомо-ложного условия типа пустого массива (= ANY('{}'::integer[])) или NULL (= ANY(NULL::integer[])).

В таких случаях некоторые версии PostgreSQL начинают себя не очень хорошо вести, пытаясь сканировать индекс без указания этого ключа... и получаем тормоза.

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

Ход выполнения запроса

Выполнение запроса - это проход дерева плана "снизу - вверх", но сам план при этом представляет из себя дерево "сверху - вниз". Неудобненько...

Помимо узлов самого плана, в полное время выполнения запроса входит плюсом еще и время планирования (Planning Time) и время передачи данных (Execution Time), которые могут составлять весьма солидную долю.

Чтобы более наглядно увидеть ход выполнения запроса, мы добавили под "шеврон" navbar'а иерархическое представление времени отработки узлов именно в порядке выполнения.

Закрытие темы "Гипотеза о связи относительного количества ожиданий СУБД и производительности СУБД "

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

Для проверки гипотезы была проведёна серия экспериментов по 3-м сценарям:

1) Базовая(эталонная) нагрузка.

2) Дополнительная нагрузка на CPU/RAM.

3) Очередь ожидания освобождения блокировки строк/таблиц.

Итог: Гипотеза не подтверждается экспериментальными данными : разница в соотношении между ожиданиями составляет ~3% , при деградации производительности ~34%.

Или другими словами: соотношение между ожиданиями при работе СУБД, в общем случае, не зависит от нагрузки и производительности СУБД и остаётся примерно постоянным для конкретной СУБД.

Таким образом - изменение соотношения между ожиданиями СУБД не может являться индикатором деградации производительности.

Тема закрыта. Статья снята с публикации.

P.S. Однако, в ходе экспериментов, получен интересный побочный результат:

При использовании pgbench c параметром "--connect", отношение количества ожиданий влияющих на производительность, к количеству ожиданий не влияющих на производительность - существенно отличается (~38%).

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

О способе оценки производительности отдельного SQL запроса .

В дополнении к теме:

Размышления о мониторинге производительности отдельного SQL запроса

Для возможного варианта решения задачи:

https://habr.com/ru/posts/833162/

если производительность отдельного SQL запроса в настоящее время не мониторится.

Предположение.

Для того, чтобы оценить производительность отдельного SQL запроса необходимо и достаточно получить отношение стоимости запроса (EXPLAIN ANALYSE) к актуальному времени выполнения запроса .

Важное следствие и ограничение:

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

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

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

К вопросу о важности определения понятия "производительность СУБД".

Пусть имеется некий запрос к СУБД, который важно мониторить с точки зрения эффективности и качества работы.

Сценарий 1: запрос выдает N1 строк и выполняется за время T1.

Сценарий 2: запрос выдает N2 строк и выполняется за время T2.

Вопрос: можно ли утверждать о инциденте в случае Сценария 2, если "T2 > T1 И N2 > N1" ?

Утверждение: Не имея определения понятия "производительность" и не обладая возможностью рассчитать метрику производительности отдельного запроса, получить однозначный ответ на поставленный вопрос - невозможно.

Пару месяцев назад (точнее 15 месяцев и 12 дней) я выложил статью про исходный код PostgreSQL где рассказал про инфраструктуру узлов (struct Node) - с помощью него реализуется наследование, полиморфизм и все, все, все.

Вот уже как 2 месяца я работаю разработчиком PostgreSQL. Уже успел реализовать пару фич, закрыть несколько тасок и разбирался с другими проблемами.

Так вот, эти 2 месяца выдались веселыми. Кроме одного момента. Мне надоело постоянно возиться с этими нодами. Проблема в том, что есть наследование и многие переменные имеют свой базовый тип (если не самый базовый Node, который просто 1 поле тэга) - приходится постоянно лезть в (работаю в VS Code) watch панель и писать монструозные конструкции по типу ((RestrictInfo*)((RelOptInfo*)root->rtable[0])->another_field))->value (взято из головы). Причем - чем глубже спускаешься, тем громаднее и неповоротливее выражения становятся.

Я искал различные расширения или способы, чтобы облегчить себе жизнь, но ничего кроме встроенного pprint(Node *).

Мне это не понравилось. И я решил эту проблему по своему. Создал расширение для VS Code, которое позволяет просматривать все переменные и при необходимости кастует узел к нужному типу с отображением всех соответствующих переменных.

Пока у этого расширения 2 фичи:

1. Приводит наследуемые от Node * переменные к нужному типу и отображает

2. Дампит переменную-узел в stdout с помощью вызова pprint

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

Вот ссылка на само расширение.