09.10.2020 10:33
Igor_Le 0 2000 Источник


Жизнь продолжается. А мы продолжаем знакомить вас с самыми интересными новостями 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, Alvaro Herrera, Petr Jelinek, Simon Riggs, Tomas Vondra против Devrim Gunduz, 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, разумеется.

Arm’s 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