Русский
Русский
English
Статистика
Реклама

Блог компании postgres professional

Мониторинг 95 метрик PostgreSQL с помощью плагина Zabbix Agent 2

24.05.2021 20:06:11 | Автор: admin

В прошлом году популярный сервис мониторинга Zabbix представил Agent 2, призванный сократить число TCP-подключений и обеспечить удобную расширяемость за счёт плагинов на Golang.

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

Как появился плагин мониторинга PostgreSQL для Zabbix Agent 2?

В 2019 году Zabbix анонсировал выпуск нового Zabbix Agent 2. Он написан с нуля на Golang. Для мониторинга каждого приложения требуется отдельный плагин. Мы в Postgres Professional решили, что это отличная возможность применить наш многолетний опыт использования Zabbix для мониторинга PostgeSQL, и написали модуль мониторинга для Agent 2.

Как устроен мониторинг СУБД в Zabbix?

Начнём с небольшого введения в схему работы мониторинга Zabbix для новичков.

Интересную нам сейчас структуру можно разбить на две составляющие:

  1. Zabbix Server, который хранит и собирает данные.

  2. Агенты, которые устанавливаются на наблюдаемых объектах и собирают данные.

Для мониторинга каждого приложения в Zabbix Server требуется шаблон - XML-файл. В нём указаны ключи метрик (уникальные ID) и параметры их обработки.

Zabbix Agent 2 призван дать пользователю инструмент мониторинга из коробки, быстро и легко настраиваемый, а также с хорошей расширяемостью.

Как же работает PostgreSQL плагин для Zabbix Agent 2?

Есть основная функция, в которой по уникальному ключу вызываются обработчики для каждой метрики. Обработчик (handler) служит для сбора данных. Это файл, в котором указывается и выполняется SQL-запрос для получения одной или нескольких метрик. Результаты выполнения запроса записываются в переменную, которая относится к типу int, float или string. Если результат должен содержать значения сразу нескольких метрик, то он будет преобразован в JSON ещё на стадии получения запроса. Полученные результаты Zabbix Agent 2 периодически отдаёт Zabbix Server.

Плагин и обработчики находятся вот в этой папке: /plugins/postgres

Какими возможностями обладает модуль мониторинга PostgreSQL для Zabbix Agent 2?

  • Поддержка постоянного подключения к PostgreSQL.

  • Мониторинг нескольких экземпляров (instances) PostgreSQL одновременно.

  • Опции контроля и проверки метрик в реальном времени через командную строку.

  • Конфигурирование плагина через общий файл конфигурации агента.

  • Сохранение состояния между проверками.

  • Довольно простая кастомизация сбора существующих метрик.

  • Возможность писать новые плагины под свои требования.

К плагину есть официальный шаблон, который можно скачать по ссылке.

В нем есть базовые триггеры и комплексный экран, на котором отображается комбинация нескольких графиков. Всего плагин собирает более 95 метрик. Полный список всех метрик также можно найти по ссылке выше.

В веб-интерфейсе Zabbix Server можно редактировать шаблон и его составляющие для своих нужд. Что именно можно настроить?

  1. Изменить интервал сбора метрики.

  2. Добавить триггер для метрики.

  3. Добавить макрос или отредактировать существующий.

Как установить и использовать PostgreSQL-плагин для Zabbix Agent 2?

1. Создаем пользователя PostgreSQL для мониторинга:

CREATE USER 'zbx_monitor' IDENTIFIED BY '<password>';GRANT EXECUTE ON FUNCTION pg_catalog.pg_ls_dir(text) TO zbx_monitor;GRANT EXECUTE ON FUNCTION pg_catalog.pg_stat_file(text) TO zbx_monitor;

2. Редактируем pg_hba.conf, чтобы разрешить подключение от Zabbix Agent 2:

# TYPE DATABASE USER ADDRESS METHOD
host all zbx_monitor 127.0.0.1 md5

Больше информации о pg_hba.conf по ссылке.

Теперь остаётся задать параметры подключения к PostgreSQL для Zabbix Agent 2. Это можно сделать двумя способами:

  • использовать макросы для параметров подключения,

  • создать сессию.

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

1. В шаблоне редактируем макрос {$PG.URI} , в котором указывается путь к PostgreSQL в формате <protocol(host:port)>.

2. Задаем макрос с именем пользователя и паролем ({$PG.USER} and {$PG.PASSWORD}). Так же можно указать макрос {$PG.DBNAME}. Этот параметр опционален для большинства метрик - если он не задан в ключе, то будет использовано имя базы, указанное в конфигурационном файле агента.

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

Второй способ позволяет задавать параметры подключения к нескольким экземплярам PostgreSQL:

  1. Задаём параметры подключения для сессии в конфигурационном файле zabbix_agent2.conf в секции плагина Postgres: Postgres.Sessions.<Session_name>.URI,Postgres.Sessions.<Session_name>.User,Postgres.Sessions.<Session_name>.Password. Здесь вместо <Session_name> нужно указать уникальное имя новой сессии.

  2. Создаём макрос с именем сессии в шаблоне {$PG.<Session_name>}.

  3. Указываем макрос как единственный параметр для метрик в шаблоне.

Рассмотрим, как использовать плагин для сбора дополнительных метрик на примере добавления метрики uptime.

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

1. Создаем файл для получения новой метрики:

zabbix/src/go/plugins/postgres/handler_uptime.go

Подключаем пакет postgres и указываем ключ (ключи) метрик:

package postgresconst (keyPostgresUptime = "pgsql.uptime")

2. Объявляем обработчик (handler) c запросом, а так же переменную uptime, куда будет записан результат:

func uptimeHandler(ctx context.Context, conn PostgresClient,                    _ string, _ map[string]string, _ ...string) (interface{}, error){var uptime float64query := `SELECT date_part('epoch', now() - pg_postmaster_start_time());

3.Выполняем запрос, проверяем, возникла ли ошибка. Если все ОК, возвращаем переменную uptime с результатом.

row, err := conn.QueryRow(ctx, query)if err != nil {...}err = row.Scan(&uptime)if err != nil {...}return uptime, nil

4. Регистрируем ключ новой метрики:

var metrics = metric.MetricSet{....,keyPostgresUptime: metric.New("Returns uptime.",[]*metric.Param{paramURI, paramUsername, paramPassword,paramDatabase}, false),}

Собираем агент!

Новый функционал

В версии Zabbix 5.2 появилась возможность вычислять метрики, собирая результаты пользовательских запросо из отдельных SQL-файлов. При этом можно создавать даже динамические запросы. В этой версии также обновлена архитектура модуля и исправлены мелкие ошибки.Продемонстрируем, как добавлять кастомные метрики через SQL - файл на примере простого запроса с одним параметром:

  1. Создадим SQL-файл с запросом.

    $touch custom1.sql$echo SELECT id FROM my_table WHERE id=$1; > custom1.sql
    

    Тут в $1 будет передан параметр при выполнении запроса.

  2. В zabbix_agent2.conf заполним параметр Plugins.Postgres.CustomQueriesPath, указав путь к директории с SQL-файлом.

    Plugins.Postgres.CustomQueriesPath=/path/to/the/file

  3. В шаблоне для ключа pgsql.query.custom укажем имя SQL-файла и добавим дополнительные параметры для запроса, т.е. тот, который заменит $1. Стоит отметить, что для названия SQL - файла и для параметров можно также создавать макросы в шаблоне.

Дополнительные материалы

Презентации Zabbix Online Meetup, который проходил 19 июня

Статья Вадима Ипатова - одного из разработчиков Zabbix Agent 2

Шаблон для плагина мониторинга PostgreSQL

Zabbix Git для тех, кто хочет видеть больше реальных примеров и посмотреть на все SQL-запросы для получения метрик

Видео доклада на PGConf.Online 2021 "Обзор новой функциональности и настройка Zabbix Agent 2 для мониторинга PostgreSQL"

Остались вопросы?

Все вопросы можно задавать в комментариях.

Подробнее..

Жизнь на PostgreSQL

12.10.2020 20:04:57 | Автор: admin
Недавно на Хабре была опубликована статья Морской бой в PostgreSQL. Должен признаться: я обожаю решать на SQL задачи, для SQL не предназначенные. Особенно одним SQL-оператором. И полностью согласен с авторами:

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

И еще. Будем честны: всегда использовать SQL по назначению тоска зеленая. Вспомните, какие примеры приводятся во всех учебниках, начиная с той самой статьи Кодда? Поставщики да детали, сотрудники да отделы Агде же удовольствие, где же фан? Для меня один из источников вдохновения сравнение процедурных решений с декларативными.

Я, позвольте, не буду объяснять, что такое Жизнь Джона Конвея. Скажу только, что оказывается используя клеточный автомат Жизни, можно построить универсальную машину Тьюринга. Мне кажется, это грандиозный факт.

Так вот, можно ли реализовать игру Жизнь одним оператором SQL?

Окей, приступим.

Поле у нас будет таблицей с координатами живых клеток, а вовсе не двумерным массивом, как можно сгоряча подумать. Такое представление более естественно для SQL, оно упрощает код и позволяет не думать о границах поля. К тому же скорость расчетов (которая, правда, вряд ли нас тут сильно волнует) будет зависеть только от числа живых клеток, а не от размеров поля.

Кстати о матрицах
Такое же представление удобно использовать для представления матриц, особенно разреженных:

CREATE TABLE matrix (  rw  integer,  cl  integer,  val float);

Простой пример, эффективно взрывающий процедурно настроенный мозг, умножение матриц. Напомню, что произведением матрицы A(LM) на матрицу B(MN) является матрица С(LN), элементы которой ci,j = k = 1...M ai,kbk,j.

Процедурный алгоритм использует тройной вложенный цикл по i, j, k. А SQL-запросу достаточно простого соединения:

SELECT a.rw, b.cl, sum(a.val * b.val)FROM a    JOIN b ON a.cl = b.rwGROUP BY a.rw, b.cl;

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

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

Итак, поле:

CREATE TABLE cells(    x integer,    y integer);INSERT INTO cells VALUES    (0,2), (1,2), (2,2), (2,1), (1,0); -- glider

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

WITH shift(x,y) AS (    VALUES (0,1), (0,-1), (1,0), (-1,0), (1,1), (1,-1), (-1,1), (-1,-1)),neighbors(x,y,cnt) AS (    SELECT t.x, t.y, count(*)    FROM (        SELECT c.x + s.x, c.y + s.y        FROM cells c            CROSS JOIN shift s    ) t(x,y)    GROUP BY t.x, t.y )SELECT * FROM neighbors;

Сдвиги (shift) тоже можно сконструировать запросом, но, пожалуй, проще от этого не станет.

Имея соседей, остается решить, какие клетки должны погибнуть, а какие родиться:

WITH shift(x,y) AS (    ...),neighbors(x,y,cnt) AS (    ...),generation(x,y,status) AS (    SELECT coalesce(n.x,c.x),           coalesce(n.y,c.y),           CASE                WHEN c.x IS NULL THEN 'NEW'                WHEN n.cnt IN (2,3) THEN 'STAY'                ELSE 'DIE'           END    FROM neighbors n        FULL JOIN cells c ON c.x = n.x AND c.y = n.y    WHERE (c.x IS NULL AND n.cnt = 3)          OR          (c.x IS NOT NULL))SELECT * FROM generation;

Полное соединение здесь необходимо, чтобы, с одной стороны, в пустой клетке могла зародиться новая жизнь, а с другой чтобы погубить живые клетки на отшибе. Унас три условия попадания в выборку: либо клетка пуста и у нее ровно три соседа (тогда она должна ожить и получает статус NEW), либо жива и имеет двух или трех соседей (тогда она выживает и получает статус STAY), либо жива, но имеет меньше двух или более трех соседей (тогда она обречена на гибель и получает статус DIE).

Теперь надо обновить игровое поле, используя информацию о новом поколении клеток. Вот тут-то нам и пригодятся возможности PostgreSQL: мы сделаем все необходимое в том же операторе SQL.

WITH shift(x,y) AS (    ...),neighbors(x,y,cnt) AS (    ...),generation(x,y,status) AS (    ...),del AS (     DELETE FROM cells    WHERE (x,y) IN (        SELECT x, y FROM generation WHERE status = 'DIE'  )),ins AS (    INSERT INTO cells        SELECT x, y FROM generation WHERE status = 'NEW')SELECT *FROM generationWHERE status IN ('STAY','NEW');

Собственно, вся логика игры написана!

К этому алгоритму уже нетрудно прикрутить отображение результата в виде привычной глазу двумерной матрицы. И, как вишенкой на торте, можно закончить запрос командой psql \watch, чтобы поколения сменяли друг друга на экране каждую секунду.

Вот весь запрос целиком с минимально удобоваримым выводом. Copy, paste, and enjoy!

WITH shift(x,y) AS (    VALUES (0,1), (0,-1), (1,0), (-1,0), (1,1), (1,-1), (-1,1), (-1,-1)),neighbors(x,y,cnt) AS (    SELECT t.x, t.y, count(*)    FROM (        SELECT c.x + s.x, c.y + s.y        FROM cells c            CROSS JOIN shift s    ) t(x,y)    GROUP BY t.x, t.y ),generation(x,y,status) AS (    SELECT coalesce(n.x,c.x),           coalesce(n.y,c.y),           CASE                WHEN c.x IS NULL THEN 'NEW'                WHEN n.cnt IN (2,3) THEN 'STAY'                ELSE 'DIE'           END    FROM neighbors n        FULL JOIN cells c ON c.x = n.x AND c.y = n.y    WHERE (c.x IS NULL AND n.cnt = 3)          OR          (c.x IS NOT NULL)),del AS (     DELETE FROM cells    WHERE (x,y) IN (        SELECT x, y FROM generation WHERE status = 'DIE'  )),ins AS (    INSERT INTO cells        SELECT x, y FROM generation WHERE status = 'NEW'),dimensions(x1,x2,y1,y2) AS (    SELECT min(x), max(x), min(y), max(y)    FROM generation    WHERE status IN ('STAY','NEW'))SELECT string_agg(CASE WHEN g.x IS NULL THEN ' ' ELSE '*' END, '' ORDER BY cols.x)FROM dimensions d    CROSS JOIN generate_series(d.x1,d.x2) cols(x)    CROSS JOIN generate_series(d.y1,d.y2) lines(y)    LEFT JOIN generation g ON g.x = cols.x AND g.y = lines.y AND g.status IN ('STAY','NEW')GROUP BY lines.yORDER BY lines.y\watch 1
Подробнее..

Приглашаем на PGConf.Online 2021

20.02.2021 12:17:51 | Автор: admin

Традиционную конференцию PGConf.Russia в этом году из-за поднадоевшего вируса не удалось провести в обещанные сроки в традиционной форме. Поэтому пока онлайн, но в запланированные дни - с 1 по 3 марта, с надеждой на оффлайн в будущем. Онлайн упрощает приглашение иностранных докладчиков (поэтому их сравнительно много), участники на подножном корме - в общем, онлайн обходится дешевле, поэтому мы смогли сделать конференцию бесплатной (благодаря уважаемым спонсорам, на текущий момент это Intel, Nutanix, Avito и Zabbix, список, скорее всего, пополнится).

Особенности формата конференции

В этом году мы не выделяем отдельного дня мастер-классов - нет смысла. Короткие и длинные доклады (22 и 45 минут + вопросы) и мастер-классы (90 и более минут) распределены по всем трём дням конференции. Некоторые доклады были записаны докладчиками заранее, как принято на большинстве онлайн-конференций, а некоторые пойдут в прямом эфире. Синхронный перевод будет. Вопросы - через чат, затем докладчик с помощью ведущего будет отвечать на них. После докладов можно перейти в комнаты Spatial Chat , чтобы там поспать продолжить обсуждение.

Также мы предлагаем участникам выступить с 5-минутными блиц-докладами и провести свои митапы. Запись на всё это будет идти во время конференции.

Чтобы все это работало, мы привлекли на помощь друзей - а именно, фирму Онтико,т.е. команду Олега Бунина, проводящую знаменитые конференции HighLoad++ и другие.

Зарегистрироваться на конференцию можно на сайте до 26 го февраля.

Что же в программе?

Мастер-классы

Python не теряет своей популярности. Для того, чтобы из питона работать с постгресом, используется библиотека psycopg2. У нас в гостях её автор, Даниэле Вараццо. В своем мастер-классе Python for PostgreSQL: how to use it, how to be good at it он даст полный обзор этой библиотеки и расскажет обо всем, что нужно для её использования.

Альваро Эрнандес - частый гость PGConf.Russia - поделится своим опытом использования PostgreSQL под Kubernetes в мастер-классе Как преобразовать Postgres в облачную платформу.

Игорь Косенков, эксперт Postgres Pro по отказоустойчивым системам, расскажет о настройке кластера с помощью утилиты CRM Shell.

Два мастер-класса будут посвящены производительности Postgres - Николая Самохвалова и нашего гостя из солнечного Пакистана Ибрара Ахмеда.

Доклады

Новые продукты, фичи и разработки

Михаил Цветков из Intel расскажет о новинках технологий, которые могут увеличить производительность СУБД: pmem, FPGA и т.п.

Давно нет крупных новостей о развитии логической репликации. Это исправит Амит Капила, ведущий разработчик и коммиттер PostgreSQL.

Иван Панченко представит актуальные сведения о разработке СУБД Postgres Pro - о новых фичах и планируемых направлениях. Про отдельные фичи расскажут Максим Орлов (Горячее обновление) и Дмитрий Урсегов (Шардман). Арсений Шер раскроет внутреннюю кухню очень глубокой разработки Postgres Professional - мультимастера (настоящего, синхронного) и объяснит, какие ограничения влечет за собой использование СУБД в таком режиме. Это Open Source! Анастасия Лубенникова поделится своими результатами в области развития встроенного секционирования PostgreSQL - какие новые фичи там появятся и над чем идёт работа. Егор Рогов расскажет о новых учебных курсах Postgres Pro.

Андрей Зубков представит обновленный анализатор исторической нагрузки pg_profile / pg_pwr (читается "Пауэр" :).

Олег Бартунов и Никита Глухов расскажут о своих новых разработках в области повышения производительности JSON (и вообще TOAST). Результаты очень интересны, в некоторых случаях JSON сможет работать на порядок быстрее. Дмитрий Долгов расскажет о результате своей многолетней работы над обобщенным сабскриптингом (т.е. чтобы можно было писать UPDATE... SET x[y] = ..., где x - не только массив, но и, например, JSON ).

Автор pgstrom Кохей Каигаи расскажет о том как с помощью GPU ускорить GiST индексы и вообще PostGIS.

Дарья Вилкова расскажет о новом агенте Zabbix для мониторинга PostgreSQL.

Дорофей Пролесковский, ведущий разработчик PostGIS, представит новости версии 3.1.

DBA/Devops

Роберт Хаас научит нас обнаруживать и устранять повреждения данных в базе.

Жульен Руо и Тацуро Ямада расскажут о полезных расширениях pg_qualstats и pg_plan_advsr, а также об своей работе по автоматизации настройки PostgreSQL. Отдельно Жульен расскажет о том, как можно противостоять изменениям таблиц collation при обновлении системных библиотек (из-за этой беды могут неправильно работать индексы, построенные по старой таблице).

Николай Самохвалов расскажет о том, как аккуратно вносить изменения в структуру больших баз, находящихся под нагрузкой, а Роберт Бернье - как такие базы апгрейдить.

Дмитрий Фонтейн поделится своими соображениями об обеспечении высокой доступности Postgres, а Андрей Бородин - своими, затронув также проблемы захвата изменений с высокодоступного кластера.

Кристофер Треверс расскажет, как он справлялся с врапараундом.

Ибрар Ахмед сделает всесторонний обзор безопасности данных в PostgreSQL.

Про бэкап тоже поговорим: Дэвид Стил расскажет о pgBackRest, а Артём Картасов - о WAL-G.

Альваро Эрнандес и Фабрицио Мельо расскажут об использовании прокси-сервера Envoy для постгреса и мониторинге сетевого трафика через него.

Андреас Шербаум расскажет о том, как устанавливать и конфигурировать постгрес через Ансибл.

Юго Нагата расскажет о своей разработке для быстрого инкрементального апдейта материализованных представлений.

Bo Peng расскажет о том, как построить кластер с балансировкой PgPool-II в кубернетесе.

Александр Никитин раскроет некоторые подводные камни копирования баз с pg_dump и pg_basebackup, а Павел Стехуле - о том, как сделать работу с psql удобнее с помощью пейджера pspg.

Иван Чувашов из онлайн-кинотеатра Окко поделится своим опытом работы DBA с высоконагруженными системами.

1C

Антон Дорошкевич из Infosoft поделится своим опытом использования компрессии данных в СУБД Postgres Pro для баз 1С. Результат обещает быть интересным не только для любителей 1С. Кроме того, в диалоге с Фёдором Сигаевым, ведущим контрибьютером PostgreSQL, обсудит основные проблемы связки "1С+Postgres".

Разработка и миграция

Алиция Кухарчик из Microsoft расскажет о миграции на Постгрес с "другой популярной базы" с использованием ora2pg, объяснит, как правильное использование знаний возможностей постгреса помогает совместить миграцию с оптимизацией запросов, чтобы новая база работала быстрее старой, а Александр Любушкин и Юлия Голубева расскажут о разработанном ими новом инструменте миграции со сложным названием LUI4ORA2PG. О миграции данных между теми же СУБД с помощью FDW расскажет Даниил Вестерман.

Дэвид Темплтон поделится опытом создания хранилища данных, а Константин Евтеев расскажет, как хранилище данных и онлайн-аналитика организованы в X5.

Иван Фролков подкинет бензинчика в спор о том, насколько БД должна быть чистым хранилищем и есть ли, помимо вреда, польза от констрейнтов.

Даниеле Вараццо, помимо мастер-класса по psycopg2, расскажет о том, как и зачем он взялся за переработку этого продукта, и чем psycopg3 будет лучше.

Андрей Фефелов поделится опытом и идеями по поводу того, как правильно обфусцировать базу при переносе в тестовое окружение, а Николай Рыжиков - интересной концепцией динамического построения SQL-запросов, вдохновленной closure.

Алексей Фадеев сравнит возможности Multicorn FDW и PL/Python, мы услышим интересные выводы о их производительности. Известный SQL-гуру Генриетта Домбровская расскажет о своей новой концепции избавления от ORM.

Василий Пучков расскажет об опыте разработки сложной системы для нефтяной отрасли на основе Postgres.

Дисклеймер

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

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


Как обычно, слайды и видеозаписи после конференции будут опубликованы. Более тёплое и ламповое оффлайн событие PGConf.Russia мы проведем чуть позже. Следите за новостями - и до встречи в онлайне!

Подробнее..

Постгрессо 22

23.06.2020 04:23:00 | Автор: admin

Жизнь продолжается. А мы продолжаем знакомить вас с самыми интересными новостями PostgreSQL

Релизы


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


PgBouncer 1.14.0

В этой версии появилась поддержка сокетов Unix-domain на Windows в ногу с PostgreSQL 13.
На сервер теперь можно войти, используя зашифрованные SCRAM-секреты, хранящиеся в userlist.txt или полученные в auth_query.
Появилась поддержка создания сокетов с помощью systemd.

Pgpool-II 4.1.2, 4.0.9, 3.7.14, 3.6.21 and 3.5.25

Минорные релизы. Ничего особо примечательного, исправление большого числа мелких багов. Скачивать сорсы и RPM можно отсюда.

SQLancer

Он же Synthesized Query Lancer. Эта интересная программка на Java предназначена для нахождения логических ошибок в СУБД (тема актуальная, см. статью Jepsen ниже). Она сначала создаёт базу, а затем генерит запросы, которые создают, модифицируют и убивают данные. Кроме того создаются индексы и представления.

При генерации запросов используются три подхода. Например, в первом
Pivoted Query Synthesis (PQS) выбирается запись и под неё генерятся запросы, которые заведомо должные вернуть эту запись. Отсутствие говорит об ошибке. Другой проверяет баги оптимизации Non-optimizing Reference Engine Construction (NoREC), третий снова логические ошибки, но используя Ternary Logic Partitioning (TLP).

pgsodium 1.1.1

Это написанное Мишелем Пеллетье (Michel Pelletier) расширение (оно выложено на PGXN, нужна регистрация), которое адаптирует функции криптографической библиотеки libsodium к SQL. Автор признаётся, что черпал вдохновение из расширения pgcryptokey Брюса Момджана. Когда ключ загружен, новые ключи можно получить генерацией пар ключей детерминированными функциями, например crpypto_box_seed_new_keypair(). Загружать отсюда.

veil2, pgbitmap

vail2 фреймворк для быстрого построения систем с RLS (Virtual Private Databases, VPD) дает возможность упростить проверку доступа, аутентификации пользователей гитхаб, документация.

pgbitmap любопытная штука, пока в альфа-стадии. Это расширение для работы с битовыми картами в PostgreSQL, с ними можно много что делать, например, вычитать друг из друга, смотреть пересечения, конвертировать в текстовые представления. Разработано оно было под задачи управления доступом для RLS (Virtual Private Databases, VPD). И то, и другое написано Марком Манро (Marc Munro).

Citus 9.3

В этой версии в основном развиваются и улучшаются возможности, которые уже были в 9.2, и которые работают на концепцию HTAP (hybrid transactional analytic processing), то есть на то, чтобы сделать базу пригодной и для транзакционных задач, и для аналитики (особенно для аналитики). Соответственно оптимизация шардинга и оконных функций в центре внимания.

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

Выбор шардов (shard pruning) работает теперь более универсально: раньше с этим были проблемы при запросах с OR в предложениях WHERE, теперь со всеми булевыми логическими выражениями в WHERE выбираются только нужные шарды.

Выражения вида INSERT SELECT работали в распределенных транзакциях и раньше, но только не с последовательностями. Теперь и с ними тоже.

В Citus можно создавать таблицы 3 типов: reference (словарные), distributed (распределенные)
и local (обычные Postgres-таблицы). Были проблемы JOIN словарных таблиц с обычными, а теперь словарные живут на координаторе кластера, никаких проблем нет, и работают такие джойны быстрее.

И ещё: появилось адаптивное управление соединениями для того, чтобы при многих параллельных запросах можно было обходиться без внешних пулеров (без PgBouncer).

wal2mongo v1.0.6

Китайская компания HighGo Software, о котором было и в Postgresso 21, с помощью этого плагина дает возможность устроить логическую репликацию от PostgreSQL в MongoDB. Это практично, если в PG накапливаются сырые данные, которые дальше анализируются в Mongo. Тестировали и собирали с PostgreSQL 12.3. Имеются сорсы и бинарники для CentOS6, 7, для Windows 7, 10, 2019.

Pitrery 3.1

Это набор bash-скриптов для PITR-бэкапа. В релизе несколько багфиксов. Качать отсюда.

psqlODBC 12.02.0000

В этом релизе некоторый набор не слишком принципиальных изменений и доработок: появление опции IgnoreTimeout, например.



Статьи



Multi-Master Replication Solutions for PostgreSQL
В этой статье от Percona рассматриваются
  • BDR (2ndQuadrant);
  • xDB (EnterpriseDB);
  • PostgreSQL XC/XC2 (NTT совместно с EnterpriseDB);
  • PostgreSQL XL (форк PostgreSQL-XC, сейчас поддерживается 2ndQuadrant);
  • Rubyrep (автор Арнт Леман Arndt Lehmann);
  • Bucardo (авторы End Point Corporation).

Странно, что не видно в этой сводке multimaster в Postgres Pro Enterprise.

Jepsen: PostgreSQL 12.3
Аналитики компании Jepsen.io натравили на Postgres свою утилиту Elle, которая тестирует валидность заявленных уровней изоляции. И нашли баг. Никакой трагедии: они находили их в дюжине уважаемых СУБД; баг уже исправляют, и патч появится в следующем минорном релизе 12.4, намеченном на 13-е августа. Кайл Кингсбери (Kyle Kingsbury) пишет об этом в блоге своей компании. На самом деле уровень SERIALIZABLE в PostgreSQL это SSI (Serializable Snapshot Isolation), что, впрочем, было известно как и про то, что REPEATABLE READ это Snapshot Isolation. Но это считалось достаточным приближением к соответствующим стандартным уровням ANSI SQL.

Elle выявила, что PEREATABLE READ в PostgreSQL слабее, чем в стандарте (но, как говорят в Jepsen, и само определение для этого уровня довольно двусмысленное так что ладно) и что уровень SERIALIZABLE в PostgreSQL допускает аномалию G-2, а это уже не comme il faut. Это событие уже обсудили на Вторнике #ru.Postgres #23 0:01:57 (см. раздел Вебинары и митапы). Решили, что ситуация далека от экстремальной.

PostgreSQL Transparent Data Encryption

Cybertec просвещает постгресистов по теме TDE, благо их патч доступен и работает (разработками TDE занимаются сейчас многие: EDB, например).

TDE шифрует в 128-битный AES-CTR всё кроме данных расширения pg_stat_statements и метаданных транзакций. Шифрование поддерживается инструкциями процессора для ускорения ввода/вывода, оверхед на само шифрование на фоне ввода/вывода незаметен. TDE работает начиная с PostgreSQL 9.6.12 вплоть до 12.3.

Safety Systems Can Reduce Safety

В чём цель? риторически заостряет Брюс Момджан сделать систему безопасней, или добиться, чтобы она выглядела безопасной? Удовлетворить неким требованиям извне? Но даже в первом случае это удаётся не всегда, говорит Брюс, вспоминая Чернобыль. Системы безопасности усложняют систему и вносят сценарии краха, которые не были возможны без неё. Ответьте на 4 вопроса
  1. насколько серьёзно происшествие, которое система безопасности хочет предотвратить?
  2. насколько оно вероятно?
  3. насколько вероятен провал системы безопасности?
  4. как провал системы безопасности может сказаться на работе всей системы?

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

When Does a Commit Happen?

В этой заметке Брюс копает вглубь механизма каммитов: они не укладываются в логику да/нет, а распадаются на 6 фаз. В результате падения процесса может, например, получиться так, что коммит уже будет сброшен на диск, но ещё не виден клиентам или уже будет реплицирован и виден запросам на репликах, но не виден запросам на мастере простите: на primary. Брюс также рекомендует почитать этот тред Андрея Бородина из Яндекса.

10 Things Postgres Could Improve Part 1, 2

В своём блоге PG-Пятнетцы (PG Phriday, ср. со Вторниками #ruPostgres) Шон Томас (Shaun Thomas, 2ndQuadrant) анонсировал 4 части сериала 10 вещей в Postgres, которые можно улучшить:
  1. проблемы с ID транзакций;
  2. неприятные сюрпризы репликации;
  3. MVCC и почему надо быть внимательным с хранением;
  4. функциональность ядра.

Уже вышли 2 первые из них.

В первой речь, конечно, о wraparound, недостаточности 32 бит на идентификатор (и двух миллиардов транзакций) и vacuum. Добавлю от себя, что пока только у Postgres Pro Enterprise есть 64-битные счетчики транзакций, но движения в этом направлении понемногу происходят и в PostgreSQL. Шон, однако, надеется, что проблему решат новые движки подключаемых хранилищ (pluggable storage). А пока что советует поиграться с секционированием, мониторить упавшие подготовленные транзакции, прилагает список рекомендаций.

Вторая часть, про репликацию, ярче: хотя бы названия главок завораживают: прилив и отлив (ebb and flow), пить из пожарного шланга, затыкая дыры в дамбе. Эту серию, пожалуй, не отнесешь к in depth, но Шон расставляет акценты и напоминает о том, что на грешной земле разработчикам есть, чем заняться.

Кстати, формат становится модным: в Postgresso 21 было о 7 вещах в PG, которые можно улучшить автора из Cybertech Каарела Моппела можно сравнить. К тому же и сам Шон ссылается на статью в смежном жанре: 10 вещей, которые я ненавижу в Postgres Рика Бронсона (Rick Bronson), работающего с петабайтными базами. Понятно, что такие вещи как vacuum не обойдет ни один автор этого жанра, другие же пункты пересекаются отнюдь не везде. Stay tuned, любители жанра.

EXPLAIN ANALYZE May Be Lying to You

Неужели действительно врёт? Альваро Эрнандес (lvaro Hernndez) называет это (квантово-механическим) эффектом наблюдателя, и сам наблюдает увеличение в полтора раза времени запроса с EXPLAIN ANALYZE по сравнению с реальным запросом. Разгадка в обращении к системным часам Альваро объясняет, что происходит в обоих случаях. Эта статья обсуждалась на #ru.Postgres #22.




Образование на дому


Сертификация

C 1 июля В Postgres Professional возобновится процесс сертификации PostgreSQL DBA. На данный момент свободны 10 временнх слотов для записи. Сертификация будет проводиться при полном соблюдении санитарно-эпидемиологических мер маски, перчатки, дистанция.

Вебинары и митапы


Вторники #ruPostgres: #22, #23

Главный док Постгрес-вторников, где есть и новая ссылка для активного участия в Zoom, здесь.

На #23 начали с опроса DBA: есть ли у вас борода. 49.4% ответили Да. Поскольку гостем номера был Владимир Бородин (у Бородина как раз нет бороды), руководитель команды разработки DBaaS в Яндекс.Облаке, то много говорили об облачных решениях. Список затронутых (иногда совсем бегло) тем есть на подписи к видео, он огромен: тут и баги в MySQL, и о миграции многотерабайтных баз в облака, о шардинге в PG (относительно много), об Odyssey, pgbouncer, о multiprimary и о многом другом.

#22 был посвящен визуализации планов, о "вранье" EXPLAIN ANALYZE, о pgsentinel, datasentinel.io и о другом. Гвоздями программы были утилиты PASH Viewer (анализ wait events у активных сессий) и молодой plan-exporter (экспорт EXPLAIN-данных в инструменты визуализации прямо из psql).

Online @Databases Meetup #2

Митап в Mail.ru (точнее: Mail.ru Cloud Solutions & Tarantool) состоится 25 июля. Программа:
  • Как собрать гибридное облако с помощью Kubernetes, которое может заменить DBaaS. Пётр Зайцев, генеральный директор Percona;
  • от хозяев: Архитектура S3: 3 года эволюции Mail.ru Cloud Storage. Владимир Перепелица, архитектор платформы Mail.ru Cloud Solutions;
  • JSON[b] в Postgres: Пора великого объединения. Олег Бартунов, генеральный директор Postgres Professional;
  • Эволюция Postgres Pro за годы существования и стратегические планы по развитию. Иван Панченко, заместитель генерального директора Postgres Professional.


Теория & Практика миграции на PostgreSQL

Митап ФОРСа состоится 2-го июля. В программе:
  • Как перейти на PostgreSQL за 10 шагов. Иван Панченко, заместитель генерального директора Postgres Professional;
  • Переходим. Миграция на PostgreSQL: Ожидания и реальность. Алексей Береснев, ведущий преподаватель УКЦ ФОРС;
  • Практический опыт миграции на примере сервера мониторинга Zabbix на PostgreSQL. Олег Константинов, руководитель группы инженеров службы внедрения и сопровождения, ФОРС Центр разработки.;
  • Широкие возможности перехода на PostgreSQL: разработка приложений, инструмент миграции, кластер на OC Эльбрус. Александр Любушкин, технический директор ФОРС Телеком.


Postgres Vision 2020

Должна пройти в онлайне 23-24 июня. Брюс Момджан с Марком Линстером (Marc Linster) расскажут о будущем PostgreSQL в многооблачном мире. Олегу Бартунову предстоит за 25 минут развернуть энциклопедию полнотекстового поиска.



Конференции


The PGCon 2020

26-29 мая прошла первая крупная конференция целиком в онлайне. В мирное время PGCon происходит в Оттаве. Пока отзывы от прекрасно до ждал худшего. Большой минус в том, что отвлечься на рабочие и домашние дела намного легче, чем в офлайновой, поэтому исправно посещающих намеченные выступления заметно меньше. Многие рассчитывают просмотреть записи потом. Слайды части докладов выложены (в самых разных местах, но ссылки есть в программе), видео пока нет, но обещаны (кроме мастер-классов, которые только live).

От русскоязычного комьюнити выступили Илья Космодемьянский (слайды) и Николай Самохвалов (слайды) в мастер-классах, Александр Коротков рассказал о планах коммьюнити по шардингу, Андрей Бородин об индексах как расширениях, Олег Бартунов о JSONB-roadmap, Алексей Кондратов про Ptrack 2.0.

PG Day Russia

Перенесена на год на 9 июля 2021.

FOSS4G 2020
Пройдёт в Калгари, Канада, 24-29 августа. Заявки принимаются.

PGDay Ukraine

Однодневная конференция в 2 потока должна состояться 5 сентября во Львове. Среди выступающих Магнус Хагандер (Magnus Hagander), Илья Космодемьянский, Деврим Гюндюз (Devrim Gndz), Томас Вондра (Tomas Vondra), Олексий Васильев и Олексий Клюкин, Павло Голуб. Программа здесь.

pgDay Israel 2020
Намечена на 10-е сентября в Тель-Авиве. Выступят в том числе Иван Панченко, Павло Голуб, Дорофей Пролесковский, Андрей Бородин.

PGDay Austria
В летней резиденцим Габсбургов замке Шёнбрунн, Вена 18 сентября должна пройти конференция PGDay Austria.





Подписывайтесь на канал postgresso!

Идеи и пожелания присылайте на почту: news_channel@postgrespro.ru
Предыдущие выпуски: #21, #20, #19, #18, #17, #16, #15, #14, #13, #12, #11 (спец), #10, #9, #8, #7, #6, #5, #4, #3, #2, #1
Подробнее..

Postgresso 23

29.07.2020 00:23:11 | Автор: admin

Жизнь продолжается. А мы продолжаем знакомить вас с самыми интересными новостями PostgreSQL

Главное событие


PostgreSQL 13 Beta 2

Релиз беты состоялся. Загрузить можно отсюда, информация для бета-тестеров здесь.

Напоминаем, что в начале апреля мы сделали обзор нового в версии 13: Много ли нового в чёртовой дюжине (спойлер: много). С тех пор по определению радикальных изменений произойти не могло. Некоторые изменения по сравнению с beta 1 всё же есть, о них написано в анонсе. Release notes 13-й версии здесь. А на этой странице расписание грядущих релизов PostgreSQL.

Релизы


pg_probackup 2.4.1

Новое в версии: прежде всего инкрементальное восстановление. Можно использовать повторно валидные неизмененные страницы, которые лежат в целевой директории. Это сильно увеличивает скорость, уменьшает нагрузку на сеть и потребление I/O. Соответственно появилась новая опция для команды restore: -I | --incremental-mode mode (mode может принимать значение checksum и lsn). Документация к этой утилите здесь.

barman 2.11

Пакет облачных утилит пополнился ещё двумя:
barman-cloud-restore и
barman-cloud-wal-restore
Теперь можно восстанавливать инстанс PostgreSQL, используя полный бэкап, созданный командами barman-cloud-wal-archive и barman-cloud-backup.

Этим новшества версии не ограничиваются, вот чейнджлог. Но об этих облачных новшествах есть небольшая статья-руководство в блоге 2ndQuadrant: начиная с установки пакета barman-cli-cloud, в которым теперь собраны все облачные утилиты и настройки, до планов улучшений в грядущей версии.

pgAdmin4 4.23

В новой версии не слишком радикальные изменения: прежде всего появилась поддержка Row Security Policies. Можно добавить название группы серверов в окне Schema Diff, а при сравнении схем теперь можно добавить опцию, позволяющая игнорировать пробелы.

Cypex 1.0

Расшифровывается Cybertec Prototyping Express и претендует на самое передовое средство разработки приложений с доступом к PostgreSQL. Скорость и простота разработки будет достигнута благодаря тому, например, что Cypex умеет предлагать (предсказывать) структуру приложения, исходя из модели данных.

PostgresDAC 3.8

Вышла новая версия набора компонентов прямого доступа к PostgreSQL от Microolap Technologies из Черноголовки. В ней появилась поддержка PostgreSQL 12 и RAD Studio 10.4 Sydney от Embarcadero Technologies. Появилась поддержка RAD Studio 10.4 Tokyo (Delphi and C++ Builder). Загрузить можно отсюда.

pgwatch2 v1.8.0

В новой версии pgwatch2, утилиты для мониторинга Postgres, много изменений. Среди них поддержка метрик PostgreSQL 13, Pgpool-II, TimescaleDB.

Появился мониторинг доступа к объектам (таблицы/представления, схемы, функции, БД) и к системным ролям прежде всего к ролям суперпользователей, но и к логин-ролям и прочим.
Теперь можно кешировать и разделять (share) на уровне инстанса и глобально метрики, общие для разных БД WAL, загрузку CPU и др. чтобы не получать их для каждой базы. Это экономит трафик.

Интервал кеширования настраивается. Новые метрики через базу работают с утилитами бэкапа/восстановления WAL-G и pgBackRest, метрики на PL/Python собирают информацию на уровне OS и отдают как SQL, чтобы можно было, например, визуализировать в Grafana.

Есть обширный чейнджлог.

pgsodium 1.2.0

Это расширение адаптирует функции криптографической библиотеки libsodium к SQL.
Со времён версии 1.1.1, о которой мы писали в прошлом выпуске, появились три уровня доступа, реализованных в соответствующих ролях, для доступа к API:
  • pgsodium_keyiduser может пользоваться только функциями API по идентификатору ключа, а видеть или использовать сырые ключи (в типе bytea) не может;
  • pgsodium_keyholder может видеть и использовать ключи и пары ключей, но не может генерировать их или получать из имеющихся (derive);
  • pgsodium_keymaker может делать всё, что душе угодно.

Есть, конечно, и другие изменения. О них здесь.

pg_chameleon 2.0.14

В версии этой утилиты репликации из MySQL в PostgreSQL улучшили поддержку пространственных типов данных. Если в целевой БД установлен PostGIS, то пространственные типы point, geometry, linestring, polygon, multipoint, multilinestring, geometrycollection преобразуются в PostGIS-овский тип geometry и данные реплицируются с использованием стандартного для геоданных формата WKB (Well-Known Binary). Поскольку реализация WKB в MySQL нестандартна, pg_chameleon убирает первые 4 байта из декодированных бинарных данные перед тем, как залить их в PostgreSQL.

Если параметр keep_existing_schema установлен в yes, то теперь хамелеон пересоздает индексы и первичные ключи в процессе init_replica. Когда реплика приходит к согласованному состоянию, пересоздаются и внешние ключи.

Crunchy PostgreSQL Operator 4.4.0

Это утилита развертывания и управления PostgreSQL-кластеров в среде Kubernetes (не путать с разработкой DBaaS Zalando Postgres Operator for Kubernetes, о которую мы упоминали в Postgresso 22). Она работает в связке с Crunchy Container Suite.

В новой версии поддерживается PostGIS 3.0. В PostGIS-контейнерах доступен pgRouting. Поддерживается pgBackRest 2.27, pgBouncer 1.14. PostgreSQL Operator протестирован с Kubernetes 1.15 1.18, OpenShift 3.11+, OpenShift 4.4+, Google Kubernetes Engine (GKE) и VMware Enterprise PKS 1.3+.

Возможно создание кластера из репозитория pgBackRest. Флаги при создании см. в Major Features релиза. Доделывается понемногу RBAC (Role-Based Access Control). Внимание! Параметр сверки DYNAMIC_RBAC переименован в RECONCILE_RBAC. TLS Authentication (аутентификация на транспортном уровне). А ещё для PostgreSQL Operator теперь есть кубернетовский Helm Chart.

ORC Foreign Data Wrapper 1.0.0

Это FDW для файлов формата Apache ORC первый релиз, который поддерживает формат файлов ORC 0.12. В этой версии FDW пока не поддерживаются DML-операции. Файлы ORC доступны только для чтения. Можно импортировать схемы из любой директории, содержащей файлы с расширением .orc.

Статьи


Заметка Брюса Момджана объясняет: json и jsonb не просто типы данных, они сами могут содержать в себе много типов.
SELECT x, jsonb_typeof(x), pg_typeof(x) FROM test;
   x    | jsonb_typeof | pg_typeof--------+--------------+----------- "abc"  | string       | jsonb 5      | number       | jsonb true   | boolean      | jsonb null   | null         | jsonb (null) | (null)       | jsonb

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

AQO адаптивная оптимизация запросов в PostgreSQL

Новый автор корпоративного хабра Postgres Professional Павел Толмачёв пишет о модуле (расширении) aqo, которое поставляется с Postgres Pro Enterprise (может использоваться и с PostgreSQL). В обстоятельной статье есть и об установке aqo, и о принципах работы, и о том, почему планировщик может выбирать неоптимальный план, о том, к чему приводит использование зависимых (коррелированных) условий. Ну и главное: о способах влияния на работу планировщика, о том, когда aqo успешно подсказывает планировщику кардинальность грядущего результата. Дока о модуле здесь, а сам он на гитхабе компании.

PgBouncer on Kubernetes and how to achieve minimal latency. Experiments with connection poolers on Kubernetes for Postgres Operator

Дмитрий Долгов, Zalando, предлагает разобраться с поддержкой пулинга соединений, появившейся в Postgres Operator 1.5 (мы писали о новшествах в этой версии в Postgresso 21). Чтобы разобраться с масштабируемостью, Дмитрий измерял на pgbench производительность инстанса PostgreSQL:
c одним инстансом PgBouncer на одном физическом ядре;
с двумя инстансами PgBouncer в своих гипертредах, но на одном физическом ядре;
с двумя инстансами PgBouncer на двух ядрах, но с возможным влиянием процессов в других гипертредах.
Анализ результатов обнаруживает не вполне ожидаемые не вполне приятные эффекты. Вывод: следует аккуратно конфигурировать использование CPU.

PostgreSQL Antipatterns: анализируем блокировки SELF JOIN vs WINDOW

В блоге компании Тензор Кирилл Боровиков aka Kilor пишет о том, как анализировать собранные из логов и уже загруженные в базу записи о блокировках still waiting for ExclusiveLock и acquired ExclusiveLock. И о подводных и надводных камнях, о том, как сильно упростить себе задачу, используя оконные функции. Это продолжение DBA: в погоне за пролетающими блокировками, где как раз рассказывалось, как распарсить записи в логах и загрузить в базу.

Foreign data wrappers: PostgreSQL's secret weapon?

В статье на сайте Splitgraph демонстрируются возможности FDW на примере использования расширения multicorn, которое даёт возможность писать расширения FDW на Python и интегрировать PostgreSQL с инструментами Splitgraph.

Postgres Tips: How to convert 2 Billion Rows to Bigint with Citus

Эту статью от Citus (то есть Microsoft) жёстко раскритиковали на Постгрес-Вторнике-25 (см. ниже в разделе Вебинары и митапы), но, может, вам будет интересно составить собственное мнение.

Recreating YikYak with Postgres

Фактически в статье речь идёт не о сети YikYak, а о расширениях cube и earthdistance. Это немного неожиданно: думалось, что речь пойдёт о PostGIS. В статье используются: функции earth_box и ll_to_earth, оператор Contains?, то есть @>, индекс GiST. Ищут не n ближайших соседей, а сколько объектов в заданной окружности. Статья простенькая, но тема earthdistance встречается не часто.

Partitioning a large table without a long-running lock

Эндрю Данстан (Andrew Dunstan) пишет о том, как секционировать большую таблицу и не уснуть в процессе. Для демонстрации Эндрю создает табличку с 10 млн строк и разбивает её на 4 секции по диапазонам. При этом используется промежуточное представление как UNION строк в несекционированной и в секционированной таблицах. Перловый скрипт перетаскивает строки в новую таблицу порциями. Такую программу можно прервать в любой момент, что удобно.

Облака


Postgres Professional и Mail.ru Cloud Solutions запускают Postgres Pro Cloud

Эта совместная разработка, облачный сервис управляемой базы данных будет предоставляться по модели Database-as-a-Service. Установка, настройка и поддержка СУБД осуществляется на стороне провайдера. Mail.ru Cloud Solutions и Postgres Pro помогают с миграцией и консультируют по построению масштабируемой и отказоустойчивой структуры хранения данных, а также по настройке взаимодействия с On Premises-системами, процессами ETL и Streaming, построению Data Warehouse и Data Lake.

Managed Databases now supports PostgreSQL 12

DigitalOcean прибавил к своей коллекции БД PostgreSQL 12. Есть средства бесшовного автоматического апгрейда с мажорных версий PostgreSQL 11 на мажорные 12 без остановки работы промышленной базы.

В DigitalOcean обращают внимание потенциальных пользователей на такие новшества 12-й версии как SQL/JSONpath, оптимизацию CTE (запросов с WITH) и генерируемых столбцов.

Персоны



Персоной недели в июне побывал уроженец Севастополя Олексий (Alex) Клюкин, работавший над Patroni и Postgres Operator в Zalando. Теперь работает в Adjust.com над инфраструктурой PostgreSQL.

С тех пор в этом качестве выступило немало и знаменитых людей, и не слишком известных в сообществе (правда они нередко уж слишком лаконичны):
Умайр Шахид (Umair Shahid)
Стейси Хейслер (Stacey Haysler)
Кохеи Кайгаи (Kohei Kaigai)
Эндрю Данстан (Andrew Dunstan)
Саймон Риггс (Simon Riggs)
Томас Вондра (Tomas Vondra)

Вебинары и митапы


Постгрес-вторники (#RuPostgres)

В-27: Разговор про коррупцию и антикоррупционные меры в PG, опыт Яндекс.Облака, DataEgret, Postgres.ai. В гостях эксперты Яндекс.Облака Андрей Бородин и Дмитрий Сарафанников.

В-26: Аналитика в Postgres. Снова (см. В-24) про шардинг. Миграции БД. JOIN в Монге.
Кое-что про то, как делать изменения под нагрузкой, имея в виду:
Database Migration Style Guide GitLab
Partitioning a large table without a long-running lock
PostgreSQL at Scale: Database Schema Changes Without Downtime

В-25:
В-25: Быстрая диагностика проблем Postgres с Алексеем Лесовским. pgCenter.
pgCenter с чего всё началось, как развивалось. Возможности; демо; ограничения (statement_timeout и прочее) pgCenter.

В-24:
Транзакции, новые распределённые СУБД (YDB и др.), FDW, шардинг.
В гостях: Стас Кельвич (сейчас Яндекс, до этого Postgres Professional).
YDB, Google Spanner, CockroachDB каковы различия.
Согласование в распределённых транзакциях и зачем атомные часы.

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

Конференции


PGConf.EU 2020
Отменена. Переносится на 2021.

PGDay Ukraine
Должна состояться во Львове 5-го сентября.

pgDay Israel 2020
Намечена на 10-е сентября в Тель-Авиве.

PGDay Austria
Ожидается в замке Шёнбрунн (около Вены) 8-го сентября.



Предыдущие выпуски: #22
#21, #20, #19, #18, #17, #16, #15, #14, #13, #12, #11 (спец), #10, #9, #8, #7, #6, #5, #4, #3, #2, #1
Подробнее..

PostgreSQL 14 Часть 1 или июльский разогрев (Коммитфест 2020-07)

14.08.2020 18:11:43 | Автор: admin
Выход PostgreSQL 13, о возможностях которого мы уже писали, планируется только осенью. Ничего принципиально нового в нем уже не появится. Поэтому самое время перейти к PostgreSQL 14.

Жизненный цикл нововведений 14 версии состоит из 5 коммитфестов. Первый из которых июльский уже завершился, а значит есть что обсудить.

Принятых изменений было намного больше, чем будет описано. Рассмотрены в основном патчи с новым или измененным функционалом СУБД. Именно такие изменения представляют наибольший интерес для пользователей PostgreSQL. А то что не попало, как правило, относится к следующим категорям: исправления ошибок, рефакторинг, инфраструктура проекта, документация(почти всегда), комментирование кода, тестирование.

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

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

Итак, начинаем.

Новости PostgreSQL 13


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

pg_stat_activity.leader_pid IS NULL для ведущего процесса
commit: 11a68e

После заморозки кода 13 версии изменились правила заполнения нового столбца leader_pid в pg_stat_activity номер ведущего процесса при выполнении параллельных запросов. Первоначально предполагалось заполнять этот столбец не только для всех рабочих процессов, участвующих в выполнении запроса, но и для самого ведущего процесса. Теперь у ведущего процесса leader_pid будет оставаться незаполненным.

Документация: новое форматирование таблиц в главе Функции и операторы
commit: e894c61

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

Параметра wal_keep_segments больше нет
commit: c3fe108

Вместо него wal_keep_size. Теперь нужно оперировать не количеством сегментов в pg_wal, а их размером. Сделано для унификации с новым для 13 версии параметром max_slot_wal_keep_size максимальный размер файлов WAL, сохраняемых для слотов репликации.

Мимо этого изменения не смог пройти depesz в своей новой серии Waiting for PostgreSQL 14. Но изменение попадет и в 13 версию, начиная с beta3.

pg_validatebackup pg_verifybackup
commit: dbc60c5

Новая для 13 версии утилита pg_validatebackup после заморозки кода переименована и будет называться pg_verifybackup.

sslminprotocolversion ssl_min_protocol_version, sslmaxprotocolversion ssl_max_protocol_version
commit: 401aad6

Новые для 13 версии параметры sslminprotocolversion и sslmaxprotocolversion переименованы: ssl_min_protocol_version и ssl_max_protocol_version.

ALTER NO DEPENDS ON EXTENSION ...
commit: 5fc7039

В версии 9.6 добавили команду ALTER DEPENDS ON EXTENSION для указания, что объект зависит от расширения. Но забыли реализовать обратный вариант команды на снятие зависимости. Упущение исправлено и портировано в 13 версию. Из-за отсутствия жалоб портировать в более ранние версии не стали.

Новый параметр hash_mem_multiplier
commit: d6c08e2

Возможность не выходить за установленные пределы оперативной памяти(work_mem) при создании хеш-таблицы появилась еще на момент заморозки кода 13 версии. Если на этапе выполнения запроса окажется, что планировщик ошибся в оценках и work_mem не хватает будут использоваться временные файлы. Это хорошо, т.к. нынешнее поведение использовать столько памяти, сколько потребуется, а это не всегда приятное соревнование с OOM-killer.

Для управления поведением планировщика предлагались параметры enable_groupingsets_hash_disk и enable_hashagg_disk. К моменту выпуска 13 beta2 оба параметра заменили на hashagg_avoid_disk_plan. Но и этого оказалось недостаточно. Теперь вместо hashagg_avoid_disk_plan появился hash_mem_multiplier.

Название взято по аналогии с bgwriter_lru_multiplier и представляет собой множитель, на который планировщик умножает work_mem, чтобы получить объем памяти, который может использоваться для операции хеширования. Значение по умолчанию 1, что не меняет предыдущего поведения память для хеширования не должна превышать work_mem.

Управляя этим параметром, и не меняя work_mem, можно дать планировщику больше шансов выбрать варианты с хеш вместо менее требовательных к наличию свободной памяти сортировок (в частности hash join вместо merge join).

EXPLAIN ANALYZE: изменения в формате вывода узла HashAggregate
commit: 0e3e1c4

А вот как будут выглядеть операции хеширования в плане запроса. Посмотрим на примере такого запроса к демо-базе:
EXPLAIN (ANALYZE) SELECT tf.fare_conditions, count(*)                    FROM ticket_flights tf GROUP BY tf.fare_conditions;

Ограничимся лишь фрагментом плана с узлом HashAggregate.
Версия 12:
->  Partial HashAggregate      Group Key: fare_conditions      ->  Parallel Seq Scan on ticket_flights tf

Версия 13beta2:
->  Partial HashAggregate      Group Key: fare_conditions      Peak Memory Usage: 24 kB      Worker 0:  Peak Memory Usage: 24 kB      Worker 1:  Peak Memory Usage: 24 kB      ->  Parallel Seq Scan on ticket_flights tf

Теперь:
->  Partial HashAggregate      Group Key: fare_conditions      Batches: 1  Memory Usage: 24kB      Worker 0:  Batches: 1  Memory Usage: 24kB      Worker 1:  Batches: 1  Memory Usage: 24kB      ->  Parallel Seq Scan on ticket_flights tf

Чтобы не играть в игру найди 10 отличий вот они, и их 5:

  • счетчик пакетов (batches) начинается с 1, а не 0;
  • Batches выводится всегда, даже если пакет был всего 1;
  • для текстового формата выводится Batches вместо HashAgg Batches;
  • для текстового формата выводится Memory Usage вместо Peak Memory Usage;
  • Batches выводится перед Memory Usage

Изменение особенно важно для тех, кто разрабатывает свои инструменты для анализа плана запросов.

Отслеживание пауз в работе очистки
commit: cedffbd

Паузы в работе очистки ([autovacuum_]vacuum_cost_delay) теперь отображаются в pg_stat_activity.wait_event_type=Timeout и wait_event=VacuumDelay. До этого считалось что процесс ничего не ждет и столбцы wait_enent* были не заполнены.

Хватит о 13 версии, начиная со следующего раздела переходим к эксклюзиву версии 14.

Клиентские приложения


vacuumdb --no-truncate --no-index-cleanup
commit: 9550ea3

Утилита vacuumdb получила два новых аргумента командной строки: --no-truncate и --no-index-cleanup. С их помощью можно отключать соответствующие параметры VACUUM, появившиеся в 12 версии: TRUNCATE (нужно ли уменьшать файл, если последние страницы полностью очищены) и INDEX_CLEANUP (нужно ли выполнять очистку индексов).

Мониторинг и управление


pg_stat_statements: отслеживание количества обработанных строк у некоторых служебных команд
commit: 6023b7e

Раньше для команд CREATE TABLE AS, SELECT INTO, CREATE MATERIALIZED VIEW, FETCH в pg_stat_statements.rows не фиксировалось количество обработанных записей. Теперь эта информация стала доступна:
CREATE TABLE bookings_copy AS SELECT * FROM bookings;
SELECT 262788
SELECT query,rows FROM pg_stat_statements     WHERE query LIKE 'CREATE TABLE bookings_copy%';
                        query                         |  rows  ------------------------------------------------------+-------- CREATE TABLE bookings_copy AS SELECT * FROM bookings | 262788


Новые столбцы в pg_prepared_statements: generic_plans, custom_plans
commit: d05b172

В pg_prepared_statements появилась информация о количестве запросов, выполненных с общим и частным планом. Следующая цель добавить такую же информацию в pg_stat_statements.

По умолчанию (plan_cache_mode = auto), если после пяти планирований запроса планировщик видит, что общий план будет не хуже частного, то он переходит на общий план, минимизируя свою работу. В следующем примере подготовленный запрос выполняется семь раз и после пятого повторения последние два раза выполняются уже с общим планом:
\d pg_prepared_statements
                  View "pg_catalog.pg_prepared_statements"     Column      |           Type           | Collation | Nullable | Default-----------------+--------------------------+-----------+----------+--------- name            | text                     |           |          | statement       | text                     |           |          | prepare_time    | timestamp with time zone |           |          | parameter_types | regtype[]                |           |          | from_sql        | boolean                  |           |          | generic_plans   | bigint                   |           |          | custom_plans    | bigint                   |           |          |
PREPARE q(text) AS SELECT count(*) FROM bookings WHERE book_ref = $1;SELECT $$EXECUTE q('ABCDEF')$$ FROM generate_series(1,7)\gexecSELECT generic_plans, custom_plans FROM pg_prepared_statements WHERE name = 'q';
 generic_plans | custom_plans---------------+--------------             2 |            5


Доступ не суперпользователям к функциям, работающим с источниками репликации
commit: cc07264

Функциями, работающим с источниками репликации (pg_*replication_origin*), теперь могут пользоваться не только суперпользователи. Ранее проверка на суперпользователя была жестко зашита в коде. Проверку убрали и отобрали права на исполнение у public. Теперь суперпользователь может командой GRANT выдать разрешение на выполнение этих функций любым пользователям. Это в том числе дает возможность запрашивать данные из представления pg_replication_origin_status обычным пользователям.

В начале переписки рассматривалась идея предоставить роли pg_monitor доступ к pg_replication_origin_status. Но это в настоящий момент не реализовано.

Функция pgstattuple_approx поддерживает таблицы TOAST
commit: ee0202d

Функция pgstattuple_approx предоставляет приблизительную, но более быструю, альтернативу функции pgstattuple из одноименного расширения для оценки распухания объектов базы данных. Ускорение обеспечивается тем, что таблица сканируется не целиком, а с учетом карты видимости и карты свободного пространства. До 14 версии примерную оценку нельзя было получить для таблиц TOAST. Теперь это исправлено.

Производительность


У этой группы патчей есть очень хорошая особенность. Как правило, для получения лучшего быстродействия ничего не нужно делать. Просто переходим на новую версию и всё начинает работать быстрее. Хотя для некоторых изменений предусмотрены ручки (параметры), которые нужно научиться аккуратно подкручивать для получения наилучшего результата.

Кажется, что для описания увеличения производительности хорошо бы привести результаты замеров. Но их не будет. Во-первых, это достаточно сложная работа, требующая очень тщательной подготовки, разработки методики и описания условий проведения тестов. А во-вторых, какие бы впечатляющие результаты не приводились в замерах, они всё равно получены на некой абстрактной системе. И полностью доверять им не стоит. Любую оптимизацию нужно проверять на своей собственной системе и нагрузке. Поэтому поверим разработчикам PostgreSQL, которые на своих тестах получили положительные результаты.

Оптимизация добавления записей в каталоги pg_attribute и pg_shdepend
commit: e3931d0

Добавление набора записей в pg_attribute, например при создании таблицы, теперь выполняется за один раз. По словам разработчиков, в некоторых случаях это приводит к 15% сокращению записи в WAL. Такая же оптимизация для pg_shdepend.

Оптимизировано выполнение операторов PL/pgSQL
commit: 1f902d4, fe2e206

PL/pgSQL стал чуть быстрее. Правда, это не особенно заметно на архитектуре x86_64, а вот aarch64 выиграла однозначно.

Оптимизация RETURN QUERY в PL/pgSQL
commit: 2f48ede

Оптимизирована не только выдача результата запроса из функции, но и добавлена возможность параллельного выполнения запросов в RETURN QUERY, RETURN QUERY EXECUTE.

Создадим функцию с оператором RETURN QUERY.
CREATE FUNCTION get_fc(OUT fare_conditions varchar, OUT total bigint)    RETURNS SETOF RECORD AS $$BEGIN    RETURN QUERY SELECT tf.fare_conditions, count(*)                   FROM ticket_flights tf GROUP BY tf.fare_conditions;END;$$ LANGUAGE plpgsql STABLE PARALLEL SAFE;

Подключим auto_explain для получения плана запроса и выполним функцию:
SET auto_explain.log_min_duration = 0;SET auto_explain.log_nested_statements = on;SELECT * FROM get_fc();

В журнале видим, что использовался план с параллельным выполнением:
\! tail -n18 logfile
2020-08-06 23:23:34.825 MSK [17278] LOG:  duration: 80.701 ms  plan:    Query Text: SELECT tf.fare_conditions, count(*)                       FROM ticket_flights tf GROUP BY tf.fare_conditions    Finalize GroupAggregate  (cost=16250.86..16251.62 rows=3 width=16)      Group Key: fare_conditions      ->  Gather Merge  (cost=16250.86..16251.56 rows=6 width=16)            Workers Planned: 2            ->  Sort  (cost=15250.84..15250.85 rows=3 width=16)                  Sort Key: fare_conditions                  ->  Partial HashAggregate  (cost=15250.79..15250.82 rows=3 width=16)                        Group Key: fare_conditions                        ->  Parallel Seq Scan on ticket_flights tf  (cost=0.00..13072.19 rows=435719 width=8)2020-08-06 23:23:34.825 MSK [17278] CONTEXT:  SQL statement "SELECT tf.fare_conditions, count(*)                       FROM ticket_flights tf GROUP BY tf.fare_conditions"    PL/pgSQL function get_fc() line 3 at RETURN QUERY2020-08-06 23:23:34.825 MSK [17278] LOG:  duration: 82.101 ms  plan:    Query Text: SELECT * FROM get_fc();    Function Scan on get_fc  (cost=0.25..10.25 rows=1000 width=40)


Выделение быстрой динамической разделяемой памяти для параллельных запросов
commit: 84b1c63

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

Параллельные запросы: данные в узле Gather обрабатываются более эффективно
commit: cdc7169

И этим всё сказано. Никаких настроек, параллельные запросы станут работать быстрее.

Все функции в расширении btree_gist помечены как PARALLEL_SAFE
commit: d98c08c

Теперь запросы, использующие операторы этого расширения, могут выполняться в параллельном режиме.

Оптимизация ввода-вывода для параллельного последовательного сканирования
commit: 56788d2

Раньше рабочие процессы получали на обработку по одному блоку за раз. Теперь получают порциями, размер которых зависит от размера таблицы. Тестирование патча показало хорошие результаты на дисках SSD для операционных систем Linux, FreeBSD, Windows. Однако для облачных провайдеров результаты не столь очевидны.

Кеширование размера файлов отношений при восстановлении
commit: c5315f4

При восстановлении, за счет кеширования, существенно сократилось количество вызовов, вычисляющих размер файлов вызовов lseek(SEEK_END). А это сокращение дисковых операций. Реплики работают в режиме восстановления только в один процесс. Любая оптимизация здесь всегда к месту.

COPY FROM в двоичном формате стала быстрее
commit: 0a0727c

Увеличена производительность загрузки данных командой COPY FROM в двоичном формате. В частности простые тесты показали ускорение на 30% в Linux, еще больше в MacOS.

COPY FROM в двоичном формате расходует меньше памяти
commit: cd22d3c

Еще одно небольшое улучшение для COPY FROM в двоичном формате позволяет сэкономить ~ 65Кб оперативной памяти на запуск.

Репликация


Логическая репликация сможет передавать данные в двоичном формате
commit: 9de77b5

Это изменение делает логическую репликацию быстрее. При создании/изменении подписки можно запросить у сервера публикации передачу в двоичном формате:
CREATE|ALTER SUBSCRIPTION  WITH (BINARY = ON)

По умолчанию двоичный формат отключен. После включения двоичные данные будут передаваться для тех типов, у которых определены функции send/receive. В противном случае используются функции указанные для input/output.

Сервер


Системные функции получения информации и адресации объектов возвращают NULL для несуществующих объектов
commit: 2a10fdc

В предыдущих версиях вызов подобных функций приводил к ошибке:
SELECT pg_describe_object('pg_class'::regclass, 0::oid, 0);
ERROR:  cache lookup failed for relation 0

Но ошибка cache lookup failed предназначена для внутреннего использования и не должна быть видна пользователям. Все видимые типы ошибок описаны в документации. Теперь запрос возвращает NULL.

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

Управление размером огромных страниц
commit: d2bddc2

Новый параметр huge_page_size для управления размером огромных страниц. По умолчанию 0, размер огромных страниц определяется настройками ОС.

У типа numeric появились значения бесконечность и минус бесконечность
commit: a57d312

Поведение такое же как и у соответствующих значений для типов с плавающей точкой. Это дает возможность конвертировать значения с плавающей точкой (и интерфейсы их использующие) в числа с произвольной точностью.

Разное


Добавлен метод amadjustmembers для проверки членов класса операторов
commit: 9f96827

Началось всё с того, что в расширении intarray оказалось невозможным средствами SQL удалить оператор <@ из класса операторов для GiST. В результате был доработан интерфейс для индексных методов доступа. В частности появилась функция amadjustmembers. Расширение intarray пока осталось без изменений.

Операторы + и для типа pg_lsn
commit: 9bae7e4

Еще не успели попробовать появившиеся в 13 версии агрегатные функции min и max для типа данных pg_lsn, как в 14-ю версию добавили арифметические операторы для добавления/вычитания байтов:
SELECT w.lsn, w.lsn +1, w.lsn -1 FROM (SELECT pg_current_wal_lsn()) AS w(lsn);
    lsn    | ?column?  | ?column?  -----------+-----------+----------- 0/EF04B78 | 0/EF04B79 | 0/EF04B77


Получение информации об источнике репликации для транзакции
commit: b1e48bb

Источник репликации можно получить новой функцией pg_xact_commit_timestamp_origin. Эту же информацию добавили в pg_last_committed_xact.

Чтобы получить информацию о времени фиксации транзакции и источнике репликации должен быть включен параметр track_commit_timestamp:
SHOW track_commit_timestamp;
 track_commit_timestamp------------------------ on
SELECT pg_current_xact_id();
 pg_current_xact_id --------------------                721
SELECT * FROM pg_xact_commit_timestamp_origin('721'::xid);
           timestamp           | roident-------------------------------+--------- 2020-08-10 13:57:18.103297+03 |       0
SELECT * FROM pg_last_committed_xact();
 xid |           timestamp           | roident-----+-------------------------------+--------- 721 | 2020-08-10 13:57:18.103297+03 |       0


На этом пока всё. Продолжение следует после сентябрьского коммитфеста.
Подробнее..

Postgresso 24

07.09.2020 16:04:06 | Автор: admin

Жизнь продолжается. А мы продолжаем знакомить вас с самыми интересными новостями PostgreSQL.
На этот раз мы решили немного изменить формат Постгрессо: теперь никакого информационного равноправия. Об одних релизах и статьях будем рассказывать подробней, о других в паре строк. Выбор субъективен, конструктивная критика приветствуется.


Релизы


PostgreSQL 13 beta 3

В 3-й бете есть изменения по сравнению с 2-й бетой, смотрите на страничке релиза.

Одновременно с Beta 3 вышли обновления: 12.4, 11.9, 10.14, 9.6.19 и 9.5.23. В них закрыты две обнаруженные бреши в безопасности, связанные с путём поиска (search_path) элементов (таблиц, функций, операторов и так далее) при создании расширений и при логической репликации. Два с лишним года назад была найдена уязвимость CVE-2018-1058, позволяющая использовать особенности работы с переменной search_path (она определяет порядок поиска в схемах при обращении к объектам БД) для запуска злокозненного кода. При неаккуратном использовании этой переменной, враг может перехватить управление над выполнением запросов и затем запустить произвольный SQL-код с правами атакуемого пользователя. Об этом можно прочитать, например, здесь. Эти опасности были объяснены, меры предосторожности перечислены. Теперь оказалось, что мер недостаточно при логической репликации и при создании расширений.

Теперь при логической репликации процессы send и receive будут исполняться с пустой строкой search_path. При создании расширений атакующий, если у него были права создавать новые объекты в расширении, мог запускать опасный код под суперпользователем. Сейчас расширения подправили и создали инструкцию для тех, кто собирается разрабатывать новые расширения.

За beta3 не последует beta4: релизная группа, то есть Джонатан Кац (Johnathan S. Katz), Альваро Эррера (Alvaro Herrera) и Питер Гайген (Peter Peter Geoghegan) пишут 2 сентября, что, проанализировав незакрытые пункты, можно сразу готовить релиз-кандидат 1 (RC1) на 17-е сентября. И, если критических проблем не обнаружится, 24-го сентября уже основную версию PostgreSQL 13. Ну а о том, много ли нового в Чёртовой Дюжине, мы уже писали.

Новые релизы Postgres Pro Enterprise/Standard

Вышли версии Postgres Pro Enterprise 12.4.1, 11.9.1, 10.14.1, 9.6.19.1, Standard 12.4.1, 11.9.1, 10.14.1, 9.6.19.1.

Изменения в Enterprise 12.4.1, например, такие:
  • устранена ошибка в оптимизации планировщика, приводившая к неправильной оценке количества строк при включённом параметре enable_compound_index_stats;
  • исправлена ошибка в расширении pgpro_scheduler, приводившая к тому, что функция schedule.stop() могла не остановить выполняющиеся задания;
  • улучшено расширение rum: при выполнении запросов с весами теперь не требуется перепроверять результаты этих запросов по таблице, так что они выполняются гораздо быстрее;
  • исправлены ошибки и в BRIN;
  • устранена ошибка, вследствие которой могли теряться результаты при обработке поисковых запросов с использованием оператора отрицания;
  • в новой версии multimaster включена функциональность, реализованная в Postgres Pro Enterprise версии 11.8.1 (ранее она оставалась недоступной при обновлении Postgres Pro Enterprise);
  • приложение pg_probackup обновлено до версии 2.4.2.

Last but not least (а для многих и самое важное):
12.4.1 и 11.9.1 теперь умеют благодаря опыту Антона Дорошкевича (ИнфоСофт) и усилиям Андрея Билле (Postgres Professional) при установке настраивать инстанс на работу с 1С (pg-setup inidb --tune=1C).

mamonsu 2.5.1

mamonsu агент мониторинга для сбора метрик операционной системы и Postgres, разработанный Postgres Professional. Главное в новой версии это окончательный переход на python 3 в связи с тем, что в 2020 году уже заканчивается поддержка python 2. Есть и другие обновления. Например, два новых плагина. Первый плагин (он называется точно так же: pg_probackup) позволяет следить за размером каталогов бэкапа, которые хранят WAL и файлы бэкапа, созданные утилитой pg_probackup.

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

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

В mamonsu есть плагины, которые появляются при установке (в каталоге mamonsu/plugins). Все они перечислены в примере конфигурационного файла. При установке этот файл автоматически подставляется как конфигурационный файл по умолчанию. Метрики в стандартной установке перечислены в середине файла README.rst. Но у пользователя есть еще и возможность самому написать плагин. Структура каждого питоновского файла, собирающего метрики состоит из определённого набора функций.

В блоге Zabbix выложена статья-расшифровка доклада разработчицы Дарьи Вилковой (Postgres Professional) для Zabbix Meetup Online.

dbForge Studio for PostgreSQL v2.3

Это графический инструментарий для работы с SQL в Postgres под Windows: с редактором кода, разноцветным форматированием его, генератором скриптов и профайлером (окна профайлера можно увидеть на скриншотах). Платный (трайл 30 дней). Производитель этой студии а также довольно популярной утилиты dbForge Data Compare for PostgreSQL компания Devart (головной офис в Праге, разработчики в Харькове).

В новой версии революционных изменений нет: например, поддержка PostgreSQL 12 генерация скриптов появились в 2.2, но много удобств добавлено.





Генератор скриптов, который создает соответствующий скрипт в ответ на действия мышью, научился создавать их для: DROP/CREATE TABLE, DROP/CREATE SEQUENCE, DROP/CREATE, CREATE INDEX. Улучшилось форматирование SQL, теперь предложения с CREATE TRIGGER, CREATE INDEX, CREATE SEQUENCE, CREATE TABLE, CREATE VIEW, CREATE MATERIALIZED VIEW, PROCEDURE\FUNCTION выглядят красиво. Профайлер научился показывать план, не исполняя запрос.


pgagroal 0.8.1

В этой версии пулера улучшена работа с системой мониторинга Prometheus: теперь pgagroal указывает серверы, которые отказали, и показывает ошибки на них. Релизы pgagroal выходят часто. В предыдущей в версии 0.8.0 пулер обучился переподключению (failover) и поддержке systemd. В 0.7.0 в конце мая появилось удалённое управление.


pg_dumpbinary 2.2

Новая версия программы Жиля Дароля (Gilles Darold), которая сохраняет дамп в бинарном формате и восстанавливает базу командой pg_restorebinary, приблизилась к поведению самой pg_dump: теперь выгружаются таблицы и последовательности расширений, зарегистрированные функцией pg_extension_config_dump. Подробный чейнджлог релиза здесь. Загрузить можно отсюда.

PostGIS 3.0.2

Вместе с этой вышли и версии 2.5.5, 2.4.9 соответствующих стабильных веток. Работают с PostgreSQL 13 beta2 и ниже вплоть до PostgreSQL 9.5 и с GEOS позже версии 3.6. Исправление ошибок, принципиальных изменений не видно.

pg_probackup 2.4.2

В этой версии утилиты появились пакеты SUSE. Кстати, в разделе Статьи есть план целой серии статей о pg_probackup.

Foreign Data Wrapper for SQLite 1.2.1

Toshiba Software Engineering & Technology Center сообщает о новой версии. Она работает с PostgreSQL 9.6, 10, 11 и 12. Улучшено:
  • добавлен пушдаун Limit/Sort в SQLite;
  • тип SQLite datetime numeric конвертируется в PostgreSQL TimeStamp

FDW поддерживает:
SELECT, INSERT, UPDATE and DELETE на внешних таблицах; транзакции.
Пушдауны:
  • WHERE-предложений;
  • агрегации;
  • ORDER BY;
  • LIMIT и OFFSET (*в случае, когда все таблицы, к которым обращаются, внешние);

Детали есть в репозитории с исходниками.

Статьи


PostgreSQL 14: Часть 1 или июльский разогрев (Коммитфест 2020-07)

Обстоятельная статья, в ней отражены все новые коммиты, а многие из них проиллюстрированы примерами. Причем некоторые относятся к версии 13. Сейчас появились и будут появляться статьи, посвященные отдельным или нескольким новшествам в PostgreSQL 14, но вряд ли появится текст, касающийся стольких коммитов.

На эту же тему, понемножку:
у Хуберта Любашевски (aka depesz) в серии Waiting for PostgreSQL 14:

Пока 3 темы, но продолжение несомненно последует.

Как Lingualeo переехал на PostgreSQL с 23 млн юзеров

Полное название начинается с В карантин нагрузка выросла в 5 раз, но мы были готовы. Статья главного бэкэнд-разработка компании Lingualeo Олега Правдина вызвала интерес слоёв более широких, чем сисадмины PostgreSQL. На момент Postgresso 24 уже 772 комментария при 44К просмотров. Может потому, что в статье много об административных преобразованиях, поиске исполнителей, может из-за того, что при переходе на новую систему сознательно грохнули некоторое количество (примерно 1%) пользовательских данных. Ну и стартовали холивары на темы NoSQL vs классика и логика внутри базы vs логика в приложениях.

Lingualeo это сервис с 23 миллионов пользователей из России, Турции, Испании и стран Латинской Америки, которые учат с его помощью английский, 100 тыс. одновременных пользователей в пике. У пользователей есть свои собственные словари (они и пострадали частично), Джунгли, курсы. Всё это работало на PHP/MySQL. Теперь всю логику перенесли в базу с хранимками на PL/pgSQL.

В статье не густо технических подробностей (обещают целую серию статей в ближайшем будущем), но их можно найти в комментариях под статьёй. Например, вот так там описано новое решение:
  1. фронт дергает ручку Список покупок;
  2. прокси-сервис [на Go, занимается балансировкой запросов к Мастеру и Слйэвам, плюс обеспечивает взаимодействие с внешними сервисами] получает запрос и дергает соответствующую хранимку в базе (в этой точке возможен гибкий роутинг к слэйвам, например);
  3. хранимка формирует ответ в виде json. В ответе есть атрибут с инструкцией для прокси-сервиса: вызови микросервис sms_sending, вот ему json с параметрами;
  4. прокси-сервис выполняет инструкцию;
  5. прокси-сервис отправляет готовый ответ на фронт (п. 4 и 5 могут параллельно выполняться, если независимые).

Нужно:
  1. разработать хранимку (PL/pgSQL) на 50-100 строк;
  2. время разработки и отладки: 1 2 часа;
  3. скорость отклика: 1 2 мсек (если структура данных правильная);

Прокси-сервис отдаёт готовый JSON на фронт.

Коллеги подсказали мне, что, судя по этим сведениям, в Lingualeo на практике применили подход, теоретически обоснованной в таких статьях как Connecting Galaxies: Bridging the Gap Between Databases and Applications (соавтор статьи, которой, увы, нет в бесплатном доступе, Борис Асенович Новиков, автор учебника Основы технологий баз данных) или в более ранней Talking To The Database In A Semantically Rich Way. Суть в том, что несоответствие в моделях данных между объектно-ориентированными приложениями и реляционными СУБД может стать роковым для данных. Чтобы его преодолеть, надо обмениваться не отдельными строками отдельных таблиц, а составными объектами (используя, например, JSON, как транспортный формат).

В статье Lingualeo нет ни слова о полнотекстовом поиске, есть только задача:

Чтобы заработала функция перевода слов по клику, текст надо разделить на слова, выражения и словосочетания. Затем обратиться к словарю и вывести пользователю перевод в новом окошке поверх текста. Бэк передаёт на фронт готовый JSON, в котором текст уже разбит на слова и выражения.

Но в комментарии автор поясняет:

Мы упростили всю систему, исключив rabbit, kafka, elastic search и др. FTS (full-text search) в PG позволяет находить необходимые данные в базе из миллионов документов за 2-3 мсек для наших задач более чем достаточно

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

Надеемся на разъяснения в грядущих статьях.

Знакомство с pg_probackup. Первая часть

Александр Никитин из БАРС Груп написал статью об этой утилите Postgres Professional. В первой части он рассказывает о резервном копировании. Дальше будет о восстановлении. Вообще запланировано рассмотреть прежде всего 4 темы:
  • создание автономных бэкапов на отдельном сервере
  • создание архива WAL-файлов и создание бэкапов в этом режиме
  • развёртывание реплики из бэкапа и настройка создания бэкапов с реплики
  • различные варианты восстановления;


Путеводитель по резервному копированию баз данных

Владимир Комаров aka hard_sign рассматривает резервное копирование во всех основных СУБД (Oracle, DB2, MS SQL, MySQL, а в эпизодах и MongoDB, Cassandra, Percona Server), в том числе и в PostgreSQL, конечно. В главке об инкрементальном резервном копировании несколько абзацев посвящены pg_probackup.

Эта статья часть мощной серии:
Путеводитель по репликации баз данных
Классификация критичности информационных систем
Распределённые СУБД для энтерпрайза.

Из более ранних есть и остросюжетная: Так что же случилось со Сбербанком?

Why PostgreSQL 13 is a Lucky Release

Джонатан Катц (Johnathan S. Katz, Crunchy Data) справедливо считает, что этот релиз не был решающим прорывом с точки зрения наращивания функциональности, но что это хорошая штука для всех каждый найдёт в нем что-нибудь для себя, из-за чего стоит немедленно проапгрейдиться до PostgreSQL 13.

Прежде всего считает он это сокращение размера индексов (дедупликация b-tree). На демонстрационном примерчике выигрыш в три раза по объему и в два раза по производительности. Далее: вакуум работает побыстрее за счет того, что индексы, опять же, во время чистки таблицы обрабатываются параллельно, при этом число параллельных процессов настраивается. Еще Джонатан отмечает как особо важную фичу инкрементальную сортировку. Напоминаем, что в нашей статье о PostgreSQL 13 эти пункты рассмотрены немного подробней (кстати, выигрыш в объеме индекса у нас тоже в 3 раза), но пунктов там гораздо больше, что преимущество и недостаток одновременно в зависимости от цели читателя.

Avoiding the Pitfalls of BRIN Indexes in Postgres

Джон Порвазник (John Porvaznik, Crunchy Data) для своих примеров генерит табличку с рандомными данными, затем рассматривает структуру индекса BRIN (Block Range INdex), используя расширение pageinspect. На вопрос, заданный себе когда стоит использовать BRIN?, автор отвечает предложением когда таблица large insert-only in-order и дальше останавливается на влиянии каждого звена этой конструкции. Индекс нежный, деликатный. Неожиданное отклонение в каждом из этих звеньев может свести на нет все прелести BRIN, поэтому перед запуском в прод стоит хорошенько промоделировать проект.

How we used Postgres extended statistics to achieve a 3000x speedup

Статья на сайте компании Affinity, известной больше как разработчик инструментов дизайна, рассказывает о том, как их инженеры решили проблему с долгим откликом на их сайте. Проблема была в том, что оптимизатор радикально промазал с оценкой кардинальности ждал одну запись там, где их тысячи. Автор Джереж Ралисон (Jared Rulison) коротко и внятно объясняет важность корреляций при сборе статистики, какие неприятные сюрпризы учёт корреляций может подложить, как оптимизатор может выбрать совсем не оптимальный тип джойна (что и случилось nested loop вместо hash join). Чтобы вразумить оптимизатор надо проделать некоторые дополнительные действия при сборе статистики.

Оценка кардинальности действительно одна из нетривиальных задач. В прошлом выпуске мы упомянули статью нашего коллеги Павла Толмачёва из отдела образования Postgres Professional: AQO адаптивная оптимизация запросов в PostgreSQL. Там рассказывается об об интеллектуальном (с ИИ) модуле (расширении) aqo, который во многих случаях помогает оптимизатору, удачно угадывая кардинальность.

A Crash Course on PostgreSQL for R Users

Союз R и PostgreSQL нечастая тема. В нехитрой статье и примерах используется демонстрационная база Полётов Нью-Йоркских аэропортов (во flights14 > 12 млн записей). Попробуйте демобазу наших аэропортов она побогаче семантически. Расширение plr Джо Конвея (Joe Conway), позволяющее хранить и исполнять пользовательские R-функции в базе, не используется. Автор обходится обычными соединениями при помощи RPostgres. Используется библиотеки Tidyverse, dplyr и другие. Есть полезные ссылки.

Building a recommendation engine inside Postgres with Python and Pandas

Крейг Кирстинс (Craig Kirstiens) из Crunchy Data решил построить движок рекомендательного сервиса прямо внутри PostgreSQL, то есть используя хранимые функции на plpython3u.
Он взял простенький пример движка на Python с демоданными, загрузил данные в Postgres. Там, где в Python был тип DataFrame, Крейг использует массивы Postgres.


Data systems that learn to be better

Эдам Коннер-Саймонс (Adam Conner-Simons) из Computer Science and Artificial Intelligence Laboratory (CSAIL, лаборатория внутри MIT) пишет о проектах со зловещими именами: Цунами (Tsunami) и Bao (BAndit Optimizer).

Цунами основан на теоретической статье The Case for Learned Index Structures (по ссылке только аннотация), написанной в 2017-м профессором MIT Тимом Краска (Tim Kraska) с соавторами и соратниками из Google. Статья тогда наделала шуму в Postgres-сообществе. Там говорилось: идея в том, что модель может выучить порядок сортировки или структуру словарных ключей (structure of lookup keys) и, исходя из этой информации, определять оптимальную позицию записи в индексе или вообще ее необходимость.

Приближается революция? спрашивал Николай Самохвалов. Мало кто верил, что обучающиеся индексы действительно заменят B-деревья, хэш-индексы и Bloom-фильтры. В качестве трезвого взгляда Олег Бартунов, например, приводил исследование, где ИИ работал не лучше интерполяции сплайнами:
The Case for B-Tree Index Structures Томаса Ноймана (Thomas Neumann). Никто из разработчиков PostgreSQL, во всяком случае, не реализовал работоспособные обучающиеся индексы.

Краска, однако, представил проект Tsunami в стенах CSAIL. Он утверждает, что на тестах удаётся достичь выигрыша в скорости исполнения запросов на порядок, а данные можно организовать в наборы обученных индексов, сократив суммарный объем на два порядка (примерно как он и предсказывал в той статье).

Кроме того, с коллективном другого состава под руководством Райана Маркуса (Ryan Marcus) он участвует в проекте Boa (аннотация), где, как утверждается, оптимизатор, полностью интегрированный в PostgreSQL, учится меньше часа на собственных ошибках, после чего составляет план так, что бьёт по производительности опенсорсные и коммерческие СУБД.

А цель CSAIL объединить эти два проекта в один, который будет работать в существующих облачных инфраструктурах, таких как амазоновский Redshift. Скептики не ведутся: любопытно, но я что-то не знаю ни одного, кто бы над этим работал пишет Брюс Момджан (Bruce Momjian). Но Дмитрий Долгов видел сообщения, что о планах реализовать Bao как опенсорсный проект, хотя никакого взаимодействия с Postgres-сообществом пока не замечено.

Образование


Вышла новая английская версия Малютки PostgreSQL: The First Experience

В этом издании примеры на PostgreSQL 12. Загрузить PDF можно бесплатно отсюда. А русская версия здесь.

Облака


Postgres Pro на Azure, mail.ru и Яндексе

Виртуальные машины, с вышедшими в конце августа новыми минорными версиями Postgres Pro, появились в облаке Microsoft Azure. Там есть виртуальные машины Postgres Pro Enterprise и Postgres Pro Standard версий 9.6.19.1, 10.14.1, 11.9.1 и 12.4.1 (виртуальные машины Postgres Pro Enterprise версий 10.14.1, 11.9.1 и 12.4.1 в двух вариантах с ОС Centos и ОС Ubuntu).

Кроме этого, Postgres Pro Standard версий 11 и 12 предлагается в облаке Microsoft Azure в виде образов Docker-контейнеров и в составе виртуальной машины, и в виде самостоятельного контейнера. Немало: 13 приложений на фоне примерно 60, имеющих отношение к Postgres. В том числе их собственных решений, например PostgreSQL Hosting: Fully Managed DBaaS on Azure.

В Яндекс.Облаке стали доступны виртуальные машины с Postgres Pro Enterprise 11.9.1 и 12.4.1. В их составе pg_probackup, CFS, multimaster и прочие Enterprise-возможности, а также установленные и настроенные сервер Zabbix и агент mamonsu. Руководство по созданию и использованию Postgres Pro Enterprise в Яндекс.Облако здесь. Незадолго до этого Postgres Pro в виде DBaaS появилась в облаке Mail.Ru Cloud Solutions пока только с Postgres Pro Standard 11.

У Яндекса есть и своя PostgreSQL Yandex Managed Service for PostgreSQL (кластеры с версиями 10, 11 и 12, а также PostgreSQL 10 для 1C. О производительности 1С в Яндекс.Облаке есть ролик в разделе Вебинары). . Есть довольно внушительный список расширений. Вообще, сравнивать облачные предложения занятие полезное и интересное, но не для этого новостного обзора слишком много вариантов. Плюс облачники обычно не стремятся сразу выставить на общее обозрение адекватную для сравнения техническую информацию.

Announcing pgBackRest for Azure: Fast, Reliable Postgres Backups

Крейг Керстинс (Craig Kerstiens) рассказывает о pgBackRest, который теперь может работать в облаках Azure.

DB-Engines Ranking Trend Popularity

Это рейтинг облачных СУБД по некоторому набору критериев. PostgreSQL примостился за Oracle, MySQL и Microsoft SQL Server. Но если глянуть кривые популярности, то видно, что эти трое стоят на месте (и даже чуть заваливаются), а наш красавец упрямо карабкается вверх (но MongoDB цепляется за пятки).

Вебинары и митапы


#RuPostgre

Ровно в начале учебного года 1 сентября Николай Самохвалов с Ильей Космодемянским начали с Интро новый сезон RuPostgres-вторников. В ближайших стримах главный фокус будет на разработческих темах: великий и ужасный SQL, сложные запросы, JSON, оптимизация производительности, отладка, ORM, GraphQL и т.д. и т.п. Но и админские темы постараются не забывать. Документ с инфо, куда можно вписывать пожелания, здесь.

Вебинар 1С на Postgres в облаке

Yandex.Cloud выложили ролик (около 30 мин, начинается почему-то на 9:35): Марат Мустафин, руководитель Центра разработки компании мудрых советов WiseAdvice (основной партнер Yandex.Cloud по 1С) рассказывает о нагрузочном тестировании (22:00), о требованиях к оборудованию, настройках PostgreSQL (в том числе отключение синхронного коммита) на сетевых и локальных SSD, влияющих на производительность, зависимости выбранного размера дисков на скорость работы, надежность и масштабируемость приложений.

Разворачивалось всё и тестировалось на кластере под Windows в яндексовском Managed Service for PostgreSQL, куда входит и их пулер Odyssey. Версия PostgreSQL 10-я (ведутся работы по переходу на 11-ю). Тесты: 1C:ERP тест-центр и синтетический Тест Гилёва. Тестирование вызывает много вопросов. Про Тест Гилёва Марат так и говорит: результаты слишком неоднозначные, и вообще это лишь начало всестороннего тестирования.

Вебинары 2ndQuadrant

JSON & ARRAY Contemporary PostgreSQL Data Types

Состоялся 2-го сентября. Ведущий Борис нет, не знаю, как произнести его фамилию: Boriss Mejas.

New Features in PostgreSQL 13

Ожидается 16-го сентября, в 19:00. рассказывать будет Питер Айзентраут (Peter Eisentraut)

Конференции


pgDay Israel 2020

Должен состояться уже 10-го сентября в Тель-Авиве.



Предыдущие выпуски:
#23, #22, #21, #20, #19, #18, #17, #16, #15, #14, #13, #12, #11 (спец), #10, #9, #8, #7, #6, #5, #4, #3, #2, #1
Подробнее..

Postgresso 25

09.10.2020 14:15:38 | Автор: admin


Жизнь продолжается. А мы продолжаем знакомить вас с самыми интересными новостями PostgreSQL.


Главное событие


EDB Completes Acquisition of 2ndQuadrant

EDB поглотила 2ndQuadrant. Теперь всё будет под брендом EDB. Руководить будет CEO EDB Эд Бойджан (Ed Boyajian), а великий и ужасный Саймон Риггс (Simon Riggs) из 2ndQuadrant получит титул PostgreSQL Fellow и будет PG-евангелистом и техническим стратегом.

Не будем считать деньги, а напомним о вкладе в сообщество от обеих уважаемых, почтенных компаний (EDB основана в 2004-м, 2ndQuadrant в 2001-м).
Если считать по участникам основных разработчиков PostgreSQL (core team), то счет 2:1 в пользу EDB: Bruce Momjian и Dave Page (PgAdmin) от EDB, против Peter Eisentraut от 2nd Quadrant. Брюс Момджан напомнил о неписанном правиле сообщества: в core team не должно быть больше половины разработчиков из одной компании. А в новом EDB 3 из 5.

Если считать по главным контрибуторам (major contributors) в код PostgreSQL, то маятник качнулся в другую сторону: 5: 3 в пользу 2ndQuadrant Andrew Dunstan, lvaro Herrera,
Petr Jelinek, Simon Riggs, Tomas Vondra против Devrim Gndz, Robert Haas, Amit Langote.
Но у 2ndQuadrant есть ещё и один Заслуженный хакер (hackers emeritus) Marc G. Fournier.

И ещё: Эд Байджан в своей статье на сайте 2ndQuadrant ссылается на COVID-19 как на силу, направляющую пользователей в сторону PostgreSQL, о чём говорится даже в некотором специальном исследовании.

Покупку уже успели обсудить на Postgres-вторниках Николая Самохвалова и Ильи Космодемьянского. Брюс Момджан оценил событие так: в целом положительно, но риски есть. Кроме изменений в core team ещё и минусы консолидации (меньше выбор, слабее конкуренция) и риск того, что процесс пойдёт и дальше: больше шанс, что какая-нибудь крупная компания может захотеть поглотить EDB.

PostgreSQL 13

Это произошло! Почти сразу после релиза-кандидата вышел и официальный релиз.

О том, что в нём будет, писали уже много, и мы здесь процитируем список новшеств вместе с соответствующими им статьями, который составили Postgres Weekly:

Там же, на Crunchy, есть и статья Грега Смита (Greg Smith) PostgreSQL 13 Upgrade and Performance Check on Ubuntu/Debian: 1.6GB/s random reads. Статья этого уважаемого автора собрала, однако, некоторые ложки дёгтя претензии к методу оценки производительности. В конце статьи мы видим медовый вывод: PostgreSQL 13 на Ubuntu совершенно прекрасен! Я проверил!

О релизе почитать здесь, загрузить отсюда, информация для бета-тестеров здесь.


Статьи


PostgreSQL, a community project

Питер Айзентраут (Peter Eisentraut, 2ndQuadrant то есть уже EDB) пишет внезапно не техническую статью, а предлагает мини-анализ Postgres Success Story он заметил, что после выхода 13-й версии, в блогах и на форумах больше говорили не о версии, а не могли нарадоваться устойчивости сообщества. Причина устойчивости по Айзентрауту такая: из 3 типов опенсорсных проектов
  • ведомых одним человеком (или двумя не многими);
  • ведомых компанией;
  • ведомых сообществом

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

Waiting for PostgreSQL 14 Support for OUT parameters in procedures

Депеш (Hubert 'depesz' Lubaczewski) пишет: Это большое дело! Процедуры появились в PostgreSQL 11 и они смогли реализовать логику базы, когда несколько транзакций в одной процедуре. Но вернуть данные они не могли, сделать SELECT по результатам было нельзя, разве что через RAISE NOTICE. А теперь можно. И демонстрирует на примерах.

До этого в серии ожиданий PostgreSQL 14:

Rename wal_keep_segments to wal_keep_size.

pg_stat_statements: track number of rows processed by some utility commands.

Improvements for handling large number of connections.

Ну и напоминаем ещё раз об Июльском разогреве Павла Лузанова.


Postgres и ИИ


Мы сделали микрообзор некоторых статей на эту модную тему. Такие статьи делятся на две категории: ИИ для оптимизации самого Postgres (в том числе ИИ как подсказчика оптимизатору) с одной стороны, и Postgres как инструмент хранения и работы с данными для машинного обучения (чаще хранения, чем работы) с другой.

На статью об ИИ-оптимизации мы недавно ссылались, сделаем это ещё раз: AQO адаптивная оптимизация запросов в PostgreSQL, автор Павел Толмачёв. Теперь об обработке и хранении данных ИИ.

Changing the Rules on MDM: Data Mastering at Scale [М.Стоунбрейкер]

Отец Postgres Майкл Стоунбрейкер выступил на DataMasters Summit конференции Tamr, что не удивительно: он со-основатель этой компании и её технический директор. Пока можно почитать статью Data Mastering at Scale, по мотивам которой, видимо, и сам доклад.

Он говорит о том, что за ETL (Extract, transform and load, извлечение, преобразование, загрузка) следует собственно Data Mastering (управление мастер-данными), где в данных, скажем, есть несколько Стоунбрейкеров (Майк, Майкл, М.), и надо понять, где настоящий Майкл Стоунбрейкер и оставить его единственную, золотую копию. Раньше соответствующий софт с этими задачами худо-бедно справлялся, но последние годы вместо нескольких источников данных может понадобиться 10 тыс. источников (как у Groupon), 250 баз на 40 языках (Toyota). И в этом случае считает не стареющий душой Майкл Стоунбрейкер на базе правил мастеринг
работать уже не будет, а нужно машинное обучение. Без человека всё равно не обойтись, но стюарты данных будут скорее спецами по выбору ML-моделей, по обучению их. И в заключение ссылается на концептуальную статью The Data Civilizer System, где описана MDM будущего.

Postgres and the Artificial Intelligence Landscape

Это PDF-презентация Брюса Момджана. Он говорит не об ИИ для оптимизации работы базы, а о собственно вычислениях машинного обучения, производимыми над данными, хранящимися в БД. Он приводит код на PL/Perl. То есть все ML-вычисления происходят именно внутри базы (гораздо чаще базу используют только для хранения, а вычисления выносят в приложения на Python или других языках). Вот почему Брюс предлагает использовать базу, и использовать её таким образом:
  • для машинного обучения нужно много данных;
  • бОльшая часть этих данных в вашей базе;
  • почему бы не обучать там, где лежат данные, в базе?
  • ведь возможен бесшовный доступ к актуальным данным;
  • можно сразу что-то делать с результатами работы ИИ (например, коммитить транзакции, если ИИ не считает банковскую операцию мошеннической);
  • ИИ выиграет от возможности транзакций, согласованности, бэкапа;
  • можно использовать сложные типы данных, FTS, GIS, индексирование;
  • Postgres может использовать GPU внутри базы.

Machine Learning with 2UDA

Серия из 7 статей о применении софта 2ndQuadrant 2UDA для машинного обучения. Он работает в среде Orange 3, то есть ориентирован на Python. То есть не внутри базы, используя не функции PL/Python(3)u, а внешние программы. Там есть, например, реализация K-NN тоже внешняя, хотя внутри штатного PostgreSQL есть конструкция GOUP BY "<->" LIMIT K, ускоряющая поиск (см. в этом выпуске статью Рамси о PgRouting и PostGIS)

Machine Learning in PostgreSQL part 1: KMeans Clustering

Герман Резницкий (Hernan Resnizky, Cybertec) рассказывал пару лет назад о KMeans (метод K-средних), реализованных внутри базы на PL/Python(3), расширение plpython(3)u. Модели грузятся как тип bytea. А предсказание K-среднего требует передачи в созданную питоновскую функцию массива массивов:
SELECT predict_kmeans('models','model',1,array[[0.5,0.5,0.5,0.5]]);

Данные брали из ML-репозитрия UCI Калифорнийского Университета в Ирвайне.


Postgres и ускорители


Мы решили в этом выпуске в двух словах рассказать о том, что нового делается в мире кремния о GPU, DPU, Arm-CPU.

Oracle Cloud Deepens HPC Embrace with Launch of A100 Instances, Plans for Arm, More

Эти новости не имеют прямого отношения к Postgres, но тенденции любопытные. У Oracle в облаках есть и база Oracle, и MySQL. Системы DGX A100 Nvidia, конечно, придут в облака прежде всего для ИИ, генерации речи, работы с мультимедиа. Но не только: DGX упоминают и в контексте баз данных: у DGX-1 более 1ТБ памяти, но мы её ещё удвоили. Не потому, что могли. А потому, что многие из наших клиентов обрабатывают огромные графы и должны быстро работать с экстремально большими базами данных, столько памяти им действительно нужно! Об этом же по-русски выжимка той статьи: Oracle Cloud расширяет портфель HPC-решений

DPU

Колумбийский университет ведёт исследовательский проект исследование архитектуры специализированных DPU-процессоров (Data Processing Unit) для повышения производительности и экономии энергии при обработке данных больших объемов. Эта исследовательская группа фокусируется на ускорении запросов к РСУБД. Первая разработанная ими архитектура нацелена на ускорение аналитических запросов к большим наборам данных.

А вообще архитекторы DPU мыслят их как часть триады CPU-GPU-DPU (в том числе и в Nvidia, разумеется.

Arms First 64-bit Cortex-R Chip Adds Computational Storage

Arm представила публике свой первый 64-битный процессор реального времени для хранения данных на уровне корпораций. В нём зашита поддержка микросервисов Linux. Он должен воплотить идею вычисления должны быть поближе к данным. Память в нём устроена так, что ОС может работать прямо в контроллере хранения данных. Процессор может адресоваться к памяти в 1ТБ DRAM. Предполагается, что он будет эффективно работать в том числе с Kubenetes и Docker.

Data processing more than billion rows per second [с GPU]

Кохей Кайгай (Kohei KaiGai, глава компании HeteroDB) повествует на вебинаре (видео пока недоступно) о том, как SSD-to-GPU Direct SQL (реализованный как расширение PostgreSQL) оптимизирует поток данных, несущийся по шине PCIe от хранения к процессорам. Цель ускорение аналитических запросов.


PostGIS


Using Postgres and pgRouting To Explore The Smooth Waves of Yacht Rock
Ещё один неожиданный поворот. Не потому, что речь в этой статье Джона Порвазника (John Porvaznik, Crunchy Data) не о яхтах и камнях, а о музыке для яхт (что-то вроде софт-рока, Beech Boys, видимо), а потому, что рассказывается о расширении pgRouting, которое требует установки PostGIS, и используется обычно для маршрутизации в самом буквальном смысле прокладывании маршрутов на карте. Но с его помощью можно и обходить графы (не используя функции PostGIS вообще). Автор строит замысловатый граф из данных о песнях и их исполнителях и натравливает на него алгоритм Краскала. Графы в статье очень красивы. Результат: лучший музыкант для яхтинга Джеф Паркаро (я не слушал: нет яхты).

Зато Пол Рамси (Paul Rumsey) занимается в майской статье Routing with PostgreSQL and Crunchy Spatial прокладыванием маршрутов по улицам Бостона. Но использует ещё и pg_tileserv и pg_featureserv гошные компоненты их пакета Crunchy Spatial. Кстати, пользуется и "<->" в конструкции ORDER BY, которая радикально ускоряет поиск ближайших соседей.

Для визуализации Рамси использует OpenLayers, а не QGIS, как многие сейчас. Геоданные берёт с Geofabrik.

Spatial analysis with PL/R

Серия из трёх статей ещё 2007 года, зато написанная автором расширения plr Джо Конвеем (Joe Conway, Crunchy Data). Он предлагает использовать R внутри базы во взаимодействии с функциями PostGIS. R пригодится для аналитики пространственных данных. Для примера он строит графики NDVI (Normalized Difference Vegetation Index вегитационный индекс) окрестностей Сан-Диего. R при этом работает с растровыми, а не векторными данными. Берёт их у United States Geologic Survey (USGS), а результаты визуализирует с помощью старинной R-библиотеки получается вполне симпатично.

Иван Муратов о PostgreSQL + PostGIS + TimescaleDB на SDCast #123

PostgreSQL + PostGIS + TimescaleDB хранилище для систем мониторинга транспорта доклад Ивана на PGConf.Russia 2019 (слайды и видео).

PostGIS vs. Geocoder in Rails

Лей Холлидей (Leigh Halliday), автор-гость в блоге pganalyze, разрабатывал приложения на Ruby on Rails и обходился без PostGIS, пользуясь Geocoder. Но овладел всё же PostGIS и теперь сравнивает. В примерах кода на Ruby используется сгенерённая демобаза со 100 тыс. домов и 100 школ. Лей по касательной задевает понятия SRID и измерения расстояний на сфере (о сфероиде речь не идёт), индексирования геоданных в Rails и в PostGIS. С задачей нахождения домов не дальше заданного расстояния от школы и с домами внутри прямоугольника рельсы и PostGIS справляются за примерно одно время. Но только PostGIS подходит для поиска домов внутри заданного многоугольника и в случае, когда добавляется условие на дом: только те, где можно арендовать квартиру недалеко от школы.


Облака


Announcing Crunchy Bridge: A modern Postgres as a service

Crunchy Bridge теперь доступен на AWS и Azure.

AWS Aurora PostgreSQL versions vanish from the mega-cloud for days, leaving customers in the dark

То был позитив. А вот негатив: Грег Клоу (Greg Clough), разработчик, использующий AWS, обнаружил, что некоторые версии AWS Aurora исчезали на прошлой неделе (то есть стали недоступны для разворачивания; уже существующие базы не пропали). Сейчас всё в порядке.

Diary of an Engineer: Delivering 45x faster percentiles using Postgres, Citus, & t-digest

Нильс Дийк (Nils Dijk, Microsoft) рассказывает, как проблема заказчика на analytics data in Hyperscale (Citus) on our Azure Database for PostgreSQL managed service была решена с помощью расширения t-digest Томаша Вондры.

Cloud Vendors as a Barrier

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

Через 3 дня Брюс продолжает тему в посте Cloud Vendor Monetization of Open Source. Тема пересекается с темой статьи Питера Айзентраута. Брюс акцентирует разницу между открыто разрабатываемым открытым кодом (как Postgres) и кодом открытым, но разрабатываемым в компании (как MySQL). Но ссылается он на другую статью: Dining Preferences of the Cloud and Open Source: Who Eats Who?. Там есть симпатичный фрагмент о софтовой пищевой цепочке:
ПО ест мир; открытый код ест ПО, облака едят открытый код, и самое актуальное мульти-облака едят облака. Через эту оптику в статье рассматриваются AWS, Hadoop, Pivotal, Red hat. Особенно нагляден, считает Брюс, пример Red Hat, оказавшейся в результате внутри IBM; но облачники могли бы для своего же блага умерить аппетиты и не съедать, а пасти (немного вольно интерпретируя Брюса) опенсорсные компании как дойных коров.


Миграция, апгрейд, интеграция


How we upgraded PostgreSQL at GitLab.com

Речь о масштабном проекте, в котором используются мощные машины с 96 ядер и 624 Гб памяти. 60К пользовательских коннектов к сайту в сек. держит каскад pgbouncer-ов. Приложения написаны на Ruby on Rails.

Using PostgreSQL to Offload Real-Time Reporting and Analytics from MongoDB

Неожиданный поворот: PostgreSQL предлагают использовать как базу с запросами для чтения как аналитическую. При этом база на MongoDB остаётся для пишущих OLTP-запросов. Данные постоянно копируются из MongoDB в Postgres средствами монговского oplog. Обосновывают такое решение тем, что сложные запросы с агрегацией, с многочисленными индексами и разнообразными джойнами в Postgres сочетаются с развитыми средствами работы с JSON.

Статья лежит на сайте Rockset, и в конце статьи говорится: если уж вы решили выгрузить аналитику и отчёты из MongoDB, но вам нужно серьёзное масштабирование, а данные слабо структурированы, то стоит подумать насчет бессхемных баз реального времени Elasticsearch и Rockset. Они умеют ускорять запросы индексами, а Rockset поддерживает полноценный SQL и умеет делать джойны.


Разное


Морской бой на PostgreSQL

Статья Владимира Турова aka Firemoon. Подробней не на Хабре, а здесь.

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

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

Планировщик, вообще-то, есть: pgpro_schedeler в Postgres Pro Enterprise. Код самого боя лежит в репозитории.

Знакомство с pg_probackup. Вторая часть

Александр Никитин из БАРС Груп опубликовал продолжение. В первой части установили pg_probackup, создали и настроили экземпляр, сняли полный и инкрементный бэкапы, научились просматривать и изменять конфигурацию экземпляра. Получили список бэкапов, написали скрипт для резервного копирования кластера и отправки результатов последней операции по снятию бэкапа в систему мониторинга.

Темы второй части:
PITR как хранить копии журналов предварительной записи, чтобы иметь возможность восстановления на произвольный момент времени (Point-in-time recovery); рассматриваются режимы DELTA, PAGE и самый интересный PTRACK, когда создается карты измененных блоков в базе данных.

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

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


Вебинары и митапы


Вебинар по JSONB Олега Бартунова



17-го сентября в новой студии Postgres Professional Олег Бартунов провёл вебинар Roadmap for JSON in PostgreSQL: What's Next? Вебинар был ориентирован на англоязычную аудиторию. Примерно треть эфирного времени пришлась на вопросы и ответы. Вопросов было очень много. Видео будет выложено позже.

Postgres-вторники

Теперь они будут не каждый вторник, а через один. Зато дополнятся англоязычными Postgres-Thursdays. Обещано, что в четвергах поучаствуют весьма известные персоны.
На YouTube;
в Zoom (ссылка теперь каждый раз новая);
планы, детали.


Релизы


dbForge: Data Compare for PostgreSQL v.3.3 и Schema Compare for PostgreSQL, v1.0

У Devart, известной dbForge Studio for PostgreSQL и Data Compare for PostgreSQL, появился новый продукт: Schema Compare for PostgreSQL v1.0. Пока он ориентирован больше на Amazon Redshift, умеет сравнивать схему PostgreSQL со схемой Redshift и помогает переезжать с первой СУБД на вторую (подробней здесь). В блоге Devart большое количество скриншотов, и сказано, что PostgreSQL, Amazon RDS, Azure PostgreSQL поддерживаются частично. Но обещано развитие в направлении PostgreSQL.

Параллельно вышел релиз новой версии dbForge Data Compare for PostgreSQL v.3.3 с поддержкой PostgreSQL 13 и с управлением скриптами предварительного и последующего выполнения (Pre & Post Script execution functionality).

pgtools

Этот инструмент дебагинга приложений, работающих с базами данных, в реальном времени показывает события базы данных, вызванные работой приложения. pgtools использует для перехвата событий базы триггеры и триггерные функции. Серверная часть написана на Python3, клиентская на vue.js. Пока находится ещё в стадии разработки, поэтому автору Лукасу Лёффлеру (Lukas Loeffler) нужна и важна реакция, советы и найденные ошибки.

PostgresDAC 3.9

PostgresDAC это набор компонентов для доступа из RAD Studio (Delphi и C++Builder)/FreePascal/Lazarus к разным Postgres-ам: PostgreSQL, EnterpriseDB, Amazon RDS, PostgresPro, и Heroku Postgres.

Главное в этой версии поддержка PostgreSQL 13 и RAD Studio 10.4.1: добавлены клиентские библиотеки v13 и библиотеки dump & restore v13 (pg_dump.dll, pg_restore.dll).

Загружать отсюда.

Pgpool-II 4.1.4

А точнее: 4.1.4, 4.0.11, 3.7.16, 3.6.23 и 3.5.27. О релизе можно почитать здесь, а скачать отсюда.

pg_probackup 2.4.4

Новое: появились пакеты для SUSE 15.2 и поддержка PostgreSQL 13. Если пропустили, то напоминаем, что в подразделе Разное раздела Статьи есть о второй части статьи из серии об этом пакете.


Конференции


HighLoad++

Должна состояться 9 и 10 ноября 2020 в Офлайн Сколково.
Конференция HighLoad++ НЕ будет перенесена в онлайн. В случае, если регулирующие органы не разрешат проводить конференцию 9 и 10 ноября, она будет перенесена со всеми обязательствами и партнёрствами на 1 и 2 марта 2021 года. Для тех, кто воспользуется бронью организаторов в гостинице в Сколково, бронь будет перенесена автоматически.




Предыдущие выпуски:
#24, #23, #22, #21, #20, #19, #18, #17, #16, #15, #14, #13, #12, #11 (спец), #10, #9, #8, #7, #6, #5, #4, #3, #2, #1
Подробнее..

PostgreSQL 14 Часть 2 или в тени тринадцатой (Коммитфест 2020-09)

16.10.2020 12:13:24 | Автор: admin
Главным событием сентября в мире PostgreSQL безусловно является выход 13 версии. Однако жизненный цикл PostgreSQL 14 идет своим чередом и в сентябре прошел второй коммитфест изменений. О том, что интересного было в первом рассказывалось в предыдущей статье. А прочитав эту можно узнать почему 5! больше не выдаст 120, разобраться что общего у хирурга и DBA, выяснить сколько же записей в пустой таблице и многое другое.

Клиентские приложения


psql: \d показывает метод доступа в расширенном списке объектов
commit: 07f386e

Вывод команды \d[tmi]+ пополнился новым столбцом Access Method. Но новых методов доступа для таблиц пока не реализовано. Поэтому для таблиц и материализованных представлений значение столбца всегда будет heap. Однако мы ждем появления и других значений, в частности очень интересна недавняя инициатива компании Cybertec по продвижению zheap.

А пока команда \di+ может показывать полезную информацию об индексных методах доступа (при наличии индексов отличных от btree).

psql: \d показывает измененное целевое значение расширенной статистики
commit: 3c99230

Возможность изменить целевое значение расширенной статистики добавили в 13 версию еще в сентябре прошлого года. А сейчас, за пару недель до выхода релиза, научили команду \d показывать измененное значение.

Автодополнение по табуляции в psql улучшено для команд: COPY и \copy; IMPORT FOREIGN SCHEMA; VACUUM; REINDEX; DEALLOCATE.

pg_dump: оптимизация работы в режиме --data-only
commit: 5423853

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

Проверка значений параметров pg_test_fsync --secs-per-test и pg_test_timing --duration
commit: 4d29e6d

Утилиты сервера pg_test_fsync и pg_test_timing сложно отнести к часто используемым. Возможно поэтому никто не замечал, что их можно запустить с некорректными значениями параметров --secs-per-test и --duration соответственно. Микаэль Пакье исправил это.

Документация


Не только сборка из исходных кодов
commit: d2511d71

В главе Server Setup and Operation появились уточнения о пакетных сборках. Не особенности конкретных сборок, а то, что в пакетных сборках основные операции с сервером(инициализация, запуск, останов) могут выполняться иначе, чем при сборке из исходников.

Портировано в 13 версию.

Шаблон нового процедурного языка
commit: adbe62d0, 51300b45

В документации по 13 версии в главе Writing a Procedural Language Handler раздела Internals описан пример кода на C для создания нового процедурного языка. Для большего удобства, шаблон для создания процедурного языка (PL/Sample) поместили в исходный код, а именно в каталог src/test/modules/plsampe. Здесь есть всё для правильного оформления нового языка: управляющий и sql файлы расширения, файл на C с основной процедурой обработчика языка, инфраструктура тестирования.

Мониторинг и управление


Amcheck: соседние индексные страницы одного уровня в B-дереве корректно ссылаются друг на друга
commit: 39132b78

Добавлена проверка, что соседние страницы одного уровня в B-дереве корректно ссылаются друг на друга. Для надежности проверки в буферном кеше блокируются сразу обе страницы. Это позволяет не пропустить проблему, когда одна из страниц изменяется во время проверки.

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

Упоминание об этой проблеме есть в майском выступлении Андрея Бородина Что и зачем мы делаем в Open Source базах данных, правда тогда еще не было известно, что в августе его патч будет принят.

Включение в log_line_prefix значения pg_stat_activity.leader_pid
commit: b8fdee7d

В 13 версии в pg_stat_activity добавили столбец leader_pid номер ведущего процесса при выполнении параллельных запросов. А в 14 версии номер ведущего процесса можно включить в log_line_prefix при помощи спецсимвола %P.

Представление pg_backend_memory_contexts
commit: 3e98c0ba

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

EXPLAIN (BUFFERS) без ANALYZE
commit: 9d701e62

Команду EXPLAIN можно выполнить с опцией BUFFERS и без ANALYZE. Следующий запрос показывает сколько буферов было прочитано для построения плана:

EXPLAIN (BUFFERS) SELECT * FROM bookings;
                           QUERY PLAN                            ----------------------------------------------------------------- Seq Scan on bookings  (cost=0.00..4301.88 rows=262788 width=21) Planning:   Buffers: shared hit=11 read=2

Такое поведение немного необычно. Ведь EXPLAIN без ANALYZE всегда выдавал только оценку стоимости будущего плана. А теперь появился вариант запуска, когда мы получаем фактические затраты (в виде количества буферов) на построение плана.

Включено в 13 версию.

Производительность


Повышение масштабируемости клиентских соединений: GetSnapshotData()
commit: dc7420c2, 1f51c17c, 941697c3, 5788e258, 73487a60, 623a9ba7

Андрес Фройнд, после перехода в Микрософт, серьезно занялся вопросами масштабируемости клиентских соединений. В недавней статье Андрес очень подробно рассказал об исследовании причин замедления работы PostgreSQL при увеличении количества подключений и выявил, что основная проблема кроется в функции GetSnapshotData().

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

Для решения этих проблем Андрес в начале марта предложил набор из 12 патчей (см. первое письмо в переписке), в которых предлагается для оптимизации работы функции существенно переработать внутренние структуры памяти и алгоритмы.

После полугодового обсуждения, в августе пошли первые коммиты. Список наиболее важных здесь приведен. В вышеупомянутой статье Андрес сообщает, что скоро в следующей расскажет о достигнутых результатах. Но уже сейчас понятно, что это одно из самых масштабных(масло масляное?) изменений в рамках 14 версии.

Ускорение умножения очень больших чисел типа numeric
commit: 88709176

В эпоху больших данных и числа должны быть большими. И выполнять операции с большими числами нужно быстро. Именно такая оптимизация умножения чисел типа numeric реализована в данном изменении.

Инкрементальная сортировка для оконных функций
commit: 62e221e1c

Инкрементальная сортировка появилась в 13 версии. Теперь этот же механизм используется и для запросов с оконными функциями.

Немного модифицируем пример из предыдущей ссылки:

EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF) SELECT ticket_no, MAX(passenger_name) OVER (ORDER BY ticket_no, passenger_id) FROM tickets;
                                            QUERY PLAN                                            -------------------------------------------------------------------------------------------------- WindowAgg (actual rows=366733 loops=1)   ->  Incremental Sort (actual rows=366733 loops=1)         Sort Key: ticket_no, passenger_id         Presorted Key: ticket_no         Full-sort Groups: 11461  Sort Method: quicksort  Average Memory: 27kB  Peak Memory: 27kB         ->  Index Scan using tickets_pkey on tickets (actual rows=366733 loops=1) Planning Time: 0.118 ms Execution Time: 313.352 ms

C отключенной инкрементальной сортировкой запрос выполняется существенно дольше:

SET enable_incremental_sort = OFF;EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)SELECT ticket_no, MAX(passenger_name) OVER (ORDER BY ticket_no, passenger_id) FROM tickets;
                          QUERY PLAN                          -------------------------------------------------------------- WindowAgg (actual rows=366733 loops=1)   ->  Sort (actual rows=366733 loops=1)         Sort Key: ticket_no, passenger_id         Sort Method: external merge  Disk: 18744kB         ->  Seq Scan on tickets (actual rows=366733 loops=1) Planning Time: 0.113 ms Execution Time: 1257.468 ms

Синхронизация статистики SLRU выполняется процессом контрольной точки
commit: dee663f7

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

Ускорение функции compactify_tuples
commit: 19c60ad6

Оптимизирована внутренняя функция compactify_tuples, которая активно используется в процессах очистки и восстановления. Ничего настраивать не нужно. Просто работает быстрее. И чем больше записей на странице тем быстрее.

Уточнение оценки количества строк для пустых таблиц
commit: 3d351d91

Сразу после создания таблицы планировщик считает, что в ней уже есть записи:

CREATE TABLE t (id int, code text);EXPLAIN SELECT * FROM t;
                      QUERY PLAN                      ------------------------------------------------------ Seq Scan on t  (cost=0.00..22.70 rows=1270 width=36)

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

Это разумные предположения для таблицы, по которой еще ни разу не собиралась статистика, и к ним претензий нет. Но что будет если в таблице действительно нет записей и мы хотим, чтобы планировщик правильно это понимал? Предположим после заполнения таблицы, мы её полностью очистили, затем собрали статистику и заодно выполнили очистку:

INSERT INTO t SELECT g.x, random()::text FROM generate_series(1,100000) AS g(x);TRUNCATE t;VACUUM ANALYZE t;


EXPLAIN SELECT * FROM t;
                      QUERY PLAN                      ------------------------------------------------------ Seq Scan on t  (cost=0.00..22.70 rows=1270 width=36)

Однако планировщик не отличает эту ситуацию от предыдущей, когда таблица была только что создана. Как известно, для оценки количества строк используется значение pg_class.reltuples, а там 0 в обоих случаях.

Сейчас поведение изменилось. После создания таблицы и до первого выполнения VACUUM или ANALYZE значение pg_class.reltuples = -1 и планировщик по-прежнему ориентируется на заполненные 10 страниц в таблице:

CREATE TABLE t (id int, code text);SELECT reltuples FROM pg_class WHERE oid = 't'::regclass;
 reltuples-----------        -1
EXPLAIN SELECT * FROM t;
                      QUERY PLAN                      ------------------------------------------------------ Seq Scan on t  (cost=0.00..22.70 rows=1270 width=36)

Однако как только по таблице будет собрана статистика или выполнена очистка, значение reltuples устанавливается в реальное для пустой таблицы в 0 и планировщик сможет правильно оценить кардинальность:

ANALYZE t;EXPLAIN SELECT * FROM t;
                    QUERY PLAN                    -------------------------------------------------- Seq Scan on t  (cost=0.00..0.00 rows=1 width=36)

Заметим, что планировщик вместо 0 пишет 1, но это уже другая история.

Подводя итог. Вынесенный в начало статьи вопрос о количестве строк в пустой таблице имеет вполне определенный ответ. PostgreSQL 14 оценивает это количество либо как 0, либо -1, в зависимости от факта сбора статистики.

Репликация


Потоковая логическая репликация
commit: 46482432, 45fdc973, 808e13b2, 7259736a

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

Как известно, данные подписчику передаются только после фиксации транзакций на сервере публикации. А пока транзакции в работе, изменения накапливаются и раскладываются по транзакциям в переупорядочивающем буфере процесса wal sender. Если в одной транзакции изменяется очень много данных, то это может вызвать проблемы.

Во-первых, расходы на временное хранение данных в процессе wal sender. Конечно, данные не будут накапливаться в оперативной памяти. Параметром logical_decoding_work_mem, появившимся еще в 13 версии (commit: cec2edfa), можно регулировать объем оперативной памяти переупорядочивающего буфера. При превышении этого размера данные транзакций будут сбрасываться на диск.

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

CREATE|ALTER PUBLICATION  WITH (STREAMING = ON);

Такая публикация будет передавать данные подписчику не дожидаясь окончания транзакций, а ориентируясь на тот же параметр logical_decoding_work_mem). Подписчик, в свою очередь, сможет применять изменения порциями и показывать их пользователям только после получения информации о фиксации транзакции.

Для реализации потребовалось очень серьезно переработать механизмы логической репликации: обработку транзакций на стороне публикации (wal sender), протокол передачи через WAL, применение данных на стороне подписчика (logical_replication_worker). Работа велась долго (первое письмо датируется 2017 годом) и изменения применялись в несколько этапов (см. список только основных коммитов).

pg_waldump выводит содержимое сообщений в записях WAL для логической репликации
commit: 9f1cf97b

Это удобно для диагностики логической репликации. Запомним позицию в журнале WAL, отправим сообщение логической репликации и найдем сообщение утилитой pg_waldump:

SELECT pg_current_wal_insert_lsn();
 pg_current_wal_insert_lsn--------------------------- 0/8A8DAAC8
SELECT pg_logical_emit_message(false, 'my_prefix', '12345'::text);
 pg_logical_emit_message------------------------- 0/8A8DAB10


\! pg_waldump --start 0/8A8DAAC8 -p data
rmgr: LogicalMessage len (rec/tot):     65/    65, tx:          0, lsn: 0/8A8DAAC8, prev 0/8A8DAA90, desc: MESSAGE non-transactional, prefix "my_prefix"; payload (5 bytes): 31 32 33 34 35 остальная часть вывода опущена...

Сервер


Построение индексов GiST с сортировкой
commit: 16fa9b2b

Казалось бы GiST это не про сортировку, про сортировку btree. Однако во многих случаях можно использовать кривую Мортона для сортировки многомерных данных. И тогда становится возможным быстро строить индекс GiST также как и btree в виде дерева.

Андрей Бородин, вдохновленный прототипом Никиты Глухова, предложил и довел до коммита новый вариант построения индексов GiST, основанный на Z-упорядочивании.

Измерять скорость работы на ноутбуке весьма сомнительный способ показать увеличение производительности. Но всё-таки попробуем воспроизвести пример Андрея и создать индекс GiST вот для такой таблички:

CREATE TABLE x AS SELECT point (random(),random()) FROM generate_series(1,10000000,1);

Включим \timing и заодно посмотрим на размер индекса.

Версия 13:

CREATE INDEX ON x USING gist (point);
Time: 93597,070 ms (01:33,597)
SELECT pg_size_pretty(pg_indexes_size('x'));
 pg_size_pretty---------------- 709 MB

Версия 14:

CREATE INDEX ON x USING gist (point);
Time: 9232,814 ms (00:09,233)
SELECT pg_size_pretty(pg_indexes_size('x'));
 pg_size_pretty---------------- 474 MB

Дополнительные комментарии излишни, но с ними можно познакомиться в переписке.

Оптимизация добавления записей в pg_depend
commit: 63110c62, 8febfd18

Продолжение работы, начатой в июльском коммитфесте. Теперь набор записей о зависимостях добавляется в pg_depend за раз, а не каждая запись по отдельности.

Изменены системные лимиты, связанные с предотвращением зацикливания счетчика транзакций
commit: cd5e8225

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

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

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

Команды SQL


Использование ключевых слов в качестве псевдонимов без явного указания AS
commit: 1ed6b89, 06a7c31

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

SELECT 5!, factorial(5);
 ?column? | factorial----------+-----------      120 |       120

Постфиксные операторы сильно усложняют грамматический разбор и накладывают некоторые ограничения на синтаксис команд. Например для псевдонима выражения в команде SELECT нельзя выбрать большинство ключевых слов без указания AS:

SELECT 1 column;
ERROR:  syntax error at or near "column"LINE 1: SELECT 1 column;
SELECT 1 AS column;
 column--------      1

Так работает в 13 версии.

Первый коммит 1ed6b89 удаляет поддержку постфиксных операторов. А второй коммит 06a7c31 расширяет грамматические возможности. В PostgreSQL 14 больше нельзя вычислить факториал выражением 5!, но подавляющее большинство ключевых слов (411 из 450) можно объявлять псевдонимами без AS:

select 1 column;
 column--------      1

Список ключевых слов можно получить функцией pg_get_keywords.

Использование CURRENT_ROLE там, где поддерживается CURRENT_USER
commit: 45b9805

Проверяя соответствие стандарту SQL, Питер Эйзентраут обнаружил, что в PostgreSQL поддерживается только CURRENT_USER, но не CURRENT_ROLE в таком варианте команды GRANT:

GRANT ROLE role_name TO role_specification GRANTED BY CURRENT_USER;

Упущение исправлено, теперь CURRENT_ROLE можно использовать везде, где раньше было только CURRENT_USER. Например в командах на изменение владельца объекта:

ALTER objtype objname OWNER TO CURRENT_USER | CURRENT_ROLE;

Системное администрирование


pg_hba.conf и pg_ident.conf поддерживают перенос строк
commit: 8f8154a

Длинную строку в конфигурационных файлах pg_hba.conf и pg_ident.conf можно разбить на несколько, если в конце строки поставить обратную косую черту \.

Модуль pg_surgery инструмент для хирургического вмешательства
commit: 34a947ca

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

Какие проблемы с видимостью строк могут быть? Если по каким-то причинам будет нарушена служебная информация о видимости строк, то возможны две неприятные ситуации:

  • не видны строки, которые должны быть видны
  • видны строки, которые не должны быть видны

Посмотрим как можно решать(?) эти две проблемы на примере таблицы с первичным ключом и одной записью.

CREATE EXTENSION pg_surgery;CREATE TABLE t (id int PRIMARY KEY, code text) WITH (autovacuum_enabled=off);INSERT INTO t VALUES (1, 'Один');SELECT ctid, * FROM t;
 ctid  | id | code-------+----+------ (0,1) |  1 | Один

Изменим строку. Это приведет к появлению новой версии строки:

UPDATE t SET code = 'Единица' WHERE id = 1;SELECT ctid, * FROM t;
 ctid  | id |  code   -------+----+--------- (0,2) |  1 | Единица

Но предыдущая версия никуда не делась (автоочистка на таблице специально отключена), поэтому попробуем её оживить, причем сразу в замороженном виде:

SELECT heap_force_freeze('t'::regclass, ARRAY['(0,1)']::tid[]);SELECT ctid, * FROM t;
 ctid  | id |  code   -------+----+--------- (0,1) |  1 | Один (0,2) |  1 | Единица(2 rows)

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

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

SELECT heap_force_kill('t'::regclass, ARRAY['(0,1)']::tid[]);SELECT ctid, * FROM t;
 ctid  | id |  code   -------+----+--------- (0,2) |  1 | Единица(1 row)

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

Разное


Уточнение сообщения об ошибке при выборе границы диапазона для секции в секционированной таблице
commit: 6b2c4e5

Вот как выглядит сообщение об ошибке в 13 версии:

CREATE TABLE p (id int) partition by range (id);CREATE TABLE c_p1 PARTITION OF p FOR VALUES FROM (1) TO (0);
ERROR:  empty range bound specified for partition "c_p1"DETAIL:  Specified lower bound (1) is greater than or equal to upper bound (0).

В 14 версии появляется новая строка с указателем на неверное значение нижней границы диапазона:

CREATE TABLE c_p1 PARTITION OF p FOR VALUES FROM (1) TO (0);
ERROR:  empty range bound specified for partition "c_p1"LINE 1: CREATE TABLE c_p1 PARTITION OF p FOR VALUES FROM (1) TO (0);                                                          ^DETAIL:  Specified lower bound (1) is greater than or equal to upper bound (0).

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

REINDEX для секционированных таблиц
commit: a6642b3a

Команда REINDEX TABLE | INDEX может использоваться для секционированных таблиц и индексов. До этого требовалось выполнять REINDEX для каждой секции.

Новая функция string_to_table
commit: 66f1630

Как и следует из названия, функция разбивает строку на несколько строк по заданному разделителю. Раньше это можно было сделать в два приема, сначала превратить строку в массив (string_to_array), а затем массив разложить на строки (unnest):

SELECT string_to_table('1,2,3',','), unnest(string_to_array('4,5,6',','));
 string_to_table | unnest-----------------+-------- 1               | 4 2               | 5 3               | 6

По замерам автора патча, Павла Стехуле, string_to_table на 15% быстрее варианта unnest(string_to_array()).

Уточнение сообщения об ошибки vacuum
commit: 7e453634, a3c66de6

Сообщение об ошибке при выполнении очистки (vacuum) дополнено информацией о смещении внутри страницы, необходимой для определения версии строки, на которой произошла ошибка.

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



На этом пока всё. Продолжение следует после ноябрьского коммитфеста.
Подробнее..

Postgresso 26

13.11.2020 14:18:57 | Автор: admin


Жизнь продолжается. А мы продолжаем знакомить вас с самыми интересными новостями PostgreSQL.


Пополнение в Core Team

Напоминаем о неписанном правиле сообщества: в Core Team не должно быть большинство из одной компании. После слияния-поглощения EDB 2ndQuadrant 3 из 5 участников Основной Команды оказались коллегами по EDB. К счастью, никого не сократили, а добавили двух достойных: Андреса Фройнда (Andres Freund, Microsoft, Citus) и Джонатана Каца (Jonathan Katz, Crunchy Data).

Любимые области Андреса Фройнда: репликация, производительность и масштабируемость (смотрите три недавние статьи на эту тему, ссылки в нашем разделе Статьи. Производительность), хранение.

Джонатан Кац (Jonathan Katz, Crunchy Data) занимался патчами и ревью, но больше концентрировался на разработке и поддержке сайта, выпуске релизов и прочей сопутствующей, но необходимой деятельности. Он вообще важный человек: председатель совета директоров Ассоциации PostgreSQL в США (United States PostgreSQL Association) и директор Ассоциации PostgreSQL-сообщества Канады (PostgreSQL Community Association of Canada), которая выступает как юридическое лицо сообщества.

Прекрасное, взвешенное решение. Впрочем, не все с этим согласны: Альваро Эрнандес (lvaro Hernndez Tortosa если полностью) поздравил новоизбранных (непонятно кем и непонятно как по его мнению) и предложил задуматься над следующими 10 проблемами управления сообществом:
Влияние компаний:
  • 40% из Core Team были из одной компании, теперь 43%, 71% из двух;
  • 100% из всего лишь 4 компаний.

Многообразие (diversity):
  • 100% это белые мужчины;
  • 100% из США или Европы;
  • все кроме одного работают в американских компаниях.

Демократия:
  • членов Core Team назначают члены Core Team;
  • срок неограничен, четверо являются членами уже больше 15 лет.

Прозрачность:
  • процессы выбора членов и кандидатов, критерии выбора и пр. суть большой секрет;
  • заседания секретны;
  • стратегии (policies) объявляются, а не обсуждаются в сообществе.

Альваро предлагает высказаться. И Ханс-Юрген Шёниг (Hans-Jrgen Schnig) высказывается:
Никогда не замечал и тени расизма при принятии патчей. Может и дальше будем продолжать как было думать о компетентности, а не о расе, гендере или о чём там? У нас с этим никогда не было проблем. Так зачем проблему создавать? Клаус Расмуссен (ClausRasmussen) ещё решительней: зачем нам этот crap с идентичностями? У нас технологическое сообщество, а не Liberal_arts_college. Желающие могут запастись попкорном и следить за дискуссией. Этот текст обсуждается также здесь.

Я опустил детали в обращении Альваро. Ещё одна из упомянутых им проблем (существующих с точки зрения Альваро): Core Team это центральный орган проекта. А юридически проект представляет Postgres Association of Canada, определяя в том числе интеллектуальную собственность: доменные имена, торговые марки и прочее. Как бы чего не вышло.

CF-новость

Анастасия Лубенникова из Postgres Professional стала распорядителем текущего коммитфеста. В этом ей помогает Георгиос Коколатос (Georgios Kokolatos).

Новости PG-этики

А ещё Анастасия входит в Комитет по этике (Code of Conduct Committee) сообщества (а Илья Космодемьянский вышел из комитета).

Кстати, благодаря то ли Альваро, то ли общему настроению, Комитет по этике объявил вакансии: нужны люди из разных стран и разных народов, чтобы отразить многообразие PostgreSQL-сообщества. Пишите на coc@postgresql.org

Документация к PostgreSQL 13.0


The PostgreSQL Global Development Group объявила о доступности русской документации к версии 13. Перевод на русский язык компания Postgres Professional. Официальная страница русскоязычной документации.

Обучение


DEV2: Разработка серверной части приложений PostgreSQL 12. Расширенный курс.

Новый курс продолжительностью 4 дня. В нём:
  • понимание внутренней организации сервера;
  • полное использование возможностей, предоставляемых PostgreSQL для реализации логики приложения;
  • расширение возможностей СУБД для решения специальных задач.

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

Статьи


Масштабируемость и производительность


Measuring the Memory Overhead of a Postgres Connection

Андрес Фройнд (тот самый, кто только что обосновался в PostgreSQL Core Team) опубликовал серию из 3 статей о производительности PostgreSQL при большом числе соединений. Они дублируются в блоге Citus и в блоге Microsoft (пока 20 лайков, 2 подписчика).

В статье об издержках памяти начинается с популярного мотива а если бы треды, а не процессы? Спойлер Андреса: если аккуратно померить, то издержки меньше 2 мебибайта. А неаккуратно это при помощи top и ps.

Для более тонких замеров памяти Андрес использует системные /proc/$pid/status и /proc/$pid/smaps_rollup. Так можно увидеть значения VmRSS, VmRSS, RssAnon, RssFile, RssShmem если вы не знали, что это, то из статьи узнаете и поймёте, почему они важны. Чтобы не обмануться с причиной перерасхода памяти, он замеряет с включенным и отключенным huge_pages. Ещё: надо помнить о copy-on-write при форке процесса.

Analyzing the Limits of Connection Scalability in Postgres

Андрес исследует узкие места с тем, чтобы далее предложить путь их решения, и аргументирует не только из общих соображений, а с примерами и листингами. Раздувание кеша (cache bloat) тоже (как и оверхед при форке) не критично. Управление work_mem тоже удовлетворительно. А собака зарыта в куче снэпшотов: функция GetSnapshotData() дорогая и вызывается часто. Вывод: надо менять саму модель соединений (connection model), а может и модель исполнения запросов (query execution model). А от себя добавим: эта тема более, чем активно обсуждалась в рассылке hackers. Более того: в Postgres Professional давно ведутся разработки в этом направлении. Начиная с 12-й версии в Postgre Pro Enterprise Edition есть встроенный пул соединений. Это не совсем то, что сделал Андрес, но это тоже в тему масштабируемости клиентских соединений.

За диагностической 2-й статьёй следует 3-я конструктивная: предложения Андреса уже в форме патчей, которые должны войти в версию PostgreSQL 14:

Improving Postgres Connection Scalability: Snapshots

Пересказывать эту статью в паре абзацев, кажется, бессмысленно. Даём ссылки на серию патчей Андреса (все они начинаются с snapshot scalability: здесь опускаем):
Dont compute global horizons while building snapshots
Move PGXACT->xmin back to PGPROC
Introduce dense array of in-progress xids
Move PGXACT->vacuumFlags to ProcGlobal->vacuumFlags
Move subxact info to ProcGlobal, remove PGXACT.
cache snapshots using a xact completion counter
(Об этом также здесь)

Другую серию из 3 статей в жанре от 8.3 и до 13 опубликовал Томаш Вондра (Tomas Vondra, 2ndQuadrant то есть EDB).

OLTP performance since PostgreSQL 8.3

В этой статье Томаш сначала объясняет замысел серии: почему начал с 8.3, почему именно эти тесты, зачем ему тестировать полнотекстовый поиск, на какой машине тестировать. Он не ставит цели сверхкорректного сравнения, это скорее упражнение для лучшего понимания PostgreSQL. До 8.3 он уж слишком отличался от нынешнего, охват и так недурен: 12 лет. А машина обычный офисный компьютер.

В 1-й статье серии Томаш исследует производительность OLTP на bgbench, взятой из 13-й версии, scale 100 (1.6 ГБ), 1 000 (16 ГБ) и 10 000 (160 ГБ). Клиенты от 1 до 256. Хранение NVMe SSD / SATA RAID; режимы: read-only (pgbench -S) / read-write (pgbench -N)

Графики с NVMe SSD ведут себя прилично: производительность в основном монотонно растёт с номером версии. А вот с SATA творятся чудеса: c SATA RAID в режиме чтения некоторые флюктуации и, похоже, регресс в версии 9.6. А вот на записи-чтении грандиозное ускорение с версии 9.1 в 6 раз!

Томаш уверен, что постгрессистам придут в голову блестящие идеи, как эффективней использовать ресурсы железа. Патчи по улучшению масштабированию соединений или патч по неволатильным буферам WAL тому пример. Можно ждать радикальных улучшений в хранении (более эффективный формат файлов на диске, использование прямого ввода-вывода, например), более эффективные индексы.

TPC-H performance since PostgreSQL 8.3

Для измерения производительности на аналитических нагрузках Томаш запускал бенчмарк TPC-H (его ещё называют бенчмарком принятия решений decision support), получал результаты, которые можно анализировать ещё очень долго, нарисовал красивые графики, и сделал свои выводы в меру отпущенного на это времени.

В TPC-H 22 запроса на 3 наборах данных: малом, среднем и большом. Томаш гоняет их на версиях от 8.3 до 13, да ещё и то включает, то отключает параллелизм. Коэффициенты масштабирования (scale factor) он выбирает такие: 1 (цель поместиться в shared-buffers), 10 (в память) и 75 (не поместиться в память). Комбинаций море, для анализа простор. Иногда автор действительно опускается до отдельных запросов и анализирует причины странного поведения. Кривая производительности немонотонно меняется с версией, а по отдельным запросам скачет совсем неожиданно. Причина простая: планировщик и оптимизатор умнеют с новыми версиями за счёт новых планов и/или за счет новых способов использования статистики, но оборотная сторона промахи: неверный выбор плана из-за плохой статистики, оценок стоимостей или других ошибок. Примерно то же и с параллелизмом: появляются новые планы, но если стоимости и оценки расходятся с реальностью, выбираются планы, хуже старых, последовательных.


Диаграмма из статьи TPC-H performance since PostgreSQL 8.3. Можно было поместить в наш раздел Прекрасное.

Full-text search since PostgreSQL 8.3

В преамбуле Томаш рассказывает историю FTS в PostgreSQL, которая началась с Олега Бартунова и Фёдора Сигаева лет за 20 до основания Postgres Professional. Далее Томаш сетует на отсутствие индустриальных стандартов тестирования полнотекстового поиска и обращается к собственным ресурсам ПО: в незапамятные времена он сочинил утилиту archie парочку питоновых скриптов, которые загружают архивы переписки PostgreSQL, превращая их в базу, которую можно индексировать, в которой можно искать тексты. Сейчас в таких архивах около миллиона строк 9.5 ГБ не считая индексов. В качестве тестовых запросов он взял 33 тыс. реальных поисковых запросов к архиву на сайте PostgreSQL.org.


Фёдор Сигаев и Олег Бартунов. Фотография из статьи Full-text search since PostgreSQL 8.3

Запросы были разного типа, но для статьи взял вот такие с tsvector, придуманным ещё Бартуновым и Сигаевым:
SELECT id, subject FROM messages WHERE body_tsvector @@ $1SELECT id, subject FROM messages WHERE body_tsvector @@ $1ORDER BY ts_rank(body_tsvector, $1) DESC LIMIT 100


Кроме того Томаш тестировал влияние индексов GIN и GiST. Оба запроса с использованием GIN дают огромный скачок в производительности в 4 с лишним раза! Томаш благодарит за это Александра Короткова и Хейкки Линнакангас (Heikki Linnakangas), придумавших патч Improve speed of multi-key GIN lookups. А вот если использовать GiST, то ничего хорошего вообще не будет. А будет плавная деградация. Почему ж никто не жаловался? вопрошает автор и предполагает, что вместе с апгрейдом версий многие апгрейдили и железо, и это маскировало эффект. Или просто не использовали GiST для текстового поиска.

Олег, Теодор [Фёдор] и их коллеги напоминает Томаш работали над более мощными вариантами GIN-индексов VODKA и RUM [примечание редакции: об индексах RUM, о том, чем они лучше GIN, о расширении rum можно почитать здесь. Про водку не будем :)]. Это как минимум поможет некоторым типам запросов. Особенно автор надеется на улучшение поддержки новых типов полнотекстовых запросов, так как новые типы индексов спроектированы для того, чтобы ускорить фразовый поиск (см. там же).

Книжечки

Кстати, о текстовых файлах и поиске в них. Вот 196640 книг (файлов) в текстовом формате. Их, скорее всего, будут использовать для обучения больших сетей, но можно их, скажем, использовать и в каких-нибудь тестах производительности текстового поиска или ещё каких-то манипуляций текстом. Собирали тексты энтузиасты с the-eye.eu (почему-то недоступного честному пользователю из РФ).

PostgreSQL 14: Часть 2 или в тени тринадцатой (Коммитфест 2020-09)

Эта статья Павла Лузанова из отдела образования Postgres Professional и о производительности тоже: постольку, поскольку патчи, принятые на этом коммитфесте, имели отношение к производительности (о патчах Андреса, которые он упоминал, там тоже есть). Это, как и Часть 1 (Коммитфест 2020-07), MUST READ для тех, кто следит за технологическими новшествами PostgreSQL без IMHO.

Жизнь в PostgreSQL


памяти Джона Хортона Конвея, умершего от COVID-19

Открывает эту мемориальную подборку ссылок недавняя статья Егора Рогова: Жизнь на PostgreSQL

Некто Сергей aka ildarovich делает это на языке запросов 1С, а точнее одним запросом: Игра Жизнь в одном запросе

А вот на C#: Как ускорить игру Жизнь в сто раз, в комментариях есть SQL-код.

На JS, огромная статья, очень красивая визуализация: Эволюционирующие клеточные автоматы

Кстати, о Конвее: Джо (Joe), однофамилец классика клеточных автоматов (в прошлом выпуске мы ссылались на статью 2007-го года про то, как использовать PL/R для GIS) теперь, в начале ноября 2020, пишет на тему сверх-актуальную:

Election Night Prediction Modeling using PL/R in Postgres

Он использует пакеты mvtnorm (3 алгоритма нормального распределения), politicaldata (специальные тулзы для сбора и анализа политических данных) и tidyverse (разные средства анализа данных). Для развлечения Джо предлагает разобраться в немалом количестве строк кода, создаёт свой тип данных и ещё предлагает придумать SQL-запросы в качестве упражнения.

Релизы


PostgreSQL 13.1

А также 12.5, 11.10, 10.15, 9.6.20 и 9.5.24. В новых версиях исправлены обнаруженные баги, в том числе связанные с безопасностью. Сейчас мы не будем на них останавливаться. Они описаны на этой странице.

OpenGauss 1.0.1

Сотрудник Huawei Вадим Гусев сообщает на хабре о появлении openGauss: новая СУБД от Huawei для нагруженных enterprise-проектов прибавила в функциональности

Это форк PostgreSQL, опенсорсный вариант проприетарной GaussDB, который работает на x86 и китайских процессорах Kunpeng 920, у которых архитектура ARM64 (к слову: напоминаем, что ARM ltd куплена Nvidia), то есть мы можем предположить курс на китайское импортозамещение (в нише ARM у нас не Эльбрусы, а Байкалы).
Как утверждают создатели, у OpenGauss гибридная ориентация в духе HTAP, и она многое умеет :
  • колоночное хранение;
  • in-memory engine;
  • развертывается решение как в контейнерах, так и на физических серверах;
  • ИИ (глубокое обучение с подкреплением в сочетании с эвристическими алгоритмами) рекомендует параметры.;
  • инкрементальное резервное копирование;
  • Standby на удаленной площадке в синхронном или асинхронном режиме (до четырех реплик на физическом уровне).

В статье с длинным интернациональным списком авторов (фамилии от индийских до русских, китайцы в меньшинстве) оценивается производительность на TPC-C.

Database Lab 2.0

Николай Самохвалов и Артём Картасов из Postgres.ai (Артём делал бОльшую часть кода) на Постгрес-вторнике 3 ноября рассказали (за полтора часа) о Database Lab 2.0 новой, сильно отличающейся версии своей среды для тестирования и разработки с тонкими клонами (при клонировании копируются только измененные блоки).

Новое:
  • поддержка RDS и других облачных Postgres-сервисов;
  • физическое развертывание с нативной поддержкой WAL-G;
  • декларативное развертывание;
  • управление снэпшотами, политики снэпшотов;
  • предобработка данных (анонимизация);
  • time travel для диагностики, контроля изменений, быстрого точечного восстановления;
  • оптимизация SQL на новом уровне: serverless EXPLAIN и бот-помощник для оптимизации;
  • 100% покрытие миграций БД (изменение схемы) автоматическими тестами на полноразмерных копиях БД;
  • регрессивные тесты;
  • поддержка docker-имиджей для Postgres 9.6, 10, 11, 12 и 13; по умолчанию в них расширения Timescale, Citus, PoWA и много других, а также большинство расширений, поддерживаемых Amazon RDS;
  • документация сильно расширена.


pg_statement_rollback 1.0

pg_statement_rollback это расширение Жиля Дароля (Gilles Darold), Жульена Руо (Julien Rouhaud) и Дэйва Шарпа (Dave Sharpe), которое реализует в PostgreSQL откат транзакции на уровне оператора (server side rollback at statement level for PostgreSQL) как в Oracle или DB2. Это значит, что при ошибке в выполнении оператора его результаты не видны как будто оператора и не было. При этом результаты операторов, выполненных в транзакции до этого, не теряются. В PostgreSQL это можно было сделать только на клиенте, в psql, например:
\set ON_ERROR_ROLLBACK on

Теперь всё будет работать на сервере таким образом, как будто для каждого оператора серверу посылаются
SAVEPOINT autosaveиRELEASE SAVEPOINT autosave

а такая роскошь раньше могла сказаться на производительности. Авторы дают результаты тестов TPS-B и честно рассказывают о проблемах.

pgbitmap 0.9.3

Бета-релиз расширения pgbitmap, доступно на pgxn и github.

Это расширение Марка Манро (Marc Munro) создаёт тип pgbitmap с полным набором функций, операторов и агрегатов. Он отличается от стандартных типов Postgres bit и bit varying тем, что строка не начинается с нулевого бита и тем, что набор операций намного богаче. Этот тип разрабатывался под Virtual Private Database для управления привилегиями. В этом релизе исправлены ошибки, он считается релизом-кандидатом. Сейчас открытых багов не осталось присылайте, если найдёте.
Документация здесь.

pgpool-II 4.2 beta1

В новой версии:
  • улучшено и упрощено конфигурирование логирования;
  • добавлен новый режим кластера: snapshot_isolation_mode, который гарантирует не только модификацию данных нескольким инстансам, но и согласованность по чтению;
  • поддержка LDAP-аутентификации между клиентом и Pgpool-II;
  • импорт SQL-парсера PostgreSQL 13.

и прочее, о чём можно прочитать в Release notes.

Загрузить можно отсюда.

pg_activity 1.6.2

pg_activity это интерфейс в стиле top для мониторинга бэкендов PostgreSQL в реальном времени. Поддерживается Бенуа Лабро (Benoit Lobrau, Dalibo Labs). В нём можно:
  • настраивать частоту обновления;
  • переключаться между тремя представлениями запросов: исполняющиеся/ждущие/блокирующие;
  • сортировать по PostgreSQL-метрикам: READ/s, WRITE/s


Зависимостей теперь мало. Работает на Python 2.6+. Исходники здесь.

pgcenter 0.6.6

На гитхабе Алексея Лесовского (Data Egret) появилась новая версия. В ней:
  • рейтинги запросов адаптированы к версии PostgreSQL 13;
  • тайминги операторов адаптированы к версии 13;
  • надо проапдейтить конфигурацию travic-ci: отключить skip_cleanup; проапгерйдить Go до версии 1.14.


pglogical 2.3.3

Появилась поддержка PostgreSQL 13. Загружать отсюда. Чейнджлог недоступен, за информацией велено обращаться к info@2ndQuadrant.com.

repmgr 5.2.0

Добавлена поддержка PostgreSQL 13. Из изменений:
  • новая опция --verify-backup запускает утилиту pg_verifybackup после сканирования реплики, чтобы убедиться в консистентности скопированных данных (только для PostgreSQL 13 и позже);
  • у failover_validation_command появились новые параметры и конфигурационная опция always_promote для управления промоутированием ноды в случае, когда метаданные repmgr уже неактуальны;
  • поддержка PostgreSQL 9.3 прекращена.


Есть и другие изменения, о которых можно узнать здесь. Сорсы находятся здесь, а инструкции по инсталляции здесь.

Прекрасное


Популярность баз 2006 2020

Скриншоты не передадут гипнотической мощи этой динамической инфографики от DB weekly. Это кино увлекательно, познавательно воодушевляюще и даже чуть-чуть отрезвляюще в то же время.



а через 14 лет популярность PostgreSQL выросла более, чем в 2 раза:



Postgres Observability

Интерактивный шедевр наглядности & информативности (этот скриншот в подмётки не годится). Автор Алексей Лесовский из DataEgret.



Конференции


Highload++

Внимание: переносится! Новые даты конференции 17 и 18 февраля 2021 года!

Ибица 2020 зачеркнуто 2021

Одна из самых любимых PG-народом конференций Postgres Ibiza 2020 должна состояться в 2021 году 23-25-го июня (дата предварительная). Следите за новостями на pgibz.io или на сайте FUNDACIN POSTGRESQL сообщества с испаноязычным уклоном. Про Бали пока не слышно.

Postgres Build 2020

Виртуальная европейская конференция по PostgreSQL, посещение бесплатное. Фокус на кейсы реальных клиентов. Пройдёт 8-9 декабря 2020 он-лайн. Twitter и LinkedIn: #postgresbuild.
Подробнее..

Postgresso 27

31.12.2020 04:15:41 | Автор: admin


Ну и год выдался! Подходит к концу. 21-му надо изрядно постараться, чтобы стать хуже. Но он надеемся стараться не будет. А жизнь продолжается. И мы продолжаем знакомить вас с самыми интересными новостями PostgreSQL.

Но сначала поделимся воспоминаниями: как проводил время на хабре отдел образования компании Postgres Professional:
  • Начнём с того, что под рукой с Postgresso. Из фонового и иногда побочного занятия Postgresso сместился к центру, стал новостным каналом со стабильной периодичностью примерно месяц. Мы отказались от плоского формата большой простыни с большим списком релизов и статей по 3-5 строчек на каждую. В 21-м продолжим экспериментировать, но от периодичности не откажемся.
  • Наш коллективный труд PostgreSQL 13. Чертова дюжина. Первый (задержка в 37 минут после заморозки) и самый полный обзор возможностей 13 версии. Далее последовали обзоры коммитфестов: Июльский, Сентябрьский и Ноябрьский Павла Лузанова. Эта практика 20-го года будет продолжена и в 21-м. Мы часто сами на них ссылаемся а как не сослаться? Они действительно информативны.
  • Жизнь в PostgreSQL и в Postgresso 26 подборка других реализаций Жизни памяти Джона Хортона Конвея, умершего от COVID-19.
  • Автор статьи Серверное программирование на человеческом языке, очень понравившейся хабр-читателям Иван Панченко. Мы помогали Ивану в подготовке статьи.
  • Сотрудник нашего отдела образования Павел Толмачёв написал для хабра статью о модуле aqo. Тема непростая, а тема использование ИИ для оптимизации запросов актуальна, а станет ещё актуальней.
  • К тому же бОльшая часть статей была переведена на английский (спасибо Елене Индрупской за титанический труд). Это серии очень глубоких погружений Егора Рогова Locks in PostgreSQL (ru), WAL in PostgreSQL (ru), MVCC in PostgreSQL (ru) и Indexes in PostgreSQL (ru). Кроме того переведён ещё десяток статей, наиболее интересных для англоязычной аудитории. Некоторые из этих статей попадали в англоязычные обзоры самых интересный статей.


Релизы



Вышла Postgres Pro Standard 13

18 декабря 2020 года компания Postgres Professional выпустила новый релиз Postgres Pro Standard 13.1.1. Это первый из тринадцатых релизов Postgres Pro.

Среди новых возможностей:

Новое расширение pgpro_pwr (или PWR, читается как power). Это расширение позволяет получать отчёты по нагрузке, полезные для выявления наиболее ресурсоёмких операций в базе данных. Оно умеет использовать данные расширения pgpro_stats, предназначенного для сбора статистики выполнения SQL-операторов и подсчёта статистики событий ожидания. pgpro_stats обновлено. В январе мы опубликуем на хабре отдельную статью о PWR.

Появилась поддержка операционной системы ОСнова 2.0. Также исправлены ошибки в PostgreSQL 13.1. Среди этих исправлений устранение уязвимостей CVE-2020-25694, CVE-2020-25695 и CVE-2020-25696 (6 патчей сотрудников Postgres Professional).

Postgres Operator v1.6.0

Релиз поддерживает последнюю PostgreSQL 13 и новый образ Spilo 13 (спило слон по-грузински), в котором имеется Patroni 2.0 (но последняя версия Patroni на сегодня 2.0.1). Апгрейд ещё не автоматический, но сильно упростился. Проще стало развертывание pgBouncer на репликах. Подробности в чейнджлоге и в доке.

Pgpool-II 4.2.0

Изменения:
  • в этом релизе теперь во всех образцах файла pgpool.conf путь к сокетам /var/run/postgresql;
  • Используется единственный сегмент разделяемой памяти для всех разделяемых переменных родительского процесса pgpool;
  • при старте убиваются существовавшие до того файлы сокетов watchdog

Загрузить можно отсюда.

pg_timetable: Advanced PostgreSQL Scheduling

Это шедулер, написанный на Go разработчиками Cybertec и работающий как отдельное приложение (для сравнения: pgpro_scheduler выполнен как расширение). Он умеет выполнять задания, состоящие из нескольких разнородных действий, например:
  • начать транзакцию;
  • записать в лог;
  • загрузить файл;
  • импортировать файл;
  • запустить агрегирование;
  • закоммитить транзакцию.

pg_timetable на гитхабе.

Новый начальник Коммитфеста


Масахико Савада (Masahiko Sawada, NTT) стал распорядителем нового Коммитфеста (предыдущий координировала Анастасия Лубенникова)

Статьи


PostgreSQL 14: Часть 3 или ноябрьское затишье (Коммитфест 2020-11)

Это изменения после ноябрьского коммитфеста, последнего в 2020. Павел Лузанов сам предлагает обратить особое внимание на вопросы:
  • Не пора ли увеличивать wal_buffers?
  • Можно ли перегружать хранимые подпрограммы по OUT-параметрам?
  • По умолчанию pg_stat_statements собирает данные о 5000 запросов. Как понять много это или мало?
  • Что будет, если в операционной системе обновится библиотека libc?

Текст огромный, так как список изменений полный. Продолжение следует после январского коммитфеста.

Обзор операторов PostgreSQL для Kubernetes: Часть 1: наш выбор и опыт и Часть 2: дополнения и итоговое сравнение"

В первой части Николай Богданов в блоге компании Флант, советовал начать с доклада на Highload++ своего коллеги Дмитрия Столярова, где тот знакомит с общими принципами работы баз данных в Kubernetes (K8s). Николай же формулирует 6 основных требований со стороны K8s и рассматривает операторы:
  • Stolon. Этот довольно популярный отказоустойчивый кластер интегрирован в K8s. Но Stolon не подошёл, так как первое же (деплой из Git и с Custom Resources) из тех кубернетовских требований не удовлетворено (нет Custom).
  • Crunchy Data PostgreSQL Operator разработка нашего старого postgres-знакомого CrunchyData (автор называет молодым стартапом) богат фичами, но он оттолкнул несоответствием принятым в K8s стандартным возможностям работы с ресурсами.
  • Zalando Postgres Operator понравился больше всего. И возможностей много, и развивается быстро, и соответствует look & feel в глазах истых кубернетчиков.

Дальше Николай начинает работать с Crunchy Data PostgreSQL Operator, делится впечатлениям. А они не столько радужны, как хотелось. Список проблем и их решений, а также план миграции прилагаются.
Во второй части обзора, вышедшей 13-го ноября, добавились ещё два K8s-оператора:
KubeDB и
StackGres.
В результате появилась сводная таблица матрица имеющихся возможностей этих 5 операторов. Но сердце автора уже прикипело к Zalando, он объявлен лучшим вариантом для тру кубернетчика.

What are table access methods, and what is their importance to PostgreSQL?

Статья Панкаджа Капура (Pankaj Kapoor, Fujitsu) этакое обозрение уже не такой уж короткой (4 года) истории попыток интегрировать вертикальное хранение в PostgreSQL. Автор наблюдал этот процесс не как посторонний: Fujitsu, где он работает, предлагала сообществу свой Vertical Clustered Index в 2016, одновременно с патчем подобной направленности, предложенным Альваро Эррера (lvaro Herrera, 2ndQuadrant, теперь EDB). Со стороны Fujitsu внедрением Vertical Clustered Index занимался Харибабу Коми (Haribabu Komi). Но сообщество пошло другим путём: сосредоточило усилия на универсальном решении на API методов доступа к таблицам, по образцу методов доступа к индексам.

Сейчас, на конец 2019-го через слой методов доступа идёт интеграция с таблицами альтернативного типа хранения, zheap, например. Но пока только с доступом на базе кортежей, то есть до интеграции вертикального хранилища (реальный претендент Zedstore) ещё далеко.

Автор предлагает заодно ознакомиться со своей презентацией на PGCon2019.

Напомним и о vops интересном расширении Postgres Professional, поддерживающем векторные операции. Данные там группируются по значениям столбцов и хранятся в виде плиток (паркета).

Insert-Only Data Modelling To Smooth Peaks On Slow Disks

Каарел Моппел (Kaarel Moppel, Cybertec) предлагает неожиданный и даже контринтуитивный способ сглаживания пиков: вместо UPDATE данных только INSERT на время пиков нагрузки, чтобы потом, в спокойные часы разобраться с данными, вставленными в экстремальной ситуации. Выигрыш в скорости INSERT vs UPDATE на тестовых данных Каарела (100 млн записей) получился раза в 3. Конечно, этот способ подходит отнюдь не во всех случаях, но Каарел говорит об опыте конкретной проблемы заказчика, у которого не было возможности или желания апгрейдить железо из-за пиков, в то время, как в обычных условиях система справлялась.

10 Things I Hate About PostgreSQL

Под Новый Год лучше бы уж не о ненависти, а о любви. Ну да ладно. Рик Бронсон (Rick Branson), работавший в том числе с петабайтного масштаба проектами, решил подытожить 2020-й десяткой самых ненавистных ему особенностей PostgreSQL (некоторые наши спойлеры курсивом):

#1: Wraparound, чреватый катастрофой
[скорее всего когда-то в будущем XID-ы станут 64-разрядными целыми (то есть как уже давно в Postgres Pro Enterprise)];
#2: При переключении кластера (failover) могут потеряться данные;
#3: Неэффективная репликация, распространяющая испорченные данные;
#4: Частая сборка мусора в СУБД типа MVCC проходит болезненно
[Вся надежда Рика на будущий zheap];
#5: Принцип по процессу на соединение мешает масштабируемости
[Рик рассказывает, как использовал 2 слоя pgbouncer-ов и как доходило в общей сложности до миллиона процессов; а также скучает про тред-на-соединение в MySQL];
#6: Индекс по Primary Key очень прожорлив по части ресурсов
[Рик предлагает использовать индекс-таблицы];
#7: Для апгрейда мажорных версий может потребоваться остановка СУБД
[Из-за несовместимости бинарных форматов хранения файлов на диске могут потребоваться часы простоя. Это при потоковой репликации. Переход на логическую может решить проблему в будущем];
#8: Неуклюжая настройка репликации;
#9: Странная догма Никаких-подсказок-планировщику;
#10: Отсутствие компрессии на уровне блоков.

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

Waiting for PostgreSQL 14 Multirange datatypes

Как всегда активен Депеш, он же Хуберт Любашевски (Hubert Lubaczewski). Здесь он пишет о патче Александра Короткова. Как можно догадаться, многодиапазонные типы собираются из непересекающихся диапазонов. Как и диапазоны, они строятся на базе integer, bigintint, numeric, timestamp without time zone, timestamp with time zone, date.

Депеш создает многодиапазонные данные и пробует их на зуб: смотрит, какие индексы с ними уже можно создавать. btree уже точно можно, так что вот такой запрос будет ускоряться:

SELECT * FROM testWHERE ranges = '{[77.7909859996235,177.7909859996235],(1035.84122266822,1135.84122266822],(1000099.99954803,1000199.99954803]}';


How to install and configure PostgreSQL Debian/Ubuntu for developer use part 1

А здесь Депеш решил расписать шаги по установке PostgreSQL-13, настройке пользователей, редактировании pg_hba.conf и запуске PgAdmin под произвольным пользователем. Это азбука, но какие-то нюансы могут и пригодиться. Содержание следующих частей пока не анонсировано. На всякий случай напоминаем о существовании Малютки.

Waiting for PostgreSQL 14 pg_stat_statements: Track time at which all statistics were last reset.

Идёт постоянное усовершенствование pg_stat_statements. В 1-м и 3-м обзорах коммитфестов от Павла Лузанова уже было о некоторых коммитах. Депеш пишет о важном коммите Фуджи Масао (Fujii Masao): времени последнего ресета статистики. Информацию в pg_stat_statements время от времени очищают приложения и отдельные запросы:

SELECT pg_stat_statements_reset();


Теперь можно спросить у pg_stat_statements о времени последней чистки:

SELECT stats_reset FROM pg_stat_statements_info; dealloc |          stats_reset          ---------+-------------------------------       0 | 2020-12-20 12:06:02.099943+01

Postgres, PL/Python and SciPy/NumPy for Processing Images

Это продолжение статьи о сохранении картинок через Django-приложение в тип PostgreSQL bytea. На этот раз картинки ещё и обрабатывают фильтром.

Is Update The Same As Delete + Insert In PostgreSQL

Ответ: почти. И дальше Лоренц Альбе (Laurenz Albe) из Cybertec исследует это почти. Речь о блокировках при стандартном уровне изоляции: READ COMMITTED.
Session 1                     Session 2 BEGIN; UPDATE uptest SET id = 2   WHERE val = 42;                               SELECT id FROM uptest                                  WHERE val = 42                                  FOR UPDATE;  -- hangsCOMMIT;                               -- one row is returned

А в другой раз:
Session 1                     Session 2 BEGIN; DELETE FROM uptest   WHERE id = 1; INSERT INTO uptest VALUES (2, 42);                               SELECT id FROM uptest                                  WHERE val = 42                                  FOR UPDATE;  -- hangsCOMMIT;                               -- no row is returned

в первый раз возвращается 1 запись, во втором 0.
Дальше Лоренц исследует эту ситуацию, используя расширение pageinspect, да ещё и рассказывает о разнице поведения атрибутов infomask и infomask2 в этих двух случаях.

Конференции


Неопределённость сохраняется. Кто-то уже объявил о переформатировании в он-лайн.

PGCon 2021

В 2021-м пройдёт 28-го мая в сокращенном формате. От конференции осталась только Unconference, которая уместится в zoom. Записаться можно здесь.

Nordic PGDay 2021

Запланирована на 18 марта в Хельсинки. Об он-лайне пока ни слова. Год назад эта конференция была отменена из-за эпидемии.

Облака


Want more PostgreSQL? You just might like Babelfish

Этот проект откровенно ориентирован на тех, кто хочет беспроблемно мигрировать с MS SQL Server на PostgreSQL. Утверждается, что Bablefish это PostgreSQL, совместимый с SQL Server настолько, что приложения, под него написанные (в том числе с T-SQL и протоколом TDS), будут сразу работать.

Новости юриспруденции


Trademark Policy изменилась

Изменения касаются и Slonik-а то есть милой сердцам постгресистов картинки, и торговых марок.

Кто ты, бек-эндер?


Может ты бэкендер? Этот в высшей степени непростой вопрос разбирается в пространном исследовании Острые орфографические боли по всей длине слова и как от них избавиться на сайте ГЗОМ. Любители отгадывать зажмурьтесь: дальше ответы-спойлеры.

Сегодня нормативно:
Бэк-энд, бэк-энд-разработчик. В профессиональных текстах back-end-разработчик.

Соответствуют русской орфографии:
Бэкендер, бэк-эндовый.

Лет через семь могут возобладать:
Бэкенд, бэкендовый.



Предыдущие выпуски:
#26, #25, #24, #23, #22, #21, #20, #19, #18, #17, #16, #15, #14, #13, #12, #11 (спец), #10, #9, #8, #7, #6, #5, #4, #3, #2, #1
Подробнее..

Postgresso 28

02.02.2021 04:10:20 | Автор: admin


Привет всем уже в 21-м году. Надеемся, он будет добрей к нам, чем прошлый. Жизнь продолжается. И мы продолжаем знакомить вас с самыми интересными новостями PostgreSQL. Для разнообразия начну с конференций: этот жанр больше всего пострадал.

Конференции


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

Nordic PGDay 2021

Отменена. Рассчитывают на Хельсинки в марте 2022. Виртуального варианта не будет, но собираются сфокусироваться на PostgreSQL-треке FOSDEM 2021 в феврале. На сайте написано 2022, но имеется в виду, судя по всему FOSDEM 2021, о котором ниже.

А вот подход Highload++. Бескомпромиссный никакого онлайна:
Highload++ 2020 (2021)

Конференцию HighLoad++ не стали переносить в онлайн решили, что она для этого слишком масштабная. Но даты передвинули с 9-10 ноября 2020 г. на 20-21 мая 2021 года. Должна пройти в Москве в Крокус Экспо 3.

А вот полная противоположность:
FOSDEM 2021

Никакого Брюсселя, в 2021 только онлайн. Не только бесплатно, но и регистрации даже не требуется. Среди участников этой огромной конференции немало докладчиков, известных среди российских постгресистов: Олег Бартунов, Павел Борисов, Алексей Кондратов, Анастасия Лубенникова, Никита Глухов (Postgres Professional), Николай Самохвалов (Postgres.ai), Пётр Зайцев (Percona), Андрей Бородин (Yandex), Олег Иванов (Samsung AI Center, он автор плагина AQO в Postgres Pro Enterprise).
Расписание можно попробовать изучить здесь. Поток PostgreSQL здесь.

PGConf.Online 2021

Последняя в этом списке, компенсирую большим количеством знаков: у меня просто больше информации.
Здесь комбинация оф и он: офлайн-конференция PGConf.Russia 2021 запланирована на на конец мая начало июня 2021 года. А 1-3 марта будет проведена онлайн-конференция с соответствующим названием PGConf.Online 2021.

Темы конференции:
  • Postgres на предприятии;
  • Масштабируемость;
  • Высокие нагрузки и очень большие базы данных;
  • devops;
  • Переход на Postgres.

Участие в онлайновой конференции бесплатное. Всем желающим участвовать нужно предварительно зарегистрироваться на сайте, трансляция докладов будет вестись из личных кабинетов. Если уже оплатили PGConf.Russia 2021, то регистрироваться повторно не нужно. Регистрация действительна для обоих событий PGConf.Online и ближайшего PGConf.Russia. Также можно отказаться от участия в PGConf.Russia и вернуть свои деньги. Для этого надо написать на info@pgconf.ru.

Доклады принимаются до 10 февраля в двух форматах: кратком (22 мин + вопросы) и полном (45 мин + вопросы) на русском и английском языках. Также приветствуются мастер-классы с практическими упражнениями и обучающие лекции по вопросам расширенной разработки и DBA. Мастер-классы могут длиться 90 или 180 минут.

На PGConf.Online 2021 возможны доклады как онлайн, так и предварительно записанные, по желанию. Планируется, что даже после записанного выступления докладчик будет онлайн отвечать на вопросы, которые будут собираться в чате модераторами.

Соревнования


PostgreSQL is the DBMS of the Year 2020

СУБД года! Это не рейтинг популярности, а рейтинг роста популярности. Из рейтингов на январь 2021 вычитаются рейтинги за январь 2020. А они вычисляются по методологии экспертов db-engines. По абсолютной, а не дифференциальной популярности postgreSQL по-прежнему на 4-м месте.
О соревновании x86 с ARM в облаках см. далее.

Облака


Тема ARM в облаках набирает обороты. Что не удивительно ARM наступает широким фронтом: суперкомпьютер на ARM взобрался на верхушку Top500; новые попытки Apple; процессор Whitechapel у Google; процессоры от Ampere Computing появятся в облаках Oracle; ну и, конечно, процессоры AWS Graviton2 с ядром Arm Neoverse в исполнении Amazon.

Вот две статьи: в одной Hosting Postgres on an AWS EC2 t4g Graviton2 ARM Instance рассказывается, как запустить и настроить инстансы t4g (но ещё и о выборе EC2 vs RDS); в другой PostgreSQL on ARM-based AWS EC2 Instances: Is It Any Good? исследуется производительность. Об этом чуть подробней: Жобин Аугустин (Jobin Augustine) и Сергей Кузьмичев (Sergey Kuzmichev) из Percona тестировали ARM vs. x86. ARM на инстансах m6gd.8xlarge на базе ARM-процессоров AWS Graviton2. Сам Amazon позиционирует их как обеспечивающий на 40 % лучшее соотношение цены и производительности по сравнению с показателями x86-инстансов M5 в тестах m5d.8xlarge. В обоих инстансах по 32 виртуальных процессора.

Для разминки прогнали на pgbench, ARM выиграл и на Read-Write и на Read-Only в районе 20%. При этом тестировщики не забывали отключать и включать проверку контрольных сумм мало ли что, архитектура разная. Затем перешли к основным перконовским тестам sysbench-tpcc. Размер базы подбирали так, чтобы она умещалась в память. Стали смотреть результаты на числе потоков от 16 до 128. Получилось, что на 16 примерно та же картина, как и на pgbench, а когда потоков больше, чем виртуальных процессоров, игра в ничью. Чтобы уж совсем не огорчать поклонников x86, авторы констатировали худшую производительность у ARM на тестах, оценивающих ввод-вывод. Но и то при 128 потоках. Подробности в статье и на гитхабе.

Теперь информация, связанных с апгрейдом в облаках Amazon:
Ensuring Consistent Performance After Version Upgrades with Amazon Aurora PostgreSQL Query Plan Management

Query Plan Management это расширение apg_plan_mgmt. В статье показано, как после апгрейда кластера Aurora PostgreSQL с 9.6.11 на 10.12 при помощи этого инструмента можно легко проверить, использует ли планировщик одобренный в предыдущей версии план запроса (планы могут получать статус Approved, Rejected, Unapproved, или Preferred).

Кстати, о версиях:
Amazon RDS for PostgreSQL Supports 12.5

RDS теперь поддерживает минорные версии: 12.5, 11.10, 10.15, 9.6.20 и 9.5.24.

Релизы


pgAdmin 4 v4.30

В этой версии появился (пока в статусе бета) новый инструмент: ERD диаграммы сущность-связь, то есть графическая репрезентация таблиц, столбцов и их взаимосвязей. Можно визуализировать уже существующие схемы БД, можно создавать мышью новые, а ERD сгенерит соответствующие SQL. Также появилась поддержка Kerberos.

PostgreSQL-плагин для Zabbix 5.2.4rc1

В новой версии появилась поддержка custom query для плагина PostgreSQL. Теперь можно создать файл .sql и положить его на свою машину. Далее в web-интерфейсе своего Zabbix-сервера в шаблоне для Zabbix-Agent2 находим элемент под названием pgsql.query.custom и в нем указываем макрос, который должен иметь значение имени sql файла с запросом (при этом в конфигурационном файле Zabbix-Agent2 нужно указать путь на машине к папке с sql файлом. И тогда агент сам выполняет запрос в sql файле и пришлет результат на Zabbix-сервер с остальными, дефолтными метриками. Автор плагина Дарья Вилкова, Postgres Professional.

Целая серия новых версий FDW:

sqlite_fdw 1.3.1
InfluxDB fdw 0.3
griddb_fdw 1.3

PostgresNIO 1.0

Это неблокирующий, event-driven клиент для Swift от Vapor, построенный на эппловской SwiftNIO. Этот клиент устанавливает соединение, авторизует и отправляет запрос на сервер, а результат обратно. Использует протокол PostgreSQL. Умеет создавать пул соединений. И ещё есть пакеты более высокого уровня поверх PostgresNIO postgres-kit.

PGMoon 12.0-1

pgmoon это клиентская библиотека, написанная на чистом Lua (MoonScript). pgmoon с самого начала была разработана для использования в OpenResty web-платформе на базе докрученного Nginx), чтобы можно было пользоваться API 100% неблокирующих cosockets для асинхронных запросов.

Ещё статьи


Расширение кластера PostgreSQL размером 5,7 ТБ и переход с версии 9.6 на 12.4

Статья в блоге Альфа-Банка, автор оригинала Томми Ли (Tommy Li, Coffee Meets Bagel приложение для романтических знакомств с системой курирования).

Базы работали на 6 серверах Postgres на инстансах i3.8xlarge в амазоновском облаке: одна главная нода, три реплики для раздачи веб-трафика только для чтения, балансируемые с помощью HAProxy, один сервер для асинхронных воркеров и один сервер для ETL (Extract, Transform, Load) и Business Intelligence. Для поддержания реплик в актуальном состоянии использовалась потоковая репликация.

Надо было одновременно проапгрейдить Postgres и перейти с i3.8xlarge на i3.16xlarge при минимальной суммарной остановке 4 ч. (а вышло полчаса). Для миграции использовали pglogical. Также в статье из этого опыта извлекли уроки. Эта статья вызвала справедливые и несправедливые замечания в комментариях. Так что примечателен не только сам случай, но и реакция на него, да и тот факт, что перевод статьи появился не где-нибудь, а на хабр-блоге Альфа-Банка (до этого там о базах данных ничего, кажется, не было).

PostgreSQL Scaling Advice For 2021

Каарел Моппел (Kaarel Moppel, Cybertec), чьи статьи регулярно попадают в наши обзоры, дерзнул дать советы тем, кто озабочен будущим масштабированием своих систем. Каарел признаётся, что воодушевился роликом Distributed MySQL Architectures Past, Present, Future Петра Зайцева, основателя и гендира Percona, и приложил (так как, по его, Каарела, словам, MySQL и Postgres суть сводные братья) некоторые выводы Петра к родной PostgreSQL и добавил собственные.

Итого: что даёт обычный Postgres?
  • один инстанс PostgreSQL легко выполняет сотни тысяч транзакций в секунду;
  • одна нода обычно выполняет десятки тысяч пишущих транзакций в секунду;
  • один инстанс Postgres легко справляется с десятками ТБ данных;
  • один инстанс на одной ноде даёт буквально пуленепробиваемую надёжность при должной заботе о согласованности данных;
  • в причинах сбоев легко разобраться, поэтому данные можно восстановить.


О чём не стоит забывать, когда озаботился масштабированием?
  • не бойтесь заводить свои собственные (а не поддерживаемые в облаке) базы данных;
  • старайтесь избегать архитектуры данных, у которой в основе одна большая таблица;
  • убедитесь, что вы выбрали подходящий ключ разбиения при шардинге вашей таблицы/базы.


Агрегаты в БД

Кирилл Боровиков aka Kilor (компания Тензор) на этот раз обратился к агрегатам. Это мини-серия из двух статей: Агрегаты в БД зачем, как, а стоит ли? и продолжение Агрегаты в БД эффективная обработка потока фактов. В первой движение мысли от count(*) к подсчетам с парсингом EXPLAIN, к сбору агрегатов в отдельную таблицу, к хранению временных агрегатов в памяти процесса и даже к хранению их вообще в другой СУБД.

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

Образование


Чёрная Малютка

Вышла новая версия знаменитой книжки-малышки
Postgres: первое знакомство.



Книжечка проапгрейдилась до версии PostgreSQL 13. В бумажном виде она, как и раньше, будет раздаваться на конференциях, которые проходят с участием Postgres Professional. PDF можно скачать.

DEV2: Разработка серверной части приложений PostgreSQL 12. Расширенный курс.

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

Митапы и подкасты


Постгрес-вторник с Петром Зайцевым

Петра Зайцева, основателя Percona, Николай Самохвалов и Илья Космодемьянский зазывали на свои Вторники целый год. Свершилось. Был разговор о компании (из которого выяснилось, что сейчас в компании около 300 сотрудников, из них человек 50 постгресистов); о причинах дрейфа компании от MySQL и MongoDB в сторону PostgreSQL (не по любви, и не из-за технологических причин, а просто в это сторону двигались клиенты и потенциальные клиенты); о разной атмосфере в комьюнити MySQL, MongoBD и PostgreSQL (второе самое монополистическое, а третье самое открытое). Но гвоздь программы перконовская утилита мониторинга pg_stat_monitor.

Монитор опирается на расширении pg_stat_statements, но добавляет некоторую функциональность. Можно, например, посмотреть тексты запросов, отбирающих много ресурсов, сравнить прожорливость одного и того же запроса с разными планами; монитор знает название приложения, отправившего запрос. В этом контексте возник и разговор о новом расширении PWR (pgpro_pwr), вошедшем в Postgres Pro Standard и Enterprise 13. Это, кажется, обсудят на следующем Вторнике (мы же обещали статью о нём и обещание скоро сдержим).
Подробнее..

PostgreSQL 14 Часть 4 или январское наступление (Коммитфест 2021-01)

08.02.2021 00:09:10 | Автор: admin
PostgreSQL 14 наступает! После первых трех относительно скромных коммитфестов (июльский, сентябрьский, ноябрьский) пошли крупные изменения.

Вот только несколько вопросов для затравки:

  • Могут ли диапазоны содержать пропуски значений?
  • Зачем нужна индексная нотация типу json?
  • Может ли индекс при частых обновлениях разрастаться меньше, чем таблица? А вообще не разрастаться?
  • Сколько времени простаивали сеансы в idle_in_transaction?
  • Как построить ER-диаграмму для таблиц системного каталога?


Клиентские приложения


psql: \dX просмотр расширенной статистики
commit: ad600bba

Новая команда \dX показывает объекты расширенной статистики в виде списка.

CREATE STATISTICS flights_from_to (dependencies, MCV)     ON departure_airport, arrival_airport     FROM flights;\x\dX
List of extended statistics-[ RECORD 1 ]+------------------------------------------------Schema       | bookingsName         | flights_from_toDefinition   | departure_airport, arrival_airport FROM flightsNdistinct    |Dependencies | definedMCV          | defined

Для каждого типа статистики (Dependencies, Ndistinct, MCV) отображается только факт сбора. Сами значения нужно смотреть в pg_statistic_ext_data, доступ к которой по умолчанию только у суперпользователей.

psql: \dtS показывает таблицы TOAST
commit: 7d80441d

Отдельную таблицу TOAST и раньше можно было посмотреть командой \d. Однако получить список таких таблиц командой \dt или \dtS было нельзя. Упущение исправлено, \dtS теперь показывает таблицы TOAST, поскольку они являются служебными.

Но есть один нюанс. Все таблицы TOAST расположены в схеме pg_toast, а эта схема вряд ли включена в search_path. Поэтому для получения списка требуется указать соответствующий шаблон:

\dtS pg_toast.*165*
                 List of relations  Schema  |      Name      |    Type     |  Owner   ----------+----------------+-------------+---------- pg_toast | pg_toast_16529 | TOAST table | postgres pg_toast | pg_toast_16539 | TOAST table | postgres pg_toast | pg_toast_16580 | TOAST table | postgres

Автодополнение по табуляции в psql улучшено для команд: CLOSE, FETCH, MOVE и DECLARE
commit: 3f238b88

Дополнительное описание не требуется.

Документация


Вычитка и редактирование документации
commit: 2a5862f0

Многие отмечают, что у PostgreSQL прекрасная документация. А ведь её пишут сами разработчики, которые обычно не считаются мастерами пера. Как же удается поддерживать высокое качество? Всё просто. Как и в любом писательском деле нужны редакторы и корректоры. И вот Джастин Призби последние два года делает огромную и важную работу: вычитывает документацию. В результате появился большой список корректур из 18 патчей. А Микаэль Пакье, как коммитер, помогал ему.

И это лишь один, крупный коммит. А количество небольших патчей улучшающих документацию просто не перечесть.

Разное


Параметр idle_session_timeout принудительное завершение простаивающих сеансов
commit: 9877374b

Новый параметр idle_session_timeout задает таймаут бездействия сеансов. При превышения установленного лимита времени, сеанс будет прерван. Параметр очень похож на появившийся еще в 9.6 idle_in_transaction_session_timeout, но действует только на сеансы, в которых нет начатой транзакции. Поэтому если требуется прерывать бездействующие сеансы вне зависимости от того, начата в них транзакция или нет, то следует установить оба параметра.

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

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

SET idle_session_timeout = '1000ms';-- пауза\! tail -n 1 logfile
2021-02-01 12:25:06.716 MSK [5262] FATAL:  terminating connection due to idle-session timeout
SHOW idle_session_timeout;
FATAL:  terminating connection due to idle-session timeoutserver closed the connection unexpectedly    This probably means the server terminated abnormally    before or while processing the request.The connection to the server was lost. Attempting reset: Succeeded.
SHOW idle_session_timeout;
 idle_session_timeout---------------------- 0

Описание от depesz.

Информация о GSS в сообщении журнала сервера
commit: dc11f31a

Сообщение о подключении нового сеанса в журнале сервера дополнено информацией о GSS, если использовался этот метод аутентификации.

pageinspect: функции для индексов GiST
commit: 756ab291

Для всех кому интересно исследовать организацию и хранение индексов GiST расширение pageinspect предлагает новые функции.

Корректное поведение EXPLAIN в командах с IF NOT EXISTS
commit: e665769e

Попытка создать уже существующую таблицу с опцией IF NOT EXISTS приводит к выдаче предупреждения:

CREATE TABLE IF NOT EXISTS tickets AS SELECT * FROM bookings;
NOTICE:  relation "tickets" already exists, skipping

Однако получение плана такой команды приводит к неожиданным результатам. Просто EXPLAIN выводит план для SELECT, который команда успевает построить до того, как будет проверять существование таблицы tickets. И никаких предупреждений!

EXPLAIN CREATE TABLE IF NOT EXISTS tickets AS SELECT * FROM bookings;
                           QUERY PLAN                            ----------------------------------------------------------------- Seq Scan on bookings  (cost=0.00..4301.88 rows=262788 width=21)

А EXPLAIN ANALYZE завершается ошибкой вместо предупреждения:

EXPLAIN ANALYZE CREATE TABLE IF NOT EXISTS tickets AS SELECT * FROM bookings;
ERROR:  relation "tickets" already exists

В 14 версии поведение стало предсказуемым:

EXPLAIN CREATE TABLE IF NOT EXISTS tickets AS SELECT * FROM bookings;
NOTICE:  relation "tickets" already exists, skipping QUERY PLAN------------(0 rows)
EXPLAIN ANALYZE CREATE TABLE IF NOT EXISTS tickets AS SELECT * FROM bookings;
NOTICE:  relation "tickets" already exists, skipping QUERY PLAN------------(0 rows)

Такие же изменения для команды EXPLAIN [ANALYZE] CREATE MATERIALIZED VIEW IF NOT EXISTS.

Добавлены первичные и уникальные ключи в таблицы системного каталога
commit: dfb75e47, 62f34097

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

Вот как это выглядит:

\d pg_class
                     Table "pg_catalog.pg_class"       Column        |     Type     | Collation | Nullable | Default---------------------+--------------+-----------+----------+--------- oid                 | oid          |           | not null | relname             | name         |           | not null | relnamespace        | oid          |           | not null |...пропущено ...Indexes:    "pg_class_oid_index" PRIMARY KEY, btree (oid)    "pg_class_relname_nsp_index" UNIQUE CONSTRAINT, btree (relname, relnamespace)    "pg_class_tblspc_relfilenode_index" btree (reltablespace, relfilenode)

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

А вот внешние ключи не добавили. На то есть веские причины:

  • У ряда таблиц столбцы oid могут иметь значения 0, когда нет реального OID, на который можно ссылаться. Для создания внешнего ключа потребуется заменить везде 0 на NULL, а это огромная работа по переписыванию кода, за которую не готовы браться.
  • У ряда таблиц столбец с потенциальным внешним ключом не просто типа oid, а oid[]. Создать внешний ключ по массиву невозможно.

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

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

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

SELECT fktable, fkcols, is_array, is_optFROM   pg_get_catalog_foreign_keys()WHERE  pktable = 'pg_attribute'::regclassAND    pkcols = ARRAY['attrelid','attnum'];
       fktable        |        fkcols         | is_array | is_opt----------------------+-----------------------+----------+-------- pg_attrdef           | {adrelid,adnum}       | f        | f pg_constraint        | {conrelid,conkey}     | t        | t pg_constraint        | {confrelid,confkey}   | t        | f pg_index             | {indrelid,indkey}     | t        | t pg_statistic_ext     | {stxrelid,stxkeys}    | t        | f pg_statistic         | {starelid,staattnum}  | f        | f pg_trigger           | {tgrelid,tgattr}      | t        | f pg_partitioned_table | {partrelid,partattrs} | t        | t(8 rows)

Мониторинг


Параметр log_recovery_conflict_waits запись в журнал долгих ожиданий разрешения конфликтов восстановления
commit: 0650ff23

При включенном новом параметре log_recovery_conflict_waits, ожидание разрешения конфликта восстановления процессом startup будет записано в журнал сервера, если время ожидания превысит deadlock_timeout.

Смоделируем ситуацию. На реплике включаем параметр, затем начинаем транзакцию и ждем:

ALTER SYSTEM SET log_recovery_conflict_waits = on;SELECT pg_reload_conf();BEGIN ISOLATION LEVEL REPEATABLE READ;SELECT count(*) FROM t;

А теперь на мастере:

DELETE FROM t;VACUUM t;

Через секунду (deadlock_timeout) в журнале реплики появится детальное сообщение с описанием конфликта. Здесь и номер конфликтующего процесса, и позиция LSN где застряли, и имя файла(читай таблицы) с номером блока:

LOG:  recovery still waiting after 1023.267 ms: recovery conflict on snapshotDETAIL:  Conflicting process: 29119.CONTEXT:  WAL redo at 0/1001BEB0 for Heap2/CLEAN: latestRemovedXid 717; blkref #0: rel 1663/16384/17198, blk 0

Еще через 30 секунд ожидания (max_standby_streaming_delay) сеанс на реплике будет прерван, как и полагается в таких случаях.

Это продолжение работы, начатой и описанной в предыдущем коммитфесте.

Представление pg_stat_database добавлена статистика о пользовательских сеансах
commit: 960869da

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

В pg_stat_database появилось много столбцов с дополнительной информации о сеансах пользователей в каждой базе данных кластера:

  • session_time общее время всех сеансов, проведенной в этой БД;
  • active_time время, потраченное на выполнение запросов;
  • idle_in_transaction_time время простоя в незавершенных транзакциях;
  • sessions количество сеансов;
  • sessions_abandoned количество прерванных сеансов из-за потери соединения;
  • sessions_fatal количество прерванных сеансов из-за ошибки уровня FATAL;
  • sessions_killed количество прерванных сеансов по инициативе пользователя.

Описание от depesz.

ps: обновление статуса процессов при выполнении контрольной точки
commit: df9274ad

Следить за работой процессов startup, checkpointer можно запросами к pg_stat_activity. Но есть три ситуации, когда представление pg_stat_activity не доступно, а checkpointer работает. Речь о контрольной точке в конце процесса восстановления после сбоя, контрольной точке во время остановки сервера и о точке рестарта во время остановки реплики.

В этих трех ситуаций можно следить за статусом процессов startup и checkpointer в операционной системе, например утилитой ps.

Типичный пример восстановление после сбоя. В конце, после наката изменений из WAL, процесс startup выполняет контрольную точку и это может занять некоторое время. Однако статус процесса startup не меняется и показывает recovering NNN. Хотя было бы полезно знать, что накат изменений завершен и осталось дождаться завершения контрольной точки. Теперь статус обновляется, понижая уровень тревоги DBA в экстремальной ситуации.

pg_stat_statements: когда была сброшена статистика
commit: 2e0fedf0

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

Но как узнать, когда статистика была последний раз сброшена? Очень просто. Заглядываем в pg_stat_statements_info:

SELECT now(), pg_stat_statements_reset();
              now              | pg_stat_statements_reset-------------------------------+-------------------------- 2021-02-03 13:25:44.738188+03 |
SELECT * FROM pg_stat_statements_info;
 dealloc |          stats_reset          ---------+-------------------------------       0 | 2021-02-03 13:25:44.738468+03

Представление pg_stat_statements_info появилось именно в 14 версии. Про столбец dealloc можно прочитать в предыдущей статье.

Описание от depesz.

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

Ход выполнения команды COPY
commit: 8a4f618e

В семействе представлений pg_stat_progress_* пополнение! Теперь можно наблюдать за прогрессом выполнения команды COPY.

Сделаем логическую копию демо-базы:

\! pg_dump -d demo -Fc -f demo.dump

Теперь развернем копию в базе данных postgres в два потока и, пока процесс идет, заглянем в представление pg_stat_progress_copy:

\! pg_restore tickets.dump -d postgres -j 2 &SELECT pid, datname, relid::regclass, bytes_processed, bytes_total, lines_processedFROM   pg_stat_progress_copy\gx
-[ RECORD 1 ]---+-------------------------pid             | 18771datname         | postgresrelid           | bookings.ticketsbytes_processed | 19088527bytes_total     | 0lines_processed | 189820-[ RECORD 2 ]---+-------------------------pid             | 18772datname         | postgresrelid           | bookings.boarding_passesbytes_processed | 14833287bytes_total     | 0lines_processed | 567652

Столбец bytes_total был бы заполнен размером файла при выполнении команды COPY FROM 'file'. Но в приведенном примере загрузка идет из копии pg_dump, поэтому размер не известен.

Статус можно отслеживать не только для загрузки (COPY FROM), но и для выгрузки (COPY TO) данных.

Описание от depesz.

Производительность


Оптимизация очистки буферного кеша
commit: d6ad34f3, bea449c6

Ряд операций требуют удаления из буферного кеша всех буферов, относящихся к определенной таблице. К таким операциям относятся команды TRUNCATE и DROP таблицы, прерванная команда CREATE TABLE AS SELECT, а также VACUUM, когда требуется удалить пустые блоки из конца таблицы.

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

Тестирование показало, что при shared_buffers от 100GB опустошение (truncate) тысячи таблиц ускорилось более чем в 100 раз.

Это продолжение работы, начатой в 13 версии.

postgres_fdw: пакетный режим для вставки записей
commit: b663a413

Выборка данных из внешних таблиц postgres_fdw использует пакетный режим. Записи передаются с внешнего сервера пачками по 100 штук (значение параметра fetch_size по умолчанию). Это существенно быстрее, чем передавать их каждый раз по одной. А вот вставка, изменение, удаление работают построчно. И потому очень медленно.

Для оптимизации было доработано FDW API. Правда доработано только в части пакетного режима для операций вставки. Обновления и удаления оставлены на будущее. Разумеется, первой оберткой, которая воспользовалась новым API, стала postgres_fdw.

Посмотрим что получилось. Настраиваем postgres_fdw для работы с внешними таблицами в базе данных demo:

CREATE EXTENSION postgres_fdw;CREATE SERVER remote_server    FOREIGN DATA WRAPPER postgres_fdw    OPTIONS (dbname 'postgres');CREATE USER MAPPING FOR postgres    SERVER remote_server    OPTIONS (user 'postgres');

Внешняя таблица будет располагаться в соседней базе postgres:

postgres=# CREATE TABLE bookings(    book_ref char(6),book_date timestamptz, total_amount numeric(10,2));

За эталонную скорость возьмем скорость вставки в локальную таблицу. И включим timing для замеров:

CREATE TABLE bookings_local (LIKE bookings);\timing

Вставка в локальную таблицу:

INSERT INTO bookings_local SELECT * FROM bookings;
INSERT 0 262788Time: 165,653 ms

А теперь вставка во внешнюю таблицу, пакетный режим отключен. (На самом деле он включен, просто по умолчанию размер пакета 1 строка).

CREATE FOREIGN TABLE bookings_remote_no_batch (    book_ref char(6), book_date timestamptz, total_amount numeric(10,2)) SERVER remote_server OPTIONS (    schema_name 'public', table_name 'bookings');INSERT INTO bookings_remote_no_batch SELECT * FROM bookings;
INSERT 0 262788Time: 6729,867 ms (00:06,730)

Почти в 40 раз медленнее! И это между базами одного кластера, где нет сетевых задержек.

Повторим эксперимент, но установим размера пакета(batch_size) равным 100.

CREATE FOREIGN TABLE bookings_remote_batch_100 (    book_ref char(6), book_date timestamptz, total_amount numeric(10,2)) SERVER remote_server OPTIONS (    schema_name 'public', table_name 'bookings',    batch_size '100');INSERT INTO bookings_remote_batch_100 SELECT * FROM bookings;
INSERT 0 262788Time: 679,632 ms

Совсем другое дело. Конечно, проигрыш локальной вставке по-прежнему заметен, ~4 раза, но всё-таки не 40!

И напоследок. Размер пакета для вставки (batch_size) можно было задать и в параметрах внешнего сервера, тогда он бы действовал для всех таблиц, в которых не определен явно.

Удаление индексных строк снизу вверх
commit: 9dc718bd, d168b666

Данная оптимизация пытается до последнего избежать деления индексной страницы на две при операциях UPDATE в ситуациях, когда столбцы индекса не менялись. Прежде чем добавлять новую версию строки в индекс, нужно посмотреть, а нельзя ли удалить на этой странице уже не нужные строки. Например, если найдена цепочка ненужных дублирующихся индексных строк, ссылающихся на одну табличную строку, то эти строки можно удалить. Питер Гейган, автор патча, назвал это удалением снизу вверх (bottom-up deletion).

Похожую задачу (избежать разрастания индексов) решает оптимизация HOT-обновление. Если UPDATE не изменяет ни один из индексированных столбцов, то новые версии строк в индексах могут не создаваться. А если индексов на таблице несколько, а изменяется столбец только одного из них? В таком случае HOT-обновление не помощник.

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

CREATE TABLE t(col1 int, col2 int) WITH (autovacuum_enabled=off);CREATE INDEX t_col1 ON t(col1);CREATE INDEX t_col2 ON t(col2);INSERT INTO t VALUES (1, 1);SELECT pg_relation_size('t') AS t_size,       pg_relation_size('t_col1') AS t_col1_size,       pg_relation_size('t_col2') AS t_col2_size;
 t_size | t_col1_size | t_col2_size--------+-------------+-------------   8192 |       16384 |       16384

Перед массовым обновлением в таблице одна строка. Размер таблицы одна страница, а оба индекса занимают по две страницы (служебная страница + страница с данными).

Теперь 100000 раз изменяем только один столбец col2 и смотрим размер таблицы и индексов.

SELECT 'UPDATE t SET col2 = col2+1' FROM generate_series(1,100000)\gexecSELECT pg_relation_size('t') AS t_size,       pg_relation_size('t_col1') AS t_col1_size,       pg_relation_size('t_col2') AS t_col2_size;
 t_size  | t_col1_size | t_col2_size---------+-------------+------------- 2818048 |     2121728 |     2260992

Эти результаты получены в PostgreSQL 12. Как видим, HOT-обновление не сработало и оба индекса почти одинаково выросли в размерах.

Теперь этот же эксперимент в PostgreSQL 13:

 t_size  | t_col1_size | t_col2_size---------+-------------+------------- 2818048 |      663552 |     2260992

Индекс t_col1, в котором не было изменений, вырос намного меньше, в ~3,5 раза. Это результат известной оптимизации 13 версии: дедупликация индексов. Но тем не менее вырос.

И, наконец, смотрим что в PostgreSQL 14:

 t_size  | t_col1_size | t_col2_size---------+-------------+------------- 2818048 |       16384 |     2260992

Вот это да! В индексе t_col1 так и осталась всего одна страница с данными. Это круто!

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

Описание от Виктора Егорова.

Параллельное выполнение REINDEX CONCURRENTLY
commit: f9900df5

В статье о ноябрьском коммитфесте уже писалось о неблокирующем параллельном выполнении CREATE INDEX CONCURRENTLY. Аналогичная оптимизация теперь и для REINDEX CONCURRENTLY.

Процедурные языки


Процедуры стали выполняться быстрее
commit: ee895a65

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

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

PL/pgSQL: оператор присваивания полностью переработан
commit: 844fe9f1, c9d52984, 1788828d, 1c1cbe27

Без лишних слов:

DO $$<<local>>DECLARE    a bookings[];    x bookings;BEGIN    /* Присвоение элементу массива составного типа */    local.a[1].book_ref := 'ABCDEF';        local.a[1].book_date := current_date;        local.a[1].total_amount := 0;        /* Присвоение срезу массива */    local.a[2:3] := (SELECT array_agg(t.*)                        FROM  (SELECT b.* FROM bookings b LIMIT 2) AS t                       );    FOREACH x IN ARRAY a LOOP            RAISE NOTICE '%', x;    END LOOP;END;$$;
NOTICE:  (ABCDEF,"2021-02-04 00:00:00+03",0.00)NOTICE:  (00000F,"2017-07-05 03:12:00+03",265700.00)NOTICE:  (000012,"2017-07-14 09:02:00+03",37900.00)DO

Теперь внутри PL/pgSQL блока можно присваивать значения элементам массива составного типа, а также срезам массива.

Для этого оператор присваивания в PL/pgSQL был полностью переработан. А парсер сервера научился разбирать выражения PL/pgSQL.

Для вычисления выражения больше не нужно формировать команду вида SELECT expr. В этом легко убедиться посмотрев на сообщение об ошибке в следующем примере:

DO $$ BEGIN RAISE NOTICE '%', 2 + 'a'; END; $$;
ERROR:  invalid input syntax for type integer: "a"LINE 1: 2 + 'a'            ^QUERY:  2 + 'a'CONTEXT:  PL/pgSQL function inline_code_block line 1 at RAISE

Слова SELECT в строке QUERY больше нет.

Репликация


Обработка репликой изменения параметров конфигурации на мастере
commit: 15251c0a

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

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

Изменение restore_command без перезапуска сервера
commit: 942305a3

Продолжение работы Сергея Корнилова, принятой в 13 версию. Тогда появилась возможность изменять без перезагрузки сервера параметры primary_conninfo, primary_slot_name и wal_receiver_create_temp_slot.

Теперь к ним добавился restore_command.

Сервер


Улучшение использования расширенной статистики
commit: 25a9e54d

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

В примере соберем расширенную статистику по аэропортам вылета и прилета. А затем посчитаем количество рейсов между Шереметьево и Пулково или в обратном направлении.

CREATE STATISTICS s ON departure_airport, arrival_airport FROM flights;ANALYZE flights;

Точное количество рейсов 610. Сравним с оценками планировщика в 13 и 14 версиях.

EXPLAIN SELECT *FROM   flightsWHERE (departure_airport = 'SVO' AND arrival_airport = 'LED')OR    (departure_airport = 'LED' AND arrival_airport = 'SVO');

PostgreSQL 13:

 Seq Scan on flights  (cost=0.00..1054.42 rows=885 width=63)

PostgreSQL 14:

 Seq Scan on flights  (cost=0.00..1054.42 rows=607 width=63)

Как видим оценка в 14 версии практически точная.

Общая инфраструктура поддержки индексной нотации для любых типов данных
commit: c7aba7c1, 0ec5f7e7, 676887a3

Индексная нотация используется для работы с массивами. Например найдем элемент с индексом 3:

SELECT (ARRAY[10,20,30,40,50])[3];
 array-------    30

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

И вот спустя несколько лет такая поддержка появилась. Первый патч создает необходимую инфраструктуру индексных нотации для произвольных типов данных. Второй патч добавляет индексную нотацию к типу hstore, а третий к типу jsonb.

Теперь вместо специальных функций и операторов можно извлекать необходимые части из json-значения. Найдем телефон в контактных данных одного из билетов:

SELECT contact_data, contact_data['phone'] AS phoneFROM   ticketsWHERE  ticket_no = '0005432000994'\gx
-[ RECORD 1 ]+-----------------------------------------------------------------------------------------------------------------------------------------------------------contact_data | {"email": "antonova.irina04121972@postgrespro.ru", "phone": "+70844502960"}phone        | "+70844502960"

Индексная нотация может использоваться и для записи в jsonb. Добавим в ранее найденный контакт Ирины Антоновой еще и адрес:

UPDATE ticketsSET    contact_data['address'] =           '{"city": "Москва",             "street": "Дмитрия Ульянова",             "building": "7А"            }'::jsonbWHERE ticket_no = '0005432000994';

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

SELECT contact_data['address'] AS address,       contact_data['address']['city'] AS city,       contact_data['address']['street'] AS street,       contact_data['address']['building'] AS building,       contact_data['phone'] AS phone,       contact_data['email'] AS emailFROM   ticketsWHERE  ticket_no = '0005432000994'\gx
-[ RECORD 1 ]----------------------------------------------------------------address  | {"city": "Москва", "street": "Дмитрия Ульянова", "building": "7А"}city     | "Москва"street   | "Дмитрия Ульянова"building | "7А"phone    | "+70844502960"email    | "antonova.irina04121972@postgrespro.ru"

Это очень удобно!

(Уточнение. Все контакты в демо-базе вымышленные и в Постгрес Про нет такой сотрудницы.)

Описание для hstore от depesz.

Команды SQL


Мультидиапазонные типы данных
commit: 6df7a969

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

Обычные диапазоны представляют собой непрерывные интервалы значений соответствующего подтипа: диапазон типа in4range для подтипа int, диапазон типа timestamptz для подтипа timestamp, и т.д. Но что, если нужно хранить диапазоны с пропусками в некоторых местах? Вот тут приходят на помощь мультидиапазоны.

Допустим мы хотим хранить в таблице периоды времени проведения коммитфестов для каждой версии PostgreSQL. Отдельный коммитфест можно представить в виде диапазона длиной в месяц. А вот как представить все пять коммитфестов одной версии?

Диапазон для подтипа timestamptz называется tstzrange, а мультидиапазон tstzmultirange. Имеющиеся типы описаны в документации. Создаем таблицу:

CREATE TABLE pg_commitfest (    version text,    working_period tstzmultirange);

Для формирования значений используем конструктор:

INSERT INTO pg_commitfest VALUES('13', tstzmultirange(           tstzrange('2019-07-01', '2019-08-01', '[)'),           tstzrange('2019-09-01', '2019-10-01', '[)'),           tstzrange('2019-11-01', '2019-12-01', '[)'),           tstzrange('2020-01-01', '2020-02-01', '[)'),           tstzrange('2020-03-01', '2020-04-07', '[]')       )),('14', tstzmultirange(           tstzrange('2020-07-01', '2020-08-01', '[)'),           tstzrange('2020-09-01', '2020-10-01', '[)'),           tstzrange('2020-11-01', '2020-12-01', '[)'),           tstzrange('2021-01-01', '2021-02-01', '[)'),           tstzrange('2021-03-01', '2021-04-01', '[)')       ));

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

Например, можем узнать, над какой версией PostgreSQL работало сообщество разработчиков в прошедший Новый год:

SELECT version FROM   pg_commitfestWHERE  working_period @> '2021-01-01'::timestamptz;
 version--------- 14

Или даты начала и конца работы над 13 версией:

SELECT lower(working_period), upper(working_period) FROM   pg_commitfestWHERE  version = '13';
         lower          |         upper          ------------------------+------------------------ 2019-07-01 00:00:00+03 | 2020-04-07 00:00:00+03

Можно создавать новые пользовательские мультидиапазонные типы. Это полезно в тех случаях, когда встроенного диапазонного и соответствующего ему мультидиапазонного типа нет. Используется та же команда CREATE TYPE AS RANGE, в которой можно указать имя и для автоматически создаваемого мультидиапазонного типа.

Например нас интересуют диапазоны и мультидиапазоны времени, подтип time. Для создания диапазона понадобится функция, вычисляющая разницу между двумя значениями типа time:

CREATE FUNCTION time_diff(a time, b time) RETURNS double precisionAS $$    SELECT extract(epoch FROM (a - b));$$ LANGUAGE sql STRICT IMMUTABLE;

Создаем тип для диапазона времени, а заодно и для мультидиапазона:

CREATE TYPE timerange AS RANGE (    subtype = time,    subtype_diff = time_diff,    multirange_type_name = timemultirange);

Теперь рабочее время можно сформировать следующим выражением:

SELECT timemultirange(           timerange('09:00', '13:00', '[)'),           timerange('14:00', '18:00', '[)')       ) AS working_hours;
               working_hours               ------------------------------------------- {[09:00:00,13:00:00),[14:00:00,18:00:00)}

Описание от depesz.

Функции ltrim и rtrim для двоичных строк
commit: a6cf3df4

Обрезать одновременно байты в начале и конце строки bytea можно было и раньше функцией btrim. Теперь обрезать можно с каждого края по отдельности новыми функциями ltrim и rtrim для двоичных строк.

Фраза GRANTED BY в командах GRANT и REVOKE
commit: 6aaaa76b

Для совместимости со стандартом SQL в команды GRANT и REVOKE добавлена необязательная фраза GRANTED BY. Например:

GRANT ALL ON TABLE table_name TO role_specification     [GRANTED BY role_specification];REVOKE ALL ON TABLE table_name FROM role_specification     [GRANTED BY role_specification];

Имя роли в GRANTED BY должно совпадать с текущей ролью. Так что выдать/отобрать права от имени другой роли не получится. Фраза добавлена в целях соответствия стандарту.

Это продолжение работы, описанной в статье о сентябрьском коммитфесте.

Системное администрирование


initdb --no-instructions
commit: e09155bd

Утилита initdb используется для инициализации кластера. И в конце своей работы выводит инструкцию как кластер запускать:

Success. You can now start the database server using:    pg_ctl -D /usr/local/pgsql/data -l logfile start

Вот только это не всегда верно. Например в пакетных дистрибутивах debian для запуска кластера предназначена утилита pg_ctlcluster, а не pg_ctl. И параметры у неё другие.

С новым параметром --no-instructions утилита initdb перестанет давать советы по запуску, чем пакетные дистрибутивы могут воспользоваться.

pg_dump: восстановление отдельной секции в качестве самостоятельной таблицы
commit: 9a4c0e36, 9eabfe30

Если в логическую копию pg_dump включена секционированная таблица, то восстановить из такой копии отдельную секцию как самостоятельную таблицу не получится. Сразу за командой CREATE TABLE идет команда ALTER TABLE ATTACH PARTITION, которая не только не нужна в такой ситуации, но и завершается ошибкой, т.к. родительскую таблицу мы не восстанавливали.

CREATE TABLE t (id int) PARTITION BY RANGE(id);CREATE TABLE t_p1 PARTITION OF t FOR VALUES FROM (1) TO (1001);CREATE TABLE t_p2 PARTITION OF t FOR VALUES FROM (1001) TO (2001);\! pg_dump -Fc -f db.dump\! pg_restore db.dump -t t_p1 -f -
...CREATE TABLE public.t_p1 (    id integer);ALTER TABLE ONLY public.t ATTACH PARTITION public.t_p1 FOR VALUES FROM (1) TO (1001);...

Теперь команды ALTER TABLE ATTACH PARTITION для всех секций выгружаются отдельно и после всех команд на создание секций CREATE TABLE. Поэтому при восстановление отдельной секции, указанной в опции -t, будет выполняться только команда CREATE TABLE, что дает возможность восстановить секцию как самостоятельную таблицу.



На этом пока всё. Ждем финальный мартовский коммитфест 14-й версии.
Подробнее..

Постгрессо 29

28.02.2021 18:05:07 | Автор: admin

Мы продолжаем знакомить вас с самыми интересными новостями PostgreSQL.

Конференция PGConf.Online 2021


Она начинается уже 1-го марта и закончится 3-го. О ней подробно написано в статье Ивана Панченко, зам. гендира Postgres Professional.

На этой конференции (которая не вместо, а кроме офлайновой, теплой-ламповой, она ожидается в конце весны) будет рекордное число иностранных гостей чему явно поспособствовал онлайн-формат. В том числе на этот раз поучаствует и Саймон Риггс (Simon Riggs). Доклады в 3 потока с 10 утра до 6 вечера. А также мастер-классы.

Статьи


PostgreSQL 14: Часть 4 или январское наступление (Коммитфест 2021-01)

Очередной must read Павла Лузанова. Крупные изменения после первых трех относительно скромных коммитфестов (июльский, сентябрьский, ноябрьский).

Вопросы для затравки, предложенные Павлом:

  • Могут ли диапазоны содержать пропуски значений?
  • Зачем нужна индексная нотация типу json?
  • Может ли индекс при частых обновлениях разрастаться меньше, чем таблица? А вообще не разрастаться?
  • Сколько времени простаивали сеансы в idle_in_transaction?
  • Как построить ER-диаграмму для таблиц системного каталога?


Deep PostgreSQL Thoughts: The Linux Assassin

Слово deep уже пугает: не про ИИ ли это. Но нет. Джо Конвей (Joe Conway, Crunchy Data) действительно копает вглубь. Даже не Постгреса, не своего же расширения plr. На этот раз тема Жуткий Убийца, являющийся из недр Linux OOM Killer.

Джо начинает с истории: первые дискуссии в Postgres-сообществе и первые патчи в 2003-м году как заставить киллера работать по понятиям Postgres. Далее Джо поясняет отношения киллера и Postgres на уровне хоста (oom_score и oom_score_adj) и на уровне CGroup, поясняет, почему так важно не допустить прихода киллера.

И дальше Джо Конвей переходит к специфическим проблемам OOM Killer в Kubernetes это, видимо, и был главный повод для написания этой статьи. Оказывается, что там, в K8s, разрушительная деятельность киллера может начаться даже при относительно благополучном состоянии памяти. В K8s своп по умолчанию выключен. До этого момента автор не трогал тему свопа, которая, вообще-то, очень даже обсуждается среди постгресистов-практиков.

Джо ссылается на обстоятельную статью Криса Дауна (Chris Down) In defence of swap: common misconceptions, причём есть и русский перевод (не автопереводчиком): В защиту свопа: распространенные заблуждения. О Postgres там нет речи, но может заинтересовать и постгресистов.

Также ссылается он на статью The weird interactions of cgroups and linux page cache in hypervisor environments в блоге компании StorPool, где в команде в основном болгарские фамилии.

Далее Джо Конвей плавно переходит к разработкам и усилиям Crunchy Data в треугольнике PostgreSQL Kubernetes ядро Linux.

??
Акула жуёт гугловый кабель (The Guardian??)

Things I Wished More Developers Knew About Databases

Статья не (только) о Postgres. Иногда полезно ещё разок глянуть на разные СУБД с птичьего полёта. Вот внушительный список тем, о которых стоит помнить разработчикам приложений. В статье Джоанна Доган (Jaana Dogan) не поленилась их разворачивать и развивать. Иногда в неожиданную сторону: в пункте #1 мы, например, узнаём, что гугловские кабели давеча покусали акулы. Немало SQL-примеров, схем и есть матрица PostgreSQL vs. MySQL.

  • Если сеть доступна 99.999% времени, вам сильно повезло;
  • ACID понимают по-разному;
  • у каждой СУБД свои возможности поддержки согласованности и изоляции;
  • оптимистические блокировки могут помочь, когда удерживать эксклюзивные блокировки нет возможности;
  • есть аномалии кроме грязного чтения и потери данных;
  • моя СУБД, в каком порядке хочу исполнять транзакции, в таком и исполняю;
  • шардинг на уровне приложения не означает шардинг вне СУБД;
  • AUTOINCREMENT может преподнести неприятные сюрпризы;
  • устаревшие данные могут быть полезны и помогают обойтись без блокировок;
  • рассогласования из-за часов;
  • под задержками (latency) могут подразумевать разное;
  • надо оценивать производительность не по усредненным показателям, а по критическим операциям/транзакциям;
  • вложенные транзакции небезопасны;
  • транзакции не должны поддерживать состояния приложений;
  • планировщик поможет узнать многое о базе данных;
  • миграции без останова сложны, но возможны;
  • существенный рост базы данных увеличивает непредсказуемость.


Troubleshooting Performance Issues Due to Disk and RAM

Хамид Ахтар (Hamid Akhtar, HighGo, Китай) написал простенькую, но небесполезную памятку для тех, кто хочет быстро сузить круг подозреваемых при поиске проблем с железом. Начав с совсем очевидных top, free и df, он обращается к утилитам анализа производительности дисков, процессора и памяти, и предлагает полезные наборы их опций:
iostat (информация и о диске, и о процессоре), напр. iostat -dmx sda 1
sar (System Activity Report, часть пакета sysstat), напр. sar -f /var/log/sa/sa03 -b -s 02:00:00 -e 02:30:00 -r -S
dstat, напр. dstat -cdngy

А вот скриптик для анализа памяти:
#!/bin/bashgrep -A3 "MemTotal" /proc/meminfo  grep "Swap" /proc/meminfogrep -A1 "Dirty\|Active" /proc/meminfo
.

Starting with Pg where is the config?

Депеш (Хуберт Любашевски) в короткой заметке напоминает, как можно найти конфигурационные файлы, если они лежат в нестандартном месте. Способы, которыми он предлагает воспользоваться не сенсационны, но может быть полезен, скажем, удобный набор опций.
Например, так:
ps -fxao pid,command | grep -E 'post(gres|master)'
на выходе будет path. И отсюда:
sudo grep -E '(hba|ident)\.conf' <путь к postgresql.conf>
Или теперь танцуем от pid:
sudo cat /proc/<подставляем pid>/environ | tr '\0' '\n' | grep ^PG | sort
Или:
sudo lsof -p <подставляем pid> -a -d cwd
получаем каталог данных и сведения о нём.
Если такие советы не понадобились, можно порефлексировать на тему я бы сделал по-другому. Скажем, просто-напросто используя find, например.

Агрегаты в БД

Кирилл Боровиков aka kilor завершил мини-серию статей про агрегаты:

Зачем, как, а стоит ли?

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

Эффективная обработка потока фактов

как обработать БОЛЬШОЕ (капслок kilor-а) количество записей и при этом особо никого не заблокировать, включая набегающий поток данных. Например, это может быть пересчет остатков и ведение сводных продаж по товарам при их постоянных отгрузках, или агрегация сальдо и оборотов по бухгалтерским счетам, при массовых изменениях проводок.

Многомерные суперагрегаты

иерархичные агрегаты в нескольких одновременных разрезах;

Прокси-таблицы

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



Облака



Babelfish: the Elephant in the Room?

Русский перевод названия этой статьи, появившейся на сайте фонда испаноговорящего сообщества FUNDACIN POSTGRESQL звучал бы так: "Вавилонская рыбка или слона-то я и не приметил?" Мы уже упоминали, что идея проекта сверхамбициозная: Bablefish это PostgreSQL, совместимый с SQL Server настолько, что приложения, под него написанные (в том числе с T-SQL и протоколом TDS), будут сразу работать, не зная, что работают с PostgreSQL.

Автор статьи Альваро Эрнандес (lvaro Hernndez Tortosa, OnGres) начинает с рыночной конъюнктуры, чтобы дальше предъявить гамлетовский вопрос, которым авторы Вавилонской Рыбки должны были задаться: форкать или не форкать?

Babelfish пока не может работать как расширение без доработки ядра PostgreSQL. Альваро напоминает, что 25-го января заслуженный и авторитетный в сообществе человек Ян Вик (Jan Wieck) предложил обсудить расширяемость протокола PostgreSQL: сделать такие хуки, которые позволят реализовать протокол SQL Server в виде расширения без изменений в ядре. Но это процесс небыстрый. Заодно решили обсудить и совместимость с MySQL. Но что делать AWS с Bablefish, если сообщество проигнорирует этот путь или интеграция пойдёт ни шатко, ни валко? Вероятней всего, считает Альваро, AWS будет развивать Bablefish как форк (так уже случилось с Aurora), как бы им не хотелось бы обойтись без форка. А если всё же придётся, то AWS это по силам.

Далее Альваро привлекает Дилемму инноватора. И задаёт ещё один интересный вопрос: хотим ли мы (то есть сообщество), чтобы Babelfish стала MariaDB у PostgreSQL?

Персона


Очередной PG-персоной недели стал Александр Сосна, живущий в небольшом городке на Нижнем Рейне и в свободное от работы в credativ время преподающий ИТ-безопасность в Нижнерейнском Университете. Он работает над довольно необычным расширением: pg_snakeoil. Это антивирус специально для PostgreSQL: он ищет вирусы в данных так, чтобы не мешать работе базы, что отнюдь не характерно для обычных антивирусов. Как замечает Александр, за вирусами охотятся не всегда из-за их вредоносности, иногда только потому, что этого требуют нормативные документы.

Релизы


PostgreSQL 13.2

Вышли PostgreSQL 13.2, 12.6, 11.11, 10.16, 9.6.21, 9.5.25 (последний выпуск ветки 9.5). В этих релизах одолели две проблемы безопасности:
в PostgreSQL 13 можно было, имея права на SELCT одного столбца, получить при помощи изощрённого запроса все столбцы таблицы;
вторая проблема касалась версий 11, 12 и 13. Если у пользователя есть права на UPDATE партицированной таблицы, но нет прав на SELECT некоторого столбца, он мог получить данные столбца из сообщений об ошибке.
Кроме того исправлено более 80 багов.

pg_probackup 2.4.9

Появился флаг --force для инкрементального режима. Теперь можно переписывать содержимое в каталоге, указанном в PGDATA, если system-identifier в целевом экземпляре и копии НЕ совпадают (раньше приходило сообщение об ошибке).


pgAdmin 4 v. 5.0

В версии 5.0 среди прочего появилась поддержка логической репликации; поддержка публикаций и подписок в Schema Diff.

Apache AGE 0.3.0

Apache AGE это расширение, добавляющее в PostgreSQL функциональность графовой базы данных. Цель проекта единое хранилище для реляционной и графовой моделей данных, чтобы пользователи могли использовать и стандартный SQL, и языки запросов к графовым базам openCypher и GQL.

Подробнее..

SQL задача на поиск последней цены

16.03.2021 18:09:12 | Автор: admin

Здравствуйте! В эфире снова Радио SQL.

Давненько не выходили в эфир, но тут братья-гуманоиды из соседнего Малого МакГеланового облака подкинули задачку. Сходу в один присест задачка не решилась, пришлось подумать. Значит и в Западном рукаве Галактики тоже могут найтись желающие поломать мозг об задачку. Сейчас изложу условие, а ответ следующим посланием уйдёт.

Условие такое. Есть набор данных с ценами на товары (prod_id) на складах (stock_id). Причём цены бывают настоящие (R=Real), а бывают рекламные (P=Promo). Для каждой цены есть дата начала действия. Нужно к каждой строчке набора вытащить реальную цену, которая является последней по дате настоящей ценой (price1) с типом 'R' на этот товар на соответствующем складе.

Вот начало запроса с тестовыми данными в виде CTE, на которых можно потренироваться:

with price(stock_id, prod_id, start_date, kind, price1, cost1, bonus1) as (values (1,1,to_date('2000-01-01','YYYY-MM-DD'),'R',100.0,32.12,6.49),       (1,1,'2000-01-02','P', 80.0, 0,   0),       (1,1,'2000-01-03','P', 70.0, 0,   0),       (1,1,'2000-01-04','R',110.0,33.48,6.19),       (1,1,'2000-01-05','P', 90.0, 0,   0),       (1,1,'2000-01-06','R',120.0,41.22,6.19),       (1,1,'2000-01-07','P', 80.0, 0,   0),       (1,1,'2000-01-08','P', 90.0, 0,   0),       (1,1,'2000-01-09','R', 93.0,36.87,6.49),       (1,1,'2000-01-10','R', 94.0,36.85,6.99),       (1,2,'2000-01-01','R',101.0,52.06,9.00),       (1,2,'2000-01-02','P', 81.0, 0,   0),       (1,2,'2000-01-03','P', 71.0, 0,   0),       (1,3,'2000-01-04','R',111.0,64.96,4.50),       (1,3,'2000-01-05','P', 92.0, 0,   0),       (1,3,'2000-01-06','R',122.0,66.83,4.60),       (1,3,'2000-01-07','P', 82.0, 0,   0),       (1,3,'2000-01-08','P', 92.0, 0,   0))select ...

Должно получиться что-то вида:

 stock_id | prod_id | start_date | kind | price1 | cost1 | bonus1 | price1x ----------+---------+------------+------+--------+-------+--------+---------        1 |       1 | 2000-01-01 | R    |  100.0 | 32.12 |   6.49 |   100.0        1 |       1 | 2000-01-02 | P    |   80.0 |     0 |      0 |   100.0        1 |       1 | 2000-01-03 | P    |   70.0 |     0 |      0 |   100.0        1 |       1 | 2000-01-04 | R    |  110.0 | 33.48 |   6.19 |   110.0        1 |       1 | 2000-01-05 | P    |   90.0 |     0 |      0 |   110.0        1 |       1 | 2000-01-06 | R    |  120.0 | 41.22 |   6.19 |   120.0        1 |       1 | 2000-01-07 | P    |   80.0 |     0 |      0 |   120.0        1 |       1 | 2000-01-08 | P    |   90.0 |     0 |      0 |   120.0        ...

Особенности же тут вот в чём. Я не зря радировал выше источник данных, потому что не таблица тут у нас, а вьюха, собранная из самых разных и зачастую совершенно неожиданных источников, откуда всякие промо-цены и берутся. То есть primary key для строчек не только нету, но и даже суррогатный-то на лету не так сразу получишь, так как никаких CTID (или там ROWID) в помине нету... Второй нюанс это тут я оставил только колонки price1, cost1 и bonus1, а в настоящем источнике данных много всяких характеристик нужно было вытащить из последней 'R'-строки, так как на рекламных строках эти данные отсутствуют. И не спрашивайте, почему так бизнесу виднее. Считайте расширенным условием задачи выбрать все эти поля из последней R-записи.

Что ж, прошу в каменты с идеями и вариантами решений! Через мифический человеко-месяц будет подведение итогов и разбор решения. Решения в комментариях будут проверяться на PostgreSQL, так что можно пользоваться (но не злоупотреблять!) платформозависимыми особенностями. Большая просьба SQL-код убирать под спойлеры, чтобы не светить его тем, кто хотел бы попробовать свои силы в решении. Для не имеющих постгреса под руками, есть масса возможностей запустить запрос онлайн, так что за отмазку не засчитывается. Да и поставить работающий постгрес из штатных репозиториев ОС под любым не слишком экзотическим Linux можно буквально в одну команду.

P.S. Так как опубликовано в корпоративном блоге Постгрес Про, то будем пользоваться корпоративными привилегиями. Для стимуляции активности за самое интересное решение выдам какие-нибудь плюшки от лица компании, промокод на PGConf или на сдачу тестов по сертификации...

Подробнее..

Postgresso 30

05.04.2021 18:06:45 | Автор: admin

Мы продолжаем знакомить вас с самыми интересными новостями PostgreSQL. Этот выпуск получился с некоторым уклоном в средства диагностики. Нет, не только. Например:

Хардверные ускорители: FPGA


В небольшом сообщении Энди Эликотта (Andy Ellicott) в блоге Swarm64 3 hardware acceleration options Postgres users should know in 2020 рассказывается о трёх аппаратных ускорителях, не GPU, а FRGA, и все они в облаках. У автора свой интерес: у Swarm64 есть собственное решение на FPGA-ускорителе. Значимым сигналом он считает объявление Amazon об FPGA-ускорителе кэша (FPGA-powered caching layer) в Redshift AQUA (Advanced Query Accelerator) в Amazon, который убыстряет запросы на порядок. А вообще уже почти все облака (во всяком случае Amazon, Alibaba, и Azure) используют сейчас FPGA-ускорители, просвещает нас Энди.

Итак:

Swarm64 Data Accelerator (DA)
это расширение, которое умеет переписывать обычные SQL-запросы, чтобы распараллеливать вычисления на всех этапах их исполнения, а сотни читающих или пишущих процессов будут работать параллельно на FPGA. Кроме того, там реализованы индексы columnstore, как в MS SQL Server. Есть техническое описание в PDF, но именно про FPGA в нём ничего нет. Зато есть демонстрационное видео, показывающее, как можно легко и быстро развернуть Postgres на инстансе Amazon EC2 F1 с FPGA. Ещё есть результаты тестов TPC-H (а позиционируется эта комбинация с FPGA прежде всего как ускоритель для гибридных транзакционно-аналитических нагрузок HTAP), и там показывает выигрыш в 50 раз по скорости.

Другой вариант, который предлагает Энди: Intel Arria 10 GX FPGA в связке с NVM-памятью Intel Optane DC, SSD и PostgreSQL 11 с тем же расширением Swarm64 DA. Всё это собрано в демо, которое вбрасывает в PostgreSQL потоки биржевых котировок со скоростью 200 тыс инсертов в секунду, и дальше работает с ними с обычным SQL.

Третий вариант с Samsung SmartSSD, в которой внутри FPGA-чип от Xilinx. Испытания (с тем же свормовским расширением, как можно догадаться) дали выигрыш в 40 раз на TPC-H и в 10-15 раз на JOIN-ах.

С маркетинговой точки зрения эти усилия нацелены прежде всего против хардверных решений для WH вроде Netezza или Teradata.

Обещано, что будет и сравнение эффективности FPGA vs. GPU (в т. ч. и в контексте проекта PGStrom).

(спасибо Александру Смолину за наводку в FB-группе PostgreSQL в России)




Конференции


были:

PGConf.online

Теперь выложены все видео и презентации доступ через расписание.

FOSDEM 21

Поток PostgreSQL devroom тёк два дня 6-7 февраля с 10 утра до 6 вечера. Материалов конференции очень много. Вот имеется однобокая, зато систематизированная выборка доклады от Postgres Professional (глаголы будущего времени там надо поменять в уме на глаголы прошедшего).

будет:

Highload++

Объявлено, что состоится офлайн 17 -18 мая 2021 в Крокус-Экспо, Москва. Есть Расписание. Я бы обратил особое внимание на потоки
СУБД и системы хранения, тестирование в Зале 3, например:
Микросервисы с нуля, Семен Катаев (Авито);
Прокрустово ложе или испанский сапог мифы и реальность СУБД в Облаках, Александр Зайцев (Altinity)
и на
Архитектуры, масштабируемость, безопасность в Зал 4 (главном), например:
Архитектура процессора Эльбрус 2000, Дмитрий Завалишин (Digital Zone);
SQL/JSON в PostgreSQL: настоящее и будущее, Олег Бартунов (Postgres Professional);
Распространённые ошибки изменения схемы базы данных PostgreSQL, Николай Самохвалов (Postgres.ai).

Вебинары и митапы


RuPostgres-вторник s02e13 Андрей Зубков (PostgresPro) pg_profile, pgpro_pwr

Вторник, посвященный pg_profile / PWR, так заинтересовал устроителей, что с большой вероятностью в ближайшее время можно ожидать продолжения: разобрались не во всех тонкостях работы этого весьма практичного инструмента, ну а расширения pgpro_stats, которое используется в PWR, коснулись по касательной.

После это был ещё вторник с Александром Кукушкиным (Zalando). Тема риски апгрейда мажорных версий с фокусом на PG12 и PG13, а пособник апгрейда Spilo: как выяснилось, бесшовный апгрейд в контексте Patroni задача слишком амбициозная, а вот Spilo, то есть Docker-образ с PostgreSQL и Patroni, с задачей справляется. Но опасностей и нюансов при апгрейде остаётся немало. Говорилось о сюрпризах от VACUUM, ANALYZE, о параллелизме по умолчанию, о CTE и материализации, о JIT.

Database Delivery: The Big Problem

Это была презентация от Ростелеком-ИТ, которую провёл Роман Гордеев (в видео глюки, надо прокрутить первые 11 минут). Его пригласили на один из стримов Tver.io сообщества тверских айтишников (но мне удобней было смотреть этот же ролик на на youtube). Речь шла об инкрементальной стратегии миграции. Роман рассказывал о вещах, применимых к разным СУБД и средам разработки, но для примера был выбран переход с базы PostgreSQL на H2 в графическом DataGrip. Соответственно в реальном времени наблюдались и решались проблемы с постгресовым типом text и с последовательностями.

В качестве механизма, который контролирует миграцию, был взят плагин liquibase для среды gradle. О настройках для такой работы можно почитать на страничке liquibase gradle на гитхабе Гордеева. Кстати, Ростелеком Информационные Технологии компания с населением под 2 тыс. человек. На официальной странице есть информация об опенсорсной СУБД in-memory Reindexer собственной разработки. Больше о базах там ничего пока найти не удалось.


Обучение


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

Тем, кто интересуется более пристально, советую прослушать доклад о курсах Егора Рогова на PGConf.online 2021.


Мониторинг


Monitoring PostgreSQL with Nagios and Checkmk

Пишет опять Хамид Ахтар (Hamid Akhtar, китайская компания High Go), на этот раз пишет о средствах мониторинга Nagios (рекурсивный акроним Nagios Ain't Gonna Insist On Sainthood Nagios не собирается настаивать на святости, в отличие от его предшественника NetSaint) и Checkmk. Публикация без претензий: как установить и настроить, не претендуя даже в этом на полноту.

Explaining Your Postgres Query Performance

Идём от простого к сложному. Пока URL подсказывает возможный подзаголовок статьи: Get Started with EXPLAIN ANALYZE. Кэт Бэтьюйгас (Kat Batuigas, Crunchy Data) действительно знакомит с самыми азами EXPLAIN, даже без опций. Жанр For dummies, и наглядно: показывает, как с помощью EXPLAIN ANALYZE можно наблюдать решения планировщика об (не)использовании индексов, и вообще что там происходит. Иллюстрируется это всё на базе Geonames.

Предыдущая её статья была о Query Optimization in Postgres with pg_stat_statements.

Вот ещё одна её статья: Three Easy Things To Remember About Postgres Indexes. В ней не только напоминания о том, что индекс занимает место на диске, но и, например, такие соображения:
Важен и тип запроса. Например, если в запросе есть знаки подстановки (wildcards)
wildcards, e.g. WHERE name LIKE 'Ma%',
то планировщик задействует по умолчанию индекс B-tree, но вам, возможно, стоит указать класс оператора, чтобы был выбран эффективный индекс.

Can auto_explain (with timing) Have Low Overhead?

Михаэль Христофидес (Michael Christofides) показывает работу расширения auto_explain с включённым и отключённым таймингом. Выводы:

Если задать ощутимый промежуток времени min_duration, издержки от auto_explain на небольшой транзакционной нагрузке )была меньше 1% с отключённым таймингом и ~2% с включённым. Семплинга не было, поэтому детали прослеживались для каждого запроса, но попадали в лог для медленных. А когда min_duration=0ms, и логировалось всё, издержки оказались больше 25%, даже без тайминга и ANALYZE. Видимо, издержки auto_explain связаны в основном с логированием.

Интерес у Михаэля не невинный он разработчик утилиты pgMustard, которая визуализирует планы. Она также расписывает, сколько тратится времени и сколько строк возвращает каждая операция (в т.ч. циклы; дочерние узлы планов subplans; CTE). Мало того, pgMustard умеет подсказывать. Например:
  • (не)эффективность индексов;
  • плохая оценка числа строк;
  • неэффективность кэша;
  • угроза распухания индекса (bloat);
  • CTE-скан использовался только 1 раз.


How to create a system information function in PostgreSQL

Давид Ян (David Zhang, старший системный архитектор в той же High Go) делится опытом написания собственных информационных функций. Ему мало тех, что можно найти на вот этой странице. Например, его не устраивает, что txid_current() возвращает ему тот же идентификатор транзакции, что и было до SAVEPOINT.

Ссылаясь на страничку Исходные данные системных каталогов, Давид показывает, как выбрать OID для новой функции, чтобы он не конфликтовал с существующими. Потом приводит код своей функции, определяющей xtid после SAVEPOINT. Называется она txid_current_snapshot и написана на C. И тестирует её. Теперь идентификатор транзакции показывается корректно.

How The PostgreSQL Optimizer Works

Ханс-Юрген Шёниг (Hans-Jrgen Schnig, Crunchy Data) написал не то, чтобы концептуальную, но большую по объёму статью, в которой есть примеры, демонстрирующие:

обработку констант: почему
WHERE x = 7 + 1
для оптимизатора не то же, что
WHERE x - 1 = 7

встраивание функций (function inlining): умение оптимизатора встраивать функции зависит от языка, в SQL он как дома, но не в PL-ях.

как обрабатываются функции, если они VOLATILE/STABLE/IMMUTABLE. Например:
WHERE x = clock_timestamp()
против
WHERE x = now()

что способен понять PostgreSQL, задумавшись о том, что чему равно:
понять, что если x = y AND y = 4, то x = 4, а значит можно использовать индекс по x это он может.

что такое view inlining и subselect flattening:
как представление превращается во вложенные SELECT-ы, а они в обычный, плоский SELECT.

Ну и, конечно, центральный вопрос как оптимизатор расправляется с JOIN. Тут Ханс-Юрген рассказывает об очерёдности джойнов, о явных и неявных; об OUTER JOIN; автоматическом исключении (pruning) ненужных; об EXIST и анти-джойнах.



Случайности:


Они не случайны

Кирилл Боровиков ака kilor выступил в роли волшебника: он угадывает случайные числа! Он придумал волшебную функцию и даже назвал её magic(). В качестве аргумента она берёт только что сгенерённое функцией random() число и предсказывает следующее:
SELECT r random, magic(r) random_next FROM random() r;       random       |    random_next--------------------+-------------------- 0.3921143477755571 | 0.6377947747296489tst=# SELECT r random, magic(r) random_next FROM random() r;       random       |    random_next--------------------+-------------------- 0.6377947747296489 | 0.5727554063674667

Чтобы исследовать содержание внутренностей волшебной функции, автор предлагает разобраться в линейном конгруэнтном алгоритме, который используется в random(), залезает в код функции setseed() в файле float.c и там находит источник вдохновения для создания своей волшебной функции.

Итого, случайные числа random() не слишком случайны, о криптографии и речи не может быть. Но кое-какие альтернативы имеются: более безопасны функции в расширении pgcrypto.


Восстановление


Speeding up recovery & VACUUM in Postgres 14

Статья на сайте Citus, но речь не о Citus, а о патче в основную ветку PostgreSQL. Написана статья (и патч) Дэвидом Роули (David Rowley), работавшим над этим уже внутри Microsoft. Он переписал внутреннюю функцию compactify_tuples, которая используется, когда PostgreSQL стартует после внештатного (нечистого) шатдауна (crash recovery), и когда идёт восстановление standby-сервера проигрыванием WAL по их прибытии с primary-сервера; VACUUM.

Эти случаи Дэвид и расписывает, поясняя схемами. Новая версия функции избавляет от ненужной внутренней сортировки кортежей в heap, поэтому и работает быстрее. На pgbench выигрыш в 2.4 раза на восстановлении и на 25% при вакууме.


Соревнования


Performance differences between Postgres and MySQL

В сообществе Arctype очень интересуются сравнительной производительностью PostgreSQL и MySQL. Эта сумбурная статья с приятными выводами продолжение вот этой, где преимущества той и другой СУБД оценивали качественно, и пришли в том числе к выводам о преимуществах PostgreSQL. Он лучше когда:
  • надо работать со сложно устроенными или объёмистыми данными;
  • аналитические нагрузки;
  • нужна транзакционная база общего назначения;
  • требуется работа с геоданными.


А на этот раз решили померить, причём с уклоном в JSON, поскольку эта тема интересует в сообществе очень многих и очень сильно. Вот что было сделано:
создан проект, в котором использовались PostgreSQL и MySQL;
создали объект JSON для тестирования чтения и записи, размер объекта около14 МБ, около 200210 записей в базе данных.

И опять приятный вывод:
JSON-запросы быстрей в Postgres!

Кроме этого автор по касательной упоминает индексы по выражениям и прочие, особенности репликации, принципиальные отличия MVCC в InnoDB MySQL и в PostgreSQL.


PostGIS


Traveling Salesman Problem With PostGIS And pgRouting

У Флориана Надлера (Florian Nadler, Cybertec) проблемный коммивояжер странствует по окрестностям Гамбурга. Это продолжение статьи 'Catchment Areas' With PostgreSQL And PostGIS. Там собрали множества городов, ближайших к крупным аэропортам, разбросав их по диаграммам Вороного.

Теперь, надо решить, как лучше эти города обойти, для чего кроме PostGIS Флориан использует функции расширения pgRouting. Чтобы превратить множество точек в граф, он выбирает утилиту osm2po.

Дальше pgr_createverticestable функция из pgRouting превратит граф в таблицу. Эта таблица-граф накладывается как слой поверх слоёв OpenStreetMap. После этого Флориан, используя функцию pgr_dijkstraCostMatrix из pgRouting, решает эту знаменитую задачу оптимизации с помощью замысловатого запроса с CTE, учитывая стоимости/веса, присвоенные ещё osm2po.

Performance Improvements in GEOS

GEOS важнейшая для геовычислений библиотека (алгоритмы портированы на C из Java Topology Suite или JTS). Crunchy Data вкладывают в её развитие не меньше сил, чем в саму PostGIS.

Пол Рамси ( Paul Ramsey) рассказывает не просто о тестах производительности GEOS (довольно специфических), а взглядом историка GEOS иллюстрирует ими хронологию улучшений в этой библиотеке от релиза 3.6 к свежайшему 3.9. Вообще-то, о GEOS 3.9 Пол говорил и раньше в начале декабря в блоге Crunchy Data Waiting for PostGIS 3.1: GEOS 3.9 и в собственном. Там тоже есть роскошные иллюстрации, но нет графиков производительности.

А вот заметку Пола Рамси Dumping a ByteA with psql можно увидеть только в его блоге. Она короткая, но может оказаться полезной тем, кто:
  • хранит двоичные файлы в столбцах базы, например изображения-ярлычки (thumbnails);
  • хочет сформировать на выходе двоичный файл изображения, песни, protobuf или LIDAR-файл;
  • использует двоичный формат для транзита двух разных типов.

Хранить в двоичном виде картинку можно, а вот посмотреть нельзя нужен файл. Вот скриптик, который берёт из базы ярлычок в типе bytea, через psql двоичное значение обертывается функцией encode и выгружается как обычное текстовое. Вывод psql перенаправляется в утилиту xxd, которая декодирует входной поток (ключ -r) обратно в двоичный вид и записывает в файл .png:
echo "SELECT encode(thumbnail, 'hex') FROM persons WHERE id = 12345" \  | psql --quiet --tuples-only -d dbname \  | xxd -r -p \  > thumbnail.png

Такой способ будет работать для любого поля bytea.


Активная жизнь в коммьюнити


How many engineers does it take to make subscripting work?

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

Патч добавляет subscripting в синтаксис функций JSONB то есть как у массивов, например:
SET jsonb_column['key'] = '"value"';
вместо
SET jsonb_column = jsonb_set(jsonb_column, '{"key"}', '"value"');

Началась история этого патча в 2015 году с беседы Дмитрия с Олегом Бартуновым и последовавшего простенького патча Долгова. Сообщество отнеслось к патчу сочувственно, но предложило переписать его в более универсальной манере, чтобы подобную функциональность можно было бы использовать и для других типов данных. Соответствующий патч Дмитрия был непрост, и ревюеры не торопились его разобрать и оценить. Ещё в истории этого патча фигурируют Том Лейн (Tom Lane), закоммитивший финальный патч Александр Коротков, Павел Стехуле (Pavel Stehule) и Никита Глухов.

Затрагиваются темы универсальности и, пожалуй, лучшее враг хорошего. Патч продвигался настолько вяло, что Дмитрий в отчаянии даже написал в комментарии к патчу: если вы дочитали до этой фразы и напишете рьвю, я выставлю бутылку пива на следующей PGConfEU (о судьбе бутылки из статьи мы не узнали).

В финале статьи 8 советов. Вот некоторые из них в моём вольном переводе, начиная с последнего Last but not least:

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

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

Разбейте патч на несколько частей это всегда облегчает работу ревьюеров.

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


Облака и контейнеры


Running Postgres In Docker Why And How?

Каарел Моппел (Kaarel Moppel, Cybertec) задаёт себе вопрос можно и нужно ли использовать PostgreSQL в Docker в качестве продакшн, будет ли он вообще там работать? и отвечает: да, работать будет, если сильно постараться, и если для фана или для тестирования.

В статье несколько разделов, но начнём с предпоследнего Капли дёгтя в бочку мёда.

Докер-имиджи да и вся концепция контейнеров оптимизированы под моментальное разворачивание в стиле стартапов . По умолчанию там даже данные не разведены как следует по томам (persistent units). Если этого не сделать, затея может закончится катастрофой.

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

У вас будет относительно лёгкая жизнь только в том случае, если вы используете такой всеобъемлющий фреймворк, как Kubernetes плюс выбираете оператор (скорее всего от Zalando или Crunchy).



Поведение


The PostgreSQL Community Code of Conduct Committee Annual Report for 2020

Этот документ сообщества переводили на русский Анастасия Лубенникова, Александр Лахин и Анастасия Распопина (все из Postgres Professional), также участвовали Виктор Егоров и Валерия Каплан. Ещё он переведён с английского на японский и иврит.

Число жалоб увеличилось в 2020: 18 против 12 в прошлом году. Мужчины жалуются чаще: 15/3. Обычно от страны по жалобе. По 2 только от РФ, Аргентины, UK и US.
Подробнее..

Postgresso 31

11.05.2021 16:15:42 | Автор: admin
Надеемся, что вы хорошо отдохнули и попраздновали. А мы предлагаем вам очередную сводку Postgres-новостей.

PostgreSQL 14 Beta 1


Релизная группа в составе Пит Гейган (Pete Geoghegan, Crunchy Data), Мишель Пакье (Michael Paquier, VMWare) и Эндрю Данстан (Andrew Dunstan, EDB) предлагают опубликовать бету 20-го мая, как это и происходило с предыдущими бетами.



Commitfest afterparty


PostgreSQL 14: Часть 5 или весенние заморозки (Коммитфест 2021-03)

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

Вот авторский тизер:
  • Может ли один запрос параллельно выполняться на разных серверах?
  • Как найти запрос из pg_stat_activity в pg_stat_statements?
  • Можно ли добавлять и удалять секции секционированной таблицы не останавливая приложение?
  • Как пустить разработчиков на прод чтобы они могли всё видеть, но ничего не могли изменить?
  • Почему VACUUM после COPY FREEZE заново переписывает всю таблицу и что с этим делать?
  • Можно ли сжимать TOAST чем-то кроме медленного zlib?
  • Как понять сколько времени длится блокировка найденная в pg_locks?
  • Для чего нужны CYCLE и SEARCH рекурсивному запросу?
  • Текст функций на каких языках (кроме C) не интерпретируется при вызове?


Миграция


CHAR(1) to Boolean transformation while migrating to PostgreSQL

В Oracle нет типа boolean, а в PostgreSQL есть. Но почему бы не использовать этот тип, если в исходной оракловой базе есть столбец boolean, который хранится там в виде CHAR(1) с ограничением CHECK? Можно. Но хотелось бы ещё получить гарантию, что значения, отличные от резрешенных для Postgres не остановят работу приложения, а будут должным образом обработаны. Для этого можно создать CAST:
CREATE CAST (char as bool) WITH FUNCTION char_to_bool(char);
Далее автор Дилип Кумар (Dileep Kumar, MigOps) показывает изменение поведения при определении CAST как IMPLICIT, а потом прогоняет запрос (обычный SELECT) на тестах, чтобы увидеть разницу CHAR(1) vs Explicit Casting vs Implicit Casting vs Boolean. Побеждает, как и ожидалось, Boolean.

Choice of Table Column Types and Order When Migrating to PostgreSQL

В статье Стивена Фроста (Stephen Frost) с участием его коллеги по Crunchy Data Дэвида Юатта (David Youatt) тоже говорится о том, какой тип выбрать в PostgreSQL при миграции, но ещё и о том, в каком порядке располагать столбцы, чтобы данные выбранных типов хранились максимально эффективно. Сначала самые широкие поля с фиксированной шириной, затем менее широкие с фиксированной и только потом поля переменной ширины иначе появятся дыры в данных. Стивен рассказывает и про неприятные сюрпризы с выравниванием, которые можно получить, излишне рьяно экспериментируя с типами PostgreSQL. Ещё совет: выбирайте NUMERIC или DECIMAL только тогда, когда необходимо (считая деньги, например), а если нет, то обходитесь NTEGER, BIGINT, REAL, DOUBLE PRECISION это проще и эффективней.


Масштабирование


Lessons Learned From 5 Years of Scaling PostgreSQL

Джо Уилм (Joe Wilm) обобщает опыт использования PostgreSQL в компании OneSignal. Система доросла за 5 лет до 75 ТБ на 40 серверах. Понятно, что не все технические решения были приняты сразу на вырост. Как решают проблемы масштабирования, и как их можно было избежать об этом и рассказывает автор. Для удобства он разбил статью по разделам (сознательно не перевожу, слишком много английских слов пришлось бы писать кириллицей):
Bloat таблиц и индексов. Коротко о (хорошо известных) причинах распухания. pg_repack справлялся так себе (см. причины), написали собственный демон, координирующий его работу. Перешли к pgcompacttable там, где pg_repack обваливает производительность (перешли не везде, pgcompacttable работает надёжней, но медленней). Есть и об уловках по ситуации: в системе были таблицы, в которых большие поля (около 1 КБ) в личных данных, и поле last_seen_time int, которое часто обновлялось. Их разнесли по разным таблицам: одним JOIN больше, зато не копятся килобайты при обновлении строки.
Database upgrade. Мажорные и минорные. С мажорными справлялись при помощи логической репликации pglogical. При минорых просто перестартовывали postgres.
Wraparound. Серьёзная проблема для таких нагрузок. Остановились на оповещениях при приближении к 250 млн оставшихся XID. Напомним, конечно, что в Postgres Pro Enterprise 64-битные XID.
Replica Promotion. Для этого обходятся средствами haproxy. Упоминается только Patroni, но и то в контексте мы не используем, но может и стоило. Для каждой логической базы данных есть два бэкенда: один read-write, другой read-only. Переключение занимает пару секунд.
Partitioning и Sharding. Важнейшая штука для такой базы, конечно. Сначала порезали на 16 секций, потом на 256, а в ближайших планах 4096. Резали на куски выбирая в качестве критерия разбиения id пользователей системы. Сейчас думают над созданием data proxy слое, который будет знать, как разрезаны данные и где лежат, и действовать соответственно. Чтобы приложениям этого не требовалось знать для нормальной работы. Сетуют, что не сделали так с самого начала.


Самокритика


Чего энтерпрайзу в PostgreSQL не хватает

Вот чего ему не хватает в порядке важности (по Кириллу Боровикову, автору статьи)
  • легковесного менеджера соединений (он же built-in connection pooler);
  • 64-bit XID;
  • микротаблиц (речь о том, что у каждой таблицы и индекса в PostgreSQL есть 3 форка файла, но почему бы не обойтись 1 файлом (heap) для мелких справочных табличек?);
  • zheap;
  • append-only storage (а в идеале, считает Кирилл хотелось иметь возможность назначать часть полей индексов или целых таблиц как no-MVCC чтобы иногда экономить на полях поддержки MVCC);
  • отложенная индексация (чтобы сервер мог размазать необходимые операции во времени для балансировки нагрузки эта тема особенно важна для конкуренции с поисковыми системами, где основная задача найти вообще, а не найти прямо сразу сейчас);
  • columnar storage (в идеале в ядре или в contrib);
  • in-memory storage (очень быстрого нетранзакционного хранилища без сброса на диск);
  • не пухнущих TEMPORARY TABLE, в том числе на репликах;
  • multimaster из коробки;
  • SQL-defined index (уметь описывать новые виды индексов прямо на SQL/PLpgSQL);
  • мониторинга производительности запросов (здесь Кирилл предлагает глянуть, как это визуализируется на родном explain.tensor.ru);
  • снапшотов статистики таблиц (как в pg_profile [а тем более в pgpro_pwr примечание редакции]).

К ЭТОМУ ДОБАВИЛИСЬ ХОТЕЛКИ ИЗ КОММЕНТАРИЕВ:

  • IS NOT DISTINCT FROM при индексации;
  • failover из коробки (аналогично Always on у MS SQL) без Patroni и сопутствующих;
  • Asynchronous IO и Direct IO;
  • бесшовного обновления мажорной версии;
  • flashback queries;
  • edition-based redefinition;
  • нормальной компрессии.

Некоторые из этих хотелок на пути к дальнейшим версиям, некоторые уже есть в Postgres Pro Enterprise (о чём не умалчивает и автор).


Видео-вторник s02e15: Десять проблем PostgreSQL. Мониторинг запросов, pg_profile

(это продолжение вторника ) с Андреем Зубковым)

Статья Рика Брэнсона: (Rick Branson) 10 things I Hate In Postgres внезапно попала в топ обсуждаемых. Вот её не миновали и устроители ruPostgres.Вторников Николай Самохвалов и Илья Космодемьянский.

О ней мы писали в Postgreso 20. На ruPostgres.вторнике s02e15 6-го апреля самые жаркие вопросы возникали, как всегда, вокруг MVCC и VACUUM, переполнения 32-битных счётчиков XID.

На 50-й минуте обсуждения 10 ненавистных вещей Андрей Зубков продолжил рассказал о pg_profile (до pgpro_pwr речь опять не дошла, говорили даже о том, чтобы наверстать в 3-й серии) и о своём патче pg_stat_statements: Track statement entry timestamp (ровно 1:00 записи).

Вторник 20-го апреля назывался Как поменять тип колонки в таблице PostgreSQL с 1 млрд строк без даунтайма?. Два разных варианта решения на уровне колонки и на уровне таблицы.

А совсем недавний 4-го мая о разном, например, о WAL-G vs. pgBackRest, об амазоновских инстансах на ARM, о которых чуть ниже. Список тем лежит в файле.


Облака и контейнеры


Dramatical Effect of LSE Instructions for PostgreSQL on Graviton2 Instances

Александр Коротков в своём блоге пишет об опыте работы с новейшими облаками инстансы Graviton2 работают на амазоновских ARM-процессорах. Но следующие за модой расплачиваются некоторыми сложностями у ARM есть специфика (по мнению Александра работа с ними скорее напоминает работу с IBM Power).

Команды LSE (Large System Extensions), доступные с версии 8.1, действительно ускоряют работу. Вот здесь это разъясняют с некоторыми подробностями, испытывая MySQL на включенных и отключенных LSE. Александр же получил колоссальный выигрыш на pgbench, скомпилировав PostgreSQL 14 с поддержкой LSE. Но это касается только амазоновских ARM AWR Graviton2. Apple M1 не удалось оптимизировать (возможно, в этих процессорах есть какая-то внутренняя оптимизация), а на китайских Kunpeng 920 результаты даже ухудшились.


Что делать


Managing Transaction ID Exhaustion (Wraparound) in PostgreSQL

Кит Фиске (Keith Fiske, Crunchy Data) регулярно пишет в своём собственном блоге Keith's Ramblings о вакууме, распухших индексах и других важнейших для вдумчивого постгресиста вещах.

В этой статье есть конкретные SQL-запросы, использующие autovacuum_freeze_max_age для получения внятной информации о происходящем с конкретными таблицами, так как vacuumdb --all --freeze --jobs=2 --echo --analyze всего кластера баз данных во многих случаях слишком радикальная мера. Если недовакуумированных таблиц очень много, то Кит советует вакуумировать в батчах не больше сотни в каждом. Сам он предпочитает держать max XID < to 50% autovacuum_freeze_max_age, лучше 30-40%.

Он написал статью и о настройке автовакуума: Per-Table Autovacuum Tuning. Но даже аккуратно настроив автовакуум, стоит с не меньшей аккуратностью мониторить ситуацию. Риск не велик, но ставка высока, как говорили наши деды.

Не удержусь от перечисления собственных проектов Кита (или с его существенным участием):
pg_partman расширение с автоматической поддержкой секционирования по времени и serial id;
pg_extractor продвинутый фильтр дампа;
pg_bloat_check скрипт для мониторинга таблиц и индексов;
mimeo расширение PostgreSQL для потабличной логической репликации;
pg_jobmon расширение для логирования и мониторинга автономных функций.

Postgres is Out of Disk and How to Recover: The Dos and Don'ts

Статья Элизабет Кристинсен (Elizabeth Christensen) с участием Дэвида Кристинсена (David Christensen), Джонатана Каца (Jonathan Katz) и Стивена Фроста (Stephen Frost) все из Crunchy Data. Почему забился диск, что НЕ делать, и что делать.
Возможные причины:
  • отказала archive_command и WAL начал заполнять диск;
  • остались слоты репликации у стендбая, а реплика стала недоступна: опять же WAL заполняет диск;
  • изменения в базе настолько большие, что генерящийся WAL съедает всё доступное дисковое пространство;
  • просто-напросто данных было слишком много, а средства мониторинга и предупреждения не сработали.

Что НЕЛЬЗЯ делать:
удалять WAL-файлы нельзя категорически;
  • не дайте переписать существующие данные, восстанавливаясь из бэкапа;
  • Никакого resize.


Что надо делать:
  • сделайте сразу бэкап на уровне файловой системы;
  • создайте новый инстанс (или хотя бы новый том) с достаточным местом, убедитесь, что Postgres остановлен и сделайте бэкап директории данных PostgreSQL (обязательно директории pg_wal и недефолтные табличные пространства), чтобы вам было куда вернуться, если понадобится;
  • когда база данных заработала, просмотрите логи, разберитесь, из-за чего возникли проблемы и почините поломки, если это возможно.

В статье рассказывается, как архивируется WAL, об попорченных архивах, кое-что о pgBackRest, а ещё предлагается почитать How to Recover When PostgreSQL is Missing a WAL File.

Кстати, о WAL. Если нужно порекомендовать хорошую статью англоязычным коллегам, то в блоге Postgre Pofessional опубликован перевод 3-й части серии Егора Рогова о WAL: WAL in PostgreSQL: 3. Checkpoint. Оригинал её здесь, en-начало-серии здесь, а ru-начало здесь.


Из блога БРЮСА МОМДЖАНА


(то есть отсюда)

Jsonb Multi-Column Type Casting

Брюс делится радостью, что есть jsonb_to_record() и можно без всяких двойных двоеточий сразу сказать:
SELECT a, b, pg_typeof(a) AS a_type, pg_typeof(b) AS b_typeFROM test, jsonb_to_record(test.x) AS x (a TEXT, b INTEGER);

(А ведь добавим от себя есть ещё и jsonb_to_recordset(jsonb)).

Брюс обращает внимание на устройство таких запросов. Если сказать
SELECT x.a, b, pg_typeof(a) AS a_type, pg_typeof(b) AS b_typeFROM test, jsonb_to_record(test.x) AS x (a TEXT, b INTEGER)WHERE b <= 4;

то это будет работать, ведь b уже integer потому, что запрос уже создал табличку x с областью видимости только внутри запроса, где типы уже преобразованы. Немногословный (как обычно в своём блоге) Брюс предлагает ознакомиться с деталями в тредах json_to_record Example и Abnormal JSON query performance.

Oracle vs. PostgreSQL

Брюс решил оценить функциональную полноту обеих СУБД в %, в ответ на чьё-то сравнение Postgres и Oracle это как резиновая уточка против танкера водоизмещением 300 тыс. тонн. Он считает:
Более реалистичной была бы оценка в 80-90%, в зависимости от того, какая функциональность для вас важней. Но можно бы поговорить и том, что в Postgres есть, а в Oracle нет. С точки зрения админа получится, может быть, и меньше 80%, а вот с точки зрения разработчика в Oracle нет многого, и оценка перевалит за 100%.

Challenging Assumptions

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

Кто закрывает дыры и латает щели (в оригинале Database Software Bundles)

Проект Postgres дал миру великолепную, полнофункциональную СУБД. Но когда пользователь думает о бэкапе, мониторинге, высокой доступности, ему приходится смотреть на сторону, так как возможности Postgres могут не совпадать с его потребностями. Иногда бреши закрывают проекты с открытым кодом, но в других случаях решают проблемы коммерческие Postgres-компании: Cybertec, edb, HighGo, Ongres, Postgres Pro, sra oss и другие, которые поставляют сервисы последней мили для корпоративных решений.

Также можно заглянуть в

Shared Memory Sizing
или, скажем, в
Replica Scaling by the Numbers


ИИ


Regression Analysis in PostgreSQL with Tensorflow

Дейв Пейдж (Dave Page, вице-президент и главный архитектор EDB) продолжает серию, посвященную ИИ и статистическим методам анализа данных. Из последнего: вышли две статьи посвященные регрессионному анализу, который ускоряют с помощью Tensorflow. В приведенных примерах можно увидеть много ласкающих слух питониста слов: pandas, numpy, matplotlib и seaborn. Подчеркнём, что используется расширение PostgreSQL plpython3u, а не просто внешние по отношению к базе библиотеки.

Во второй части дело доходит до пред-обработки данных. Используется популярный у педагогов машинного обучения набор данных Boston Housing Dataset по ним тренируются угадывать цену дома в Бостоне в зависимости от некоторых факторов. Из набора выкидывают значения, сильно отличающиеся от общей массы, чтобы не запутать нейронную сеть при обучении. Ещё смотрят распределения и строят корреляции. Третья статья ещё не вышла. Обещано, что в ней уже воспользуются достижениями 2-й части, чтобы обучать нейронную сеть регрессионному анализу.


Релизы


Kubegres

Обычно в разговоре о PostgreSQL в Kubernetes на третьей фразе появляются операторы от Crunchy Data и Zalando. Kubegres, возможно, вклинится в разговор. Разработчик Алекс Арика (Alex Arica, Reactive Tech Limited). Создавался Kubegres на базе фреймворка Kubebuilder version 3 (SDK для разработки Kubernetes APIs с использованием CRD. Можно забрать отсюда.

KuiBaDB

KuiBaDB это Postgres для OLAP, переписанный с Rust и многопоточностью. У этой СУБД есть только базовая функциональность. Она, например, поддерживает транзакции, но не вложенные транзакции. KuiBaDB создан для разработчиков, чтобы они могли быстренько проверить на ней свои идеи. В ней есть векторный движок и колоночное хранение, она опирается на каталоги (catalog-driven).

pgBackRest 2.33

Появилась поддержка нескольких репозиториев данные и WAL можно копировать сразу в несколько хранилищ.
pgBackRest поддерживает теперь GCS Google Cloud Storage.
Отныне можно задать путь вручную с ./configure --with-configdir. Стало удобней работать с не-Linux ОС, например с FreeBSD.
Появилось логирование в процессе бэкапа.

pg_probackup 2.4.15

В новой версии pg_probackup при бэкапе в инкрементальном режиме автоматически обнаруживается переключение таймлайнов, за счёт использования команды TIMELINE_HISTORY протокола репликации (предложил Алексей Игнатов).

При операциях merge и retention merge теперь тоже можно использовать флаги --no-validate и --no-sync.

pgmetrics 1.11.0

pgmetrics утилита с открытым кодом для сбора статистики работающего PostgreSQL, распространяемая в виде единого бинарного файла без внешних зависимостей. Разработчик RapidLoop, у которой есть ещё и pgDash, для которой pgmetrics собирает статистику.

Новое в версии:
  • собирает и парсит логи из AWS RDS и Aurora, используя CloudWatch;
  • поддержка пулера Odyssey v1.1;
  • улучшена поддержка Postgres 13;
  • улучшена поддержка метрик AWS RDS;
  • появились бинарники для ARMv8

Скачать можно отсюда.

HypoPG 1.2

HypoPG одно из произведений Жульена Руо (Julien Rouhaud). Это расширение для работы с гипотетическими индексами. Новое в версии: работая на стендбае, hypopg использует фальшивый (fake) генератор oid, который одалживает их внутри интервала FirstBootstrapObjectId / FirstNormalObjectId, а не генерит реальные. Если потребуется, можно работать по-старому, используя опцию hypopg.use_real_oids. Есть и ещё изменения, hypopg_list_indexes(), подробности в документации.

pgstats.dev

Это динамическая диаграмма Postgres Observability упрощенное представление устройства PostgreSQL и доступные системные представления и функции для получения статистики о работе подсистем Postgres. Этому необычному произведению Алексея Лесовского (Data Egret) всего 5 месяцев, но её знают многие DBA, спорят и интересуются: что новенького? Новое, например, вот:
  • стрелки, которые раньше показывали связи между блоками и метками статистики, теперь исчезли, а соответствующие цвета введены, чтобы показать их отношения;
  • на страницах описания статистик (см. pg_stat_progress_create_index в качестве примера) улучшена внутренняя навигация за счет добавления ссылок на связанные элементы;
  • добавлены ресурсы внешние ссылки с дополнительной информацией;
  • теперь есть управление версиями, чтобы вы могли видеть, как Postgres эволюционировал от одной версии к другой.


AGE 0.4.0

Расширение, добавляющее графовую функциональность. Новшества в 0.4.0 здесь.

pg_log_statements 0.0.2

pg_log_statements расширение PostgreSQL, которое позволяет логировать SQL-запросы так, что переменная log_statement может быть установлена для отдельного серверного процесса (по id или фильтру), а не на уровне базы или инстанса.

Можно зайти на PGXN или на гитхабе создателя Пьера Форстмана, специалиста по Oracle.


Конференции


PostgresLondon 2021

Состоится уже 12-го мая, виртуальная. Расписание.

Highload++

Состоится офлайн 17 -18 мая в Крокус-Экспо, Москва. Расписание.

Postgres Vision 2020

Postgres Vision виртуальная конференция EDB, но участие свободное. Состоится 22-23 июня. Регистрация.

Следующий номер Postgresso 32 выйдет в первых числах июня.
Подробнее..

SQL разбор задачи на поиск последней цены

17.05.2021 16:18:04 | Автор: admin

В эфире снова Радио SQL, здравствуйте, согалактчики!

Сегодня у нас обещанный разбор задачи на поиск последней цены. Прошёл как раз земляной месяц. У вас же 60 солов в месяце, да? Я немного путаюсь во всех этих ваших неметрических то 12-ти, то 60-тиричных системах времени. Впрочем, перейдём к делу.

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

Условие задачи

Есть набор данных с ценами на товары (prod_id) на складах (stock_id). Причём цены бывают настоящие (R=Real), а бывают рекламные (P=Promo). Для каждой цены есть дата начала действия. Нужно к каждой строчке набора вытащить реальную цену, которая является последней по дате настоящей ценой (price1) с типом 'R' на этот товар на соответствующем складе.

Вот начало запроса с тестовыми данными в виде CTE, на которых можно потренироваться:

with price(stock_id, prod_id, start_date, kind, price1, cost1, bonus1) as (values (1,1,to_date('2000-01-01','YYYY-MM-DD'),'R',100.0,32.12,6.49),       (1,1,'2000-01-02','P', 80.0, 0,   0),       (1,1,'2000-01-03','P', 70.0, 0,   0),       (1,1,'2000-01-04','R',110.0,33.48,6.19),       (1,1,'2000-01-05','P', 90.0, 0,   0),       (1,1,'2000-01-06','R',120.0,41.22,6.19),       (1,1,'2000-01-07','P', 80.0, 0,   0),       (1,1,'2000-01-08','P', 90.0, 0,   0),       (1,1,'2000-01-09','R', 93.0,36.87,6.49),       (1,1,'2000-01-10','R', 94.0,36.85,6.99),       (1,2,'2000-01-01','R',101.0,52.06,9.00),       (1,2,'2000-01-02','P', 81.0, 0,   0),       (1,2,'2000-01-03','P', 71.0, 0,   0),       (1,3,'2000-01-04','R',111.0,64.96,4.50),       (1,3,'2000-01-05','P', 92.0, 0,   0),       (1,3,'2000-01-06','R',122.0,66.83,4.60),       (1,3,'2000-01-07','P', 82.0, 0,   0),       (1,3,'2000-01-08','P', 92.0, 0,   0))select ...

Должно получиться что-то вида:

 stock_id | prod_id | start_date | kind | price1 | cost1 | bonus1 | price1x ----------+---------+------------+------+--------+-------+--------+---------        1 |       1 | 2000-01-01 | R    |  100.0 | 32.12 |   6.49 |   100.0        1 |       1 | 2000-01-02 | P    |   80.0 |     0 |      0 |   100.0        1 |       1 | 2000-01-03 | P    |   70.0 |     0 |      0 |   100.0        1 |       1 | 2000-01-04 | R    |  110.0 | 33.48 |   6.19 |   110.0        1 |       1 | 2000-01-05 | P    |   90.0 |     0 |      0 |   110.0        1 |       1 | 2000-01-06 | R    |  120.0 | 41.22 |   6.19 |   120.0        1 |       1 | 2000-01-07 | P    |   80.0 |     0 |      0 |   120.0        1 |       1 | 2000-01-08 | P    |   90.0 |     0 |      0 |   120.0        ...

Особенности же тут вот в чём. Я не зря радировал выше источник данных, потому что не таблица тут у нас, а вьюха, собранная из самых разных и зачастую совершенно неожиданных источников, откуда всякие промо-цены и берутся. То есть primary key для строчек не только нету, но и даже суррогатный-то на лету не так сразу получишь, так как никаких CTID (или там ROWID) в помине нету... Второй нюанс это тут я оставил только колонки price1, cost1 и bonus1, а в настоящем источнике данных много всяких характеристик нужно было вытащить из последней 'R'-строки, так как на рекламных строках эти данные отсутствуют. И не спрашивайте, почему так бизнесу виднее. Считайте расширенным условием задачи выбрать все эти поля из последней R-записи.

Задачу эту можно решать разными способами. Начнём с самого простого:

Первый подход

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

select * -- выбрать все поля из источника данных       -- а тут подзапрос, выбирающий нужную цену     , (select price1          from price sub         where sub.stock_id = p.stock_id -- те же склад           and sub.prod_id  = p.prod_id  -- и товар,           and sub.kind = 'R'            -- оставим только настоящие цены           and sub.start_date <= p.start_date  -- с датой более ранней или такой же,         order by start_date desc        -- отсортируем в порядке последние цены раньше         limit 1                         -- и возьмём только первую строку       ) as price1x  from price p;

Всё очень прямолинейно и просто, комментарии объясняют, что и как выбирается. Самое главное обеспечить, чтобы такой подзапрос возвращал не более одной записи, а то будет ошибка. Попутно отметим, что если записей не нашлось, что запрос вернёт NULL. В принципе это логичное поведение, но если дальше эти цены будут участвовать в каких-то расчётах, то это надо будет принять во внимание.

Отлично, мы сделали это! Запускаем! Можно расслабиться, прыснуть себе чего-нибудь зободробительного в жвалы, сделать первый (и самый вкусный) гулп... И пока запрос работает, давайте немного отвлечёмся и поразмышляем об его эффективности.

Итак, по условию у нас исходным набором данных была сборная вьюха. Что она там и как выбирает и не перелопачивает ли для этого полбазы неизвестно. Но сборная вьюха и эффективность это обычно понятия плохо совместимые. То есть ожидания от вьюхи что она тормознутая. И второй неутешительный вывод, который просто напрашивается: сборная вьюха практически не оставляет надежд на наличие индексов, так что в подзапросе, чтобы найти нужный склад и нужный товар на нём, скорее всего придётся прочитать всю вьюху целиком. На каждый подзапрос. А если она в самом деле полбазы вычитывает? Миллион строк, да для каждой полбазы перечитать... Вот так на ровном месте и без использования каких бы то ни было спецсредств можно поставить на колени практически любую базу. И мы получим highload на ровном месте. Вернее в highload это превратится, если оптимизатор найдёт способ распараллелить выполнение запроса, так что может быть всё ещё не так уж плохо. У меня на тестовых данных, кстати говоря, сумел.

А ну-ка запустим в соседнем окошке select count(*) from price и внимательно посмотрим как на количество записей, так и на время исполнения. Потому что именно эти два числа нужно будет умножить друг на друга, чтобы прикинуть общее время выполнения запроса. Наш запрос будет работать хоть сколько-нибудь обозримое время, только если количество записей не будет превышать десятков или сотен, ну максимум тысяч записей. Так что полюбовались на количество записей, и давай, тяни свои ложноножки (или ложноручки, что там у тебя) к консоли и прерывай запрос, пока не прилетели админы, чтобы убедительно объяснить на пальцах, что надо и что не надо делать на боевом сервере.

Подход второй

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

Это в целом годный и рабочий способ, исходная вьюха скорее всего будет прочитана только два раза, если вдруг оптимизатор не найдёт более эффективный план выполнения (что вряд ли) или банально не ошибётся. Это даст хорошую производительность, но... Что же но? Почему не хочется так делать? А всё очень просто. Такая конструкция в виде соединения двух наборов данных с витиеватыми условиями, включая выборку только нужных данных, довольно капризна. В этих декартовых соединениях легко ошибиться и потерять часть исходных данных или наоборот, выбрать чего-то лишнего.

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

Так что оставим этот способ напоследок, а сперва попробуем способ получше, и это...

Подход третий

Что там у нас сделать-то надо было? Сгруппировать и для каждой группы выбрать значение?.. Ба, да сюда же прямо просятся аналитические функции! Они как раз предназначены для подобных задач, когда нужно что-то сгруппировать и выбрать для каждой группы. Если при этом нужно оставить только значения для каждой группы, то используются аналитические функции, а если нужно сохранить весь исходный набор данных то оконные.

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

select *     , agg_func(...) over (...) -- тут нужно будет определить окно и найти подходящую функцию  from price

Казалось бы всё просто. Функция будет из тех, которые возвращают одно из значений в группе, это first_value() или lag() или что-то подобное. А вот с определением окна нужно немного помудрить. Оконные функции позволяют определять окно, указав группировку и сортировку. Понятно, что в определении окна будет partition by stock_id, prod_id и что-то надо добавить, чтобы ближайшая предыдущая строчка с реальной ценой встала на фиксированное место в этой группе. Если это не получается сделать в лоб (как, например, если бы нам надо было выбрать просто самую первую или минимальную цену), то обычно помогает такой приём, когда определяют специальное вычислимое поле и по нему делают или группировку, или сортировку. Навскидку пишем case when kind='R' then, потому что от поля kind у нас точно есть зависимость, и задумываемся... Мнэ...

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

Решение постепенно нашлось, и вот какой приём при этом был применён. Получилась двухходовка. На первом этапе формируем специальное вычислимое поле, по которому на втором этапе уже выбираем нужные значения. Поле (назовём его уровнем цены) формируем так: суммируется нарастающим итогом для каждого склада и товара в порядке даты начала действия следующее: единица для строк с kind='R' и ноль для всего остального. Получается как раз, что уровень цены перещёлкивается на следующий, как только мы встречаем реальную цену:

select *     , sum(case when kind='R' then 1 else 0 end) -- сумма нарастающим итогом       over(partition by stock_id, prod_id       -- в разрезе складов и товаров            order by start_date                  -- порядок важен!            rows between unbounded preceding and current row) as lvl -- нам нужно именно до CURRENT ROW  from price

Теперь осталось только оконной функцией выбрать самое первое значение в каждой такой группе:

select *     , first_value(price1) over (partition by prod_id, stock_id, lvl                                     order by start_date) as price1x  from (select ...)

Собрать вместе можно хоть через подзапрос, хоть с CTE. Смотрим на результаты выполнения вычисляется за один проход, то есть в высшей степени эффективно (достат кол!).

Итого, вот оно решение:

select p.*     , first_value(price1) over (partition by prod_id, stock_id, lvl                                     order by start_date) as price1x  from (select *             , sum(case when kind='R' then 1 else 0 end)               over(partition by stock_id, prod_id order by start_date                    rows between unbounded preceding and current row) as lvl  from price) p

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

select *     , first_value(price1) over w as price1x     , first_value(cost1)  over w as cost1x  from (select *             , sum(case when kind='R' then 1 else 0 end)               over(partition by stock_id, prod_id order by start_date                 rows between unbounded preceding and current row) as lvl          from price) pwindow w as (partition by prod_id, stock_id, lvl order by start_date)

Вот собственно и всё, на этом можно закончить, реализация второго подхода не понадобилась.

Выводы

  1. Во время составления SQL-запроса имеет смысл думать про эффективность его работы.

  2. Использовать оконные функции отличная идея.

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

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

Разбор решений, приведённых в комментариях

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

Так или иначе я насчитал 11 разных вариантов решения от 10 представителей. Вообще запросов было приведено больше, но часто следующий SQL-запрос в цепочке комментариев был развитием или исправлением предыдущего. Так что количество сильно зависит от того, как считать. Пройдёмся по хронологии.

Статья с условием задачи была опубликована 16 марта 2021 в 17:12. Первое решение от @nice17 16 марта 2021 в 17:34 было предложено уже через 22 минуты после публикации статьи (22 минуты, Карл! и ещё же надо было хоть по диагонали прочитать условие). Решение было неверным, но подход к решению явно был уже в нужном направлении. Чуть позже автор довёл его до правильного. А первое более-менее работающее решение (от @ZMB138 16 марта 2021 в 19:07) появилось меньше чем через два часа(!) после публикации, это была реализация подхода 2.

Первое решение в третьем подходе от @Kilor появилось ещё спустя полчаса 16 марта 2021 в 19:39. Автор применил хитрый ход, использовав функцию array_agg(), которая допускает использование FILTER в определении окна, что позволило отфильтровать только записи с реальными ценами и избежать рассмотренной мной двухходовости. Также продемонстрирован интересный ход, что вся найденная для сопоставления строка таблицы упаковывалась в JSON, из которого дальше выбиралось нужное поле. Или все нужные поля. Не очень универсально в плане разных диалектов SQL, но изящно. Последняя версия запроса от 17 марта 2021 в 10:18 уже без упаковки/распаковки в JSON получилась компактной и эффективной.

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

Аналогичный подход использовал @AngelloreA в запросе от 16 марта 2021 в 22:30. Сопоставляемая строка с реальными стоимостями упаковывалась правда не в JSON, а просто в текст, что потенциально чревато проблемами при распаковке (надо бы явно указать форматы), но это работает и тоже в один проход, то есть получилась реализация подхода 3.

@viras777 16 марта 2021 в 23:07 привёл необычное решение, где весьма остроумно для генерации уровней цены используется последовательность. В целом, как мне кажется, использовать последовательность для такого случая избыточно (да и Оккам не велел), плюс побочных эффектов в программировании обычно стараются избегать, но тем не менее оно работает.

@AlexKadetov уже 16 марта 2021 к 23:10 получил по сути такое же решение в подходе 3, к которому пришёл и я, пусть даже и с некоторыми огрехами в реализации. Вообще огрехи в реализации были много у кого, я старался не придираться, потому что в реальной жизни конечно всякий запрос ещё какое-то время доводится до кондиции, уточняется его работа и всё подобное вылавливается и исправляется.

Ночью @qvan 17 марта 2021 в 01:39 привёл несколько тяжеловесное, но рабочее решение в подходе 2. Утром @xxxcoltxxx 17 марта 2021 в 09:13 привёл более явное и ясное решение в реализации подхода 2. Чуть позже @jayrumi 17 марта 2021 в 13:11 тоже опубликовал своё пусть и несколько тяжеловесное, но работающее решение тоже в подходе 2.

Дальше опять вернулся @Kilor и 17 марта 2021 в 14:30 привёл пару красивых решений в подходе 2, продемонстрировав виртуозную технику JOIN-ов наборов данных. Ближе к вечеру @Miha_S7 17 марта 2021 в 18:19 привёл своё решение в подходе 3, повторяющее полученное мной в первой части статьи.

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

Итого, из интересного отмечу скорость, с которой тема была раскрыта со всех сторон, включая диалекты дружественных СУБД. Плюшкополучателем был избран @Kilor, как автор самого первого однопроходного решения (в подходе 3), а также за проявленную широту охвата техники владения SQL (использование оконных функций, JSON, FILTER, JOIN-ы) и ясную по форме реализацию с использованием всего перечисленного. С ним я уже связался. Специально отмечу самое первое работающее решение от @ZMB138, оригинальность и неожиданность использования последовательностей от @viras777, а также эталонное на мой взгляд решение от @AlexKadetov.

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

Подробнее..

Отказоустойчивый кластер PostgreSQL с помощью crm

08.06.2021 14:19:38 | Автор: admin
Автор Игорь Косенков, инженер postgres Professional

Привет всем! Сегодня речь пойдет о кластере. Да, снова об отказоустойчивом кластере на базе Corosync/Pacemaker. Только настраивать мы его будем не как обычно с помощью утилиты pcs, а с помощью мало используемой утилиты crm.

С точки зрения использования этих утилит (pcs и crm) весь мир Unix-like операционок делится на два вида:
  • содержит пакеты утилиты pcs (RHEL, CentOS, Debian, Ubuntu);
  • содержит пакеты утилиты crm (SLES, Opensuse, Elbrus, Leningrad и т.д.).

crm cluster resource manager специальная утилита, которая используется для создания и управления отказоустойчивым кластером. Она включена в пакет crmsh, который обычно не входит в состав самых распространенных дистрибутивов Linux.

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

В то же время, если спросить у поисковика про утилиту настройки кластера pcs, которая является по функционалу такой же утилитой, как и crm, то информации будет много. Есть даже несколько статей на Хабре (в том числе и моя статья Кластер pacemaker/corosync без валидола).

Утилита crm такая же мощная и гибкая, как и pcs, но незаслуженно обделена вниманием.

Решено было исправить этот пробел и написать статью.

Причины, по которым те или иные разработчики дистрибутивов предпочитают кто crm, а кто pcs, мне неизвестны. Могу предположить, что все дело в зависимостях. Например, если сравнить количество зависимостей у pcs и crm, то получается такая картина:
$ sudo rpm -qpR crmsh-3.0.1-1.el7.centos.noarch.rpm | wc -l19$ sudo rpm -qpR pcs-0.9.169-3.el7.centos.x86_64.rpm | wc -l50

Сторонники минимализма, скорей всего, предпочтут crmsh. А если еще учесть, что pcs тянет за собой ruby, openssl, pam и python, а crmsh только python, то выбор в некоторых случаях будет однозначно на стороне crm. В каких случаях? Ну, например, при сертификации ОС есть некоторые трудности с пакетом ruby. Также известны случаи, когда в банковских структурах служба безопасности не разрешает установку нерегламентированного ПО.

Сходства и различия


У утилиты crm есть как сходства, так и различия с известной всем утилитой pcs.
Сходства утилит приведены в таблице 1:



На этом сходства заканчиваются и дальше идут различия, которых много, поэтому привожу лишь некоторые из них (таблица 2):



Различия начинаются с самого начала с момента инициализации кластера. Инициализировать кластер с помощью crm можно одной командой, а у pcs это происходит в два этапа авторизация и инициализация.

Удалить кластер (разобрать) у pcs можно одной командой сразу, а у crm необходимо удалять по одному узлу до тех пор, пока их не останется в кластере.

Чтобы изменить параметры ресурса, который мы уже создали в кластере, у pcs есть опция update. У crm такой опции нет, но есть команда configure edit, которая позволяет менять любые настройки кластера налету и мгновенно. Даже больше мы можем за один прием отредактировать любое количество параметров и ресурсов, и в конце редактирования применить все изменения сразу. Удобно? Думаю, да.

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

У crm в стандартной поставке нет веб-инструмента, но зато он есть в коммерческой версии SUSE HAWK.

Подготовка к настройке отказоустойчивого кластера


Лучший способ узнать и познакомиться с crm это настроить отказоустойчивый кластер.

Чем мы сейчас и займемся. Для примера возьмем ОС CentOS 7.9.

Для создания отказоустойчивого кластера PostgreSQL нам понадобится стенд, состоящий из 3-х узлов node1, node2, node3. На каждом узле установлена ОС CentOS 7.9 и пакеты corosync, pacemaker, fence-agents* (агенты фенсинга).

В качестве СУБД будем использовать Postgres Pro Standard v.11, но вы можете с таким же успехом использовать ванильную версию PostgreSQL. В нашей системе установлены необходимые пакеты postgrespro-std-11-server, postgrespro-std-11-libs, postgrespro-std-11-contrib, postgrespro-std-11-client.

Настройки СУБД (postgresql.conf) и доступа к ней (pg_hba.conf) не рассматриваются в данной статье, информации об этом достаточно в интернете. На одном из узлов (например, node1) необходимо инициализировать базу данных с помощью initdb, а на двух других узлах с помощью pg_basebackup скопировать базу данных с node1.

Кроме того, в будущем кластере должны быть настроены синхронизация времени на узлах и разрешение имен узлов в кластере с помощью файла /etc/hosts.

ПРИМЕЧАНИЕ:
В этом разделе все команды необходимо выполнить на всех узлах кластера.
Поскольку пакет crmsh не входит в состав дистрибутива ОС, то необходимо подключить репозиторий
Extra OKay Packages for Enterprise Linux с этим пакетом.
node1,2,3$ sudo rpm -ivh http://repo.okay.com.mx/centos/7/x86_64/release/okay-release-1-5.el7.noarch.rpm

Нам также понадобится репозитарий EPEL:
node1,2,3$ sudo yum install epel-releasenode1,2,3$ sudo yum update

Устанавливаем пакет crmsh:
node1,2,3$ sudo yum install crmsh

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

Разработчики crmsh вставили код вызова этой кластерной утилиты для удобства настройки. Можно, конечно, обойтись и без csync2, но в таком случае будет больше ручной работы с конфигурационными файлами на каждом узле.

ОТСТУПЛЕНИЕ:
Сервис csync2 может использоваться не только для создания отказоустойчивого кластера Corosync/Pacemaker. Например, если есть несколько серверов, у которых меняются конфигурационные файлы и эти файлы периодически нужно синхронизировать по критерию самый свежий файл.


Итак, устанавливаем csync2 и простейшую базу данных для хранения мета-данных (sqlite).
$ sudo yum install csync2 libsqlite3x-devel

Тут нас поджидает подводный камень.

Поскольку csync2 и crmsh не являются родными для CentOS, то без дополнительных танцев сразу после установки они не заработают. Вызов crm влечет вызов утилиты csync2, которой в свою очередь не хватает парочки systemd-юнитов. Почему этих файлов нет в пакете csync2 для CentOS мне неизвестно. Замечу, что в коммерческом дистрибутиве SLES (crmsh там родной) все необходимые файлы есть, все работает из коробки сразу после установки пакетов.
Итак, создадим и добавим недостающие systemd-юниты.
Первый называется csync2.socket и содержит:
[Socket]ListenStream=30865Accept=yes[Install]WantedBy=sockets.target

Второй называется csync2@.service с таким содержимым:
[Unit]Description=csync2 connection handlerAfter=syslog.target[Service]ExecStart=-/usr/sbin/csync2 -i -vStandardInput=socketStandardOutput=socket

Оба файла нужно разместить в стандартной папке systemd /usr/lib/systemd/system.

Юнит, относящийся к сокету, нужно активировать и установить в автозапуск при загрузке ОС:
node1,2,3$ sudo systemctl enable --now csync2.socket

Примечание. Все настройки выполнялись для ОС CentOS, но есть подозрение, что эти действия также понадобятся и для других систем, например, для Debian или Ubuntu.

Теперь у нас все готово к началу работ по настройке кластера.

Настройка кластера с помощью crm


Настройка кластера производится в 2 этапа инициализация, затем создание и добавление ресурсов. Инициализация кластера с настроенным сервисом синхронизации конфигураций csync2 производится на одном узле.

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

На всякий случай сначала удалим кластер (на всех узлах) с помощью такого набора команд:
node1,2,3$ sudo systemctl stop corosync;sudo find /var/lib/pacemaker/cib/ -type f -delete; sudo find -f /etc/corosync/ -type f -delete

Далее надо выполнить команду инициализации кластера:
node1$ sudo crm cluster init --name demo-cluster --nodes "node1 node2 node3" --yes

где demo-cluster название нашего кластера.

По этой команде создаются необходимые файлы в папке /etc/corosync: corosync.conf, ключ авторизации authkey, а также прописываются ssh-ключи для беспарольной авторизации и выполнения команд в кластере с привилегиями суперпользователя root (на всех трех узлах кластера).

По умолчанию инициализация кластера выполняется в режиме multicast. Но есть также возможность проинициализировать кластер в режиме unicast:
node1$ sudo crm cluster init --unicast --name demo-cluster --nodes "node1 node2 node3" --yes

Кластер проинициализирован и запущен.
Проверить работоспособность можно с помощью консольного монитора состояния кластера crm_mon:
node1$ sudo crm_mon -Afr

Далее можно приступать к созданию ресурсов в кластере.

Создание ресурсов в кластере


Для начала поменяем некоторые значению по умолчанию. Например, порог миграции ресурсов migration-threshold по умолчанию равен 0. Меняем на 1, чтобы после первого сбоя ресурсы мигрировали на другой узел.

node1$ sudo crm configure rsc_defaults rsc-options: migration-threshold=1 resource-stickiness=INFINITY

По умолчанию, кластер запускается в симметричном режиме.

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

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

Зачем это нужно? Ну, например, в ситуации, когда в кластере ресурсы запускаются не на всех узлах, т.е. узлы неравноценны по ресурсам и назначению.

Если, вдруг, вам когда-то понадобится изменить режим кластера с симметричного на несимметричный, то достаточно ввести команду:
node1$ sudo crm configure property symmetric-cluster=false

Мы оставим этот параметр без изменения.

Включаем механизм stonith:
node1$ sudo crm configure property stonith-enabled=yes

Создадим и добавим ресурс виртуальный IP адрес:
node1$ sudo crm configure primitive master-vip IPaddr2 op start timeout=20s interval=0 op stop timeout=20s interval=0 op monitor timeout=20s interval=10s params ip=<virtual IP> nic=eth0

где <virtual IP> виртуальный IP-адрес в кластере.

С помощью монитора состояния кластера crm_mon можно убедиться в том, что ресурс успешно создан и запущен на первом попавшемся узле:
node1$ sudo crm_mon -Afr

Создадим ресурс postgresql и назовем его pg:
node1$ sudo crm configure primitive pg pgsql op start interval=0 timeout=120s op stop interval=0 timeout=120s op monitor interval=30s timeout=30s op monitor interval=29s role=Master timeout=30s params pgctl="/opt/pgpro/std-11/bin/pg_ctl" psql="/opt/pgpro/std-11/bin/psql" pgdata="/var/lib/pgpro/std-11/data" pgport="5432" repuser=postgres master_ip=<virtual IP> rep_mode=sync node_list="node1 node2 node3"

ПРИМЕЧАНИЕ:
В данном примере пути расположения бинарников и БД указаны по умолчанию для версии Postgres Pro Std 11. Также для упрощения указан пользователь для репликации postgres. Но ничто не мешает вам изменить умолчательные пути и пользователя репликации на свои.


Хочу обратить внимание на параметр rep_mode: он задан sync. Это означает, что в отказоустойчивом кластере хотя бы одна реплика будет синхронной. Синхронность реплики в кластере обеспечивает RPO=0 (кластер без потерь данных в случае сбоя).

Зададим тип ресурса Master-Standby (ms):
node1$ sudo crm configure ms mspg pg meta target-role=Master clone-max="3"

Нам нужно, чтобы ресурсы vip-master и mspg в режиме мастер запускались на одном узле:
node1$ sudo crm configure colocation pgsql-colocation inf: master-vip:Started mspg:Master

Указываем порядок запуска ресурсов сначала СУБД в режиме мастер, потом виртуальный IP:
node1$ sudo crm configure order order-promote-pgsql Mandatory: mspg:promote master-vip:start

Таким образом, мы создали 2 необходимых ресурса виртуальный IP адрес и ресурс postgresql.

Теперь можно переходить к настройке фенсинга в отказоустойчивом кластере.

Фенсинг узлов


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

Для начала можно ознакомиться со списком всех агентов фенсинга:
node1$ sudo crm ra list stonith

На моем стенде node1, node2, node3 это виртуальные машины, которые запущены и управляются с помощью гипервизора KVM. Соответственно, ресурс-агент фенсинга для KVM называется fence_virsh.

Вывести полную информацию о fence_virsh:
node1$ sudo crm ra info stonith:fence_virsh

Прежде чем создавать ресурс фенсинга, рекомендую проверить работоспособность всей цепочки от ОС виртуалки до гипервизора.

Проверка работоспособности фенсинга для узла node1 выглядит так:
node1$ fence_virsh -a <hypervisor IP> -l <username>-p <password> -n node1 -x --use-sudo -o status

где username & password учетная запись на хосте гипервизора.

Фенсинг для node1 настраивается так:
node1$ sudo crm configure primitive fence-node1 stonith:fence_virsh params ipaddr=<hypervisor IP> ip=<hypervisor IP> login=<username> username=<username> passwd=<password> pcmk_host_list=node1 sudo=1 op monitor interval=60s

ПРИМЕЧАНИЕ:
Ресурсы фенсинга не должны запускаться на своих узлах, иначе фенсинг может не сработать.

Следующее правило расположения запретит ресурсу фенсинга для узла node1 располагаться на этом узле:
node1$ sudo crm configure location l_fence_node1 fence-node1 -inf: node1

Для node2:
node1$ sudo crm configure primitive fence-node2 stonith:fence_virsh params ipaddr=<hypervisor IP> ip=<hypervisor IP> login=<username> username=<username> passwd=<password> pcmk_host_list=node2 sudo=1 op monitor interval=60snode1$ sudo crm configure location l_fence_node2 fence-node2 -inf: node2

Для node3:
node1$ sudo crm configure primitive fence-node3 stonith:fence_virsh params ipaddr=<hypervisor IP> ip=<hypervisor IP> login=<username> username=<username> passwd=<password> pcmk_host_list=node3 sudo=1 op monitor interval=60snode1$ sudo crm configure location l_fence_node3 fence-node3 -inf: node3

Можно написать скрипт, который будет содержать все команды сразу, останется только его выполнить. Но сегодня наша цель не автоматизация создания кластера, а изучение crm.

Инициализация кластера с помощью crm без csync2


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

Сначала вариант с использованием multicast.

Все команды выполняются на одном узле, например, на node1.
node1$ sudo crm cluster init --name demo-cluster --nodes "node1" --yes

По этой команде создаются необходимые файлы в папке /etc/corosync: corosync.conf, ключ авторизации authkey.

Далее нужно скопировать авторизационный файл authkey и corosync.conf на узлы node2 и node3:
node1$ sudo scp /etc/corosync/{authkey,corosync.conf} node2:/etc/corosync/node1$ sudo scp /etc/corosync/{authkey,corosync.conf} node3:/etc/corosync/

На остальных узлах (на node1 кластер уже запущен) запустить кластер:
node2,3$ sudo crm cluster start<source>С помощью монитора crm_mon можно убедиться, что кластер проинициализирован и запущен:<source lang="sh">node1$ sudo crm_mon -Afr


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

Все команды выполняются на одном узле, например, на node1.
node1$ sudo crm cluster init --unicast --name demo-cluster --nodes "node1" --yes

Открываем файл /etc/corosync/corosync.conf и добавляем строки в секцию nodelist:
node {ring0_addr: node2nodeid: 2}node {ring0_addr: node3nodeid: 3}

В секции quorum меняем число голосов:

expected_votes: 3

Далее необходим рестарт сервиса corosync на первом узле:
node1$ sudo systemctl restart corosync

Затем нужно скопировать файл authkey и отредактированный corosync.conf на узлы node2 и node3:
node1$ sudo scp /etc/corosync/{authkey,corosync.conf} node2:/etc/corosync/node1$ sudo scp /etc/corosync/{authkey,corosync.conf} node3:/etc/corosync/

На остальных узлах (на node1 кластер уже запущен) запустить кластер:
node2,3$ sudo crm cluster start

С помощью монитора crm_mon можно убедиться, что кластер проинициализирован и запущен:
node1$ sudo crm_mon -Afr

На этом инициализация кластера без csync2 закончена.

Вспомогательные команды crm



При работе с кластером могут пригодиться некоторые crm-команды.
Для удобства команды и пояснения сведены в таблицу 3:



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

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru