![](https://habrastorage.org/webt/nm/a4/wl/nma4wlhw56ui7y4vd4rn6-ftg6w.jpeg)
Привет всем уже в 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: первое знакомство».
![](https://habrastorage.org/webt/sd/nj/ct/sdnjcthsnq6rdibyxcqhnmgihzq.jpeg)
Книжечка проапгрейдилась до версии PostgreSQL 13. В бумажном виде она, как и раньше, будет раздаваться на конференциях, которые проходят с участием Postgres Professional. PDF можно скачать.
DEV2: Разработка серверной части приложений PostgreSQL 12. Расширенный курс.
Напоминаем о появившемся курсе. Задача его не просто познакомить с базовыми функциями PostgreSQL, но и научить пользоваться его расширяемостью: дополнять серверные механизмы собственным кодом.
Митапы и подкасты
Постгрес-вторник с Петром Зайцевым
Петра Зайцева, основателя Percona, Николай Самохвалов и Илья Космодемьянский зазывали на свои Вторники целый год. Свершилось. Был разговор о компании (из которого выяснилось, что сейчас в компании около 300 сотрудников, из них человек 50 постгресистов); о причинах дрейфа компании от MySQL и MongoDB в сторону PostgreSQL (не по любви, и не из-за технологических причин, а просто в это сторону двигались клиенты и потенциальные клиенты); о разной атмосфере в комьюнити MySQL, MongoDB и PostgreSQL (второе самое монополистическое, а третье — самое открытое). Но гвоздь программы — перконовская утилита мониторинга pg_stat_monitor.
Монитор опирается на расширении pg_stat_statements, но добавляет некоторую функциональность. Можно, например, посмотреть тексты запросов, отбирающих много ресурсов, сравнить прожорливость одного и того же запроса с разными планами; монитор знает название приложения, отправившего запрос. В этом контексте возник и разговор о новом расширении PWR (pgpro_pwr), вошедшем в Postgres Pro Standard и Enterprise 13. Это, кажется, обсудят на следующем Вторнике (мы же обещали статью о нём и обещание скоро сдержим).