PostgreSQL *

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

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

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

В продолжении темы - "время отклика СУБД" https://habr.com/ru/posts/827054/

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

Допустим имеется OLTP нагрузка на СУБД - большое количество коротких запросов. В результате, имеем некоторое значение метрики "Среднее время отклика" = sum(total_exec_time) / sum(calls).

И вот , ситуация изменилась - запросов OLTP стало меньше , но появились аналитические/долгие запросы .

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

Является ли данная ситуация алертом для создания инцидента о деградации производительности СУБД ?

Конечно же - нет.

Более того - в этом случае резко увеличится количество обрабатываемых блоков разделяемой области.

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

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

О мониторинге СУБД.

Классическая метрика -"Время отклика СУБД" - в реальной жизни бесполезна.

Причина - подверженность ошибке 1-го и 2-го рода.

1) Во время аварии отклик СУБД может не только не расти, но даже уменьшаться.

2) Рост времени отклика может быть вызван снижением нагрузки на СУБД.

Утилита pgpro_pwr имеет одну очень серьезную проблему - жестко установленное расписание сбора снимков с помощью take_sample.

Чтобы получить выборки со всех включённых серверов, вызовите функцию take_sample(). Обычно достаточно получать одну-две выборки в час. Для выполнения этой функции по расписанию можно воспользоваться планировщиком cron или подобным.

Последствия:

1)Невозможно собрать статистику производительности и состояния СУБД во время инцидента производительности . Например, если снимки собираются по рекомендации, указанной в документации - каждые полчаса , то практически нельзя ничего сказать о состоянии СУБД в течении 5-10 минут, в которые было зафиксировано снижение производительности в середине 30-ти минутного промежутка.

2) Ожидания в разделе "Top waits" не коррелированы с показателями производительности СУБД. Отчет показывает ожидания отсортированные по времени. И только за весь период снимка. Установить, какое именно ожидание/ожидания (и следовательно запрос/запросы) повлияло/повлияли на деградацию производительности СУБД во время инцидента - практически невозможно.

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

• 11:10 - 13:20 : Нисходящий тренд (снижение производительности )

• 13:30 - 15:40 : Восходящий тренд ( рост производительности )

Казалось бы, в период 11:10-13:20 - инцидент деградации производительности.

НО.

Корреляционный анализ событий ожиданий и показателей производительности показал – корреляция между событиями ожидания и изменением производительности в период 11:10 – 13:20 - отсутствует.

Вероятнее всего, из данного факта следуют следующие выводы:

1. Аномалии СУБД в период 11:10 - 13:20 – отсутствуют

2. Снижение производительности СУБД вызвано внешними причинами (снижение количества подключений, изменение характера запросов, снижением числа запросов и т.д. и т.п. ) .  Т.е. причинами, находящимися вне зоны ответственности DBA.

Обновление библиотеки asyncpg-lite до версии 0.3.1.1

Рад сообщить, что библиотека asyncpg-lite обновлена до версии 0.3.1. Все предыдущие версии были удалены и больше не доступны для установки. Для корректной работы, пожалуйста, удалите старые версии с помощью следующей команды:

pip uninstall asyncpg-lite

Чтобы установить последнюю версию, используйте:

pip install --upgrade asyncpg-lite

Актуальная версия: 0.3.1.1

Вы можете найти страницу библиотеки на GitHub по следующему адресу: asyncpg-lite на GitHub.

Что нового в версии 0.3.1.1

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

Причины обновления

Основная причина переписывания библиотеки — улучшение безопасности. Старые версии имели определенные уязвимости, которые теперь устранены.

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

Благодарю за ваше внимание и поддержку!

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

Такое решение принято из-за ограничений чистого asyncpg в предотвращении SQL-инъекций. Вместо разработки собственного решения я решил воспользоваться проверенными инструментами ORM, которые предоставляет SQLAlchemy, но, при этом, я постарюсь максимально сохранить ту простоту в использовании, которая была в старых версиях asyncpg-lite.

Начиная с версии asyncpg-lite 0.3, библиотека будет основываться на SQLAlchemy и драйвере asyncpg для работы с PostgreSQL. Версии ниже 0.3 будут сняты с доступности для скачивания и установки с завтрашнего дня.

С выходом asyncpg-lite 0.3 настоятельно рекомендуем удалить старые версии библиотеки и установить актуальную.

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

Благодарю за внимание! 🚀

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

1) Статистика производительности СУБД- скользящие средние , стандартное отклонение , дисперсия : полезно для оценки текущего состояния и подготовки baselines и оповещений по проблемам производительности.

2) Статистика нагрузки на СУБД-количество подключений , гистограмма подключений , коэффициент корреляции с производительностью : очень помогает быстро обнаружить аномальное поведение приложения.

3) Статистика ожиданий СУБД - количество ожиданий , гистограмма ожиданий , коэффициент корреляции с производительностью : очень помогает быстро выявить аномалии инфраструктуры и приложения.

4)Быстрые/медленные скользящие средние, тренды, свечи, уровни поддержки - это просто красиво :-) Манагерам нравятся красивые картинки.