Конференции
Приходите на PGConf.Russia 2023!
На Хабре появился этот анонс конференции (пройдёт 3-4 апреля) с описанием докладов, которые там будут, а на сайте конференции появилась сама программа конференции. Трудно выбрать, что протранслировать сюда. Пожалуй, пусть здесь будет 1:1 блок, посвящённый миграции:
О ней послушаем Максима Афиногенова, Дмитрия Умникова (Axenix), Василия Пучкова (Лукойл-Технологии), Антона Немцева (Нетрика), Владимира Сердюка (SoftPoint) и Альфреда Столярова (EvApps). Елена Скворцова (ИТ-Экспертиза) расскажет о миграции 1С. Максим Емелин из Postgres Professional расскажет о применении Debezium. Александр Любушкин и Андрей Чибук (Форс Телеком) поделятся своим опытом переноса больших объемов данных и представят разработанную для этого утилиту. Игорь Мельников представит новинку Postgres Pro - пакеты, почти как в Oracle.
Офлайн-иностранец будет один: Кристофер Треверс (Christopher Travers), которым многим по обе стороны Атлантики стал известен после лихой статьи Which is worse when working on production databases? Being drunk or tired? о которой мы писали в прошлом номере. На этой конференции он поговорит на сугубо технологические темы - сразу 2 доклада: PGConf.Russia 2023 - Crazy things you can do with PostgreSQL Indexes и PostgreSQL vs Redis: Making the Right Choice. Онлайновый ино-участник тоже один: Брюс Момджян, который представит свой доклад Beyond Joins and Indexes об исполнителе запросов PostgreSQL (онлайн). UPD: будет ещё один иностранный онлайн-участник - это Вигнешваран Си (Vigneshwaran C, Fujitsu), о его докладе есть ниже в разделе Репликация и бэкап.
Ещё некоторые доклады: О некоторых интересных исторических уязвимостей Postgres сделает доклад Андрей Бородин из Яндекс.Облако, Иван Фролков (Postgres Professional) на этот раз расскажет об использовании UUID различных версий в качестве первичных ключей и о том, что нового в Postgres по этой части, а Андрей Рудомётов (тоже Postgres Professional) передаст Привет от встроенного мультимастера! (Сравнение двунаправленной репликации в ваниле и Postgres Pro Multimaster).
От отдела образования Postgres Professional будут 2 доклада: Павел Толмачёв: Познакомимся с GEQO за 20 минут - о том, как работает генетический оптимизатор запросов в PotstgreSQL, и PostgreSQL 16: На финишной прямой - традиционный обзор новинок Павла Лузанова, который на этот раз будет открывать конференцию.
Будет, разумеется, и астрономический доклад - Экстремальная астрономия Владимира Липунова.
Пройдёт 12-го мая в Хаасроде, недалеко от Брюсселя. Приём докладов закончен, а регистрация продолжается. Докладчики ещё не объявлены.
PGConf.de 2023 и Swiss PGDay 2023
Немецкий PGConf пройдёт в Эссене 27-го июля. Продолжается регистрация. Интересный вид рекламы: организаторы говорят: заодно потом сможете съездить на Swiss PGDay 2023 на той же неделе - 29-30-го. Там можно подавать заявки на доклады до 17-го апреля, а на постеры, рядом с которыми можно вести пояснительную работу - до 15-го мая.
Раз уж зашла речь о Крисе Треверсе, офлайновом иностранном участнике конференции PGDay.Russia, то вот интервью с ним в еженедельнике Персоны Недели Андреаса Шербаума :
Chris Travers | PostgreSQL Person of the Week
Некоторые фрагменты:
- Откуда вы родом?
- Из США, пожалуй. Когда я был подростком, много мотался по Калифорнии, Мичигану, Юте, по Вашингтону (штату). В 2010-м я уехал за границу и с тех пор не возвращался. Жил в Индонезии, Швеции, Германии. Сейчас опять в Индонезии.
- Какими СУБД вы пользуетесь?
- Их много: MySQL, HBase, MongoDB, Redis, CouchDB, SQLite, Firebird, Neo4J и другие. PostgreSQL - моя любимая, но есть за что ценить и другие. Я считаю, что SQLite сильно недооценили. Пожалуй, по расширяемости софта управления базой это единственная СУБД, сравнимая в этом с PostgreSQL. Если вам нужна база, встроенная в ваше приложение, я, ни секунды не сомневаясь, посоветую SQLite.
Крис там говорит о том, что более известен статьями и докладами о человеческом факторе, но и о высоконагруженных системах ему есть что сказать - взять хотя бы доклад PostgreSQL at 20TB And Beyond на FOSDEM 4 года назад. Вообще-то, там он говорит даже не о 20, а о 400ТБ данных, которые можно использовать для аналитики почти в реальном времени. Этот доклад относится к периоду его работы в берлинской Adjust, о которой мы немного знаем по рассказам работающих там бывших коллег - Артура Закирова, например. В Adjust Крис возглавлял команду постгресистов. Сейчас работает в Timescale.
Крис говорит примечательную вещь: для постгрессиста важно уметь учиться [ну, это понятно - прим. редакции] и желание/способность думать, когда нужно, в духе формальной математической теории и логики. РСУБД реализуют математические модели, и SQL не лучший пример реализации такой математики. Если мы понимаем математику, лежащую под этим, мы сможем избежать многих ненужных проблем.
Что до соцсетей, то Крис предпосылает этим трём богатырям чёткое разделение труда:
linkedin - продуктивное общение по PostgreSQL,
Facebook - фото,
Youtube - там он делится своими собственными кулинарным шоу: кухня Западной Суматры, литовская кухня, итальянская. Планируются Ява и Бали, немецкая кухня.
Ну и заодно, пусть будет здесь статья Криса: Invoking (Your Own) Perl from PL/Perl.
Postgres Pro Enterprise 15.2.1
Отличия новой версии у Enterprise всегда двух видов: некоторые наследуют изменениям соответствующей версии PosstgreSQL (в данном случае 15.2 по сравнению с 15.1), а некоторые изменения суть отличия от предыдущей версии самого Enterprise (то есть 15.1.1). Об этом не надо забывать.
В PostgreSQL 15.2 закрыли дыру в безопасности CVE-2022-41862: Client memory disclosure when connecting, with Kerberos, to modified server. Она, соответственно, закрыта и в Enterprise 15.2.1. Об этом непосредственно не сказано в отличиях версии Postgres Pro Enterprise 15.2.1, но там говорится, что все изменения, унаследованные от PostgreSQL 15.2, описаны в Замечаниях к выпуску PostgreSQL 15.2. И там эта устранённая проблема сформулирована чуть более технологично, чем на postgresql.org: Устранение утечки содержимого памяти после сбоя инициализации шифрования трафика GSSAPI в библиотеке libpq.
По части собственно Enterprise есть новое:
добавлен параметр enable_large_mem_buffers, позволяющий копировать и выгружать значения типов
byteaиtextбольшого размера;улучшена производительность, ранее страдавшая из-за многочисленных сбросов кеша;
устранена ошибка сегментации, которая могла возникать в PL/pgSQL при попытке удалить отдельное поле составного типа после завершения автономной транзакции;
исправлена проблема, связанная со значительным потреблением памяти при оптимизации запроса, содержащего большое количество подзапросов
UNION ALL.
Кроме того, входящие в Enterprise модули и утилиты обновились до:
-
это были разработки Postgres Professional, а кроме этого ещё и
Анонимы и фейкеры
За классом программ, подменяющих данные при анонимизации, закрепилось словечко faker. Я не борец за чистоту русского языка, хотя меня иногда утомляют хейтеры, газлайтингеры и пр. Но вот фейкер - этого слова точно не хватает в современном русском. Ладно, к делу.
Появился анонимизатор pg-anonymizer. Он экспортирует базу, анонимизируя данные. То есть это статическая анонимизация. Задача у создателя - Рафаэля Юшэ (Raphaël Huchet aka rap2hpoutre) - была сделать простенький, легко инсталируемый инструмент, а не конкурировать в функциональности с существующими. Последняя версия - 0.7.0. Сейчас этот анонимизатор умеет:
выбирать столбцы для анонимизации (можно задать список);
функцию-фейкер можно выбирать;
можно пропускать указанные таблицы;
NULL можно не анонимизировать;
можно менять локали, которые использует фейкер;
можно импортировать анонимизированный SQL-файл через psql.
В конце этой странички есть любопытное замечание: раздел Why - чего ради затеяли ещё один анонимайзер. Потому, что существующие не понравились по разным причинам:
PostgreSQL Anonymizer - его трудно настраивать, да и вообще он неуклюжий для нехитрых задач - считает Рафаэль, - но всё же это лучшее решение из существующих.
pganonymize не работает со схемой данных, отличной от public, а также со столбцами с названиями, в которых есть символы верхнего регистра.
pgantomizer валится в простых ситуациях, да ещё и не сообщая об ошибке.
Про первый мы писали в выпуске Postgresso 2, когда рассказывали о недавно появившемся в Postgres Pro Enterprise 15 своём pgpro_anonymizer с похожим богатым набором функций. Второй - почти тёзка pg_anonymize Жюльена Руо (Julien Rouhaud), но он ещё в бета-фазе.
Расширение Postgres, основанное на Python Faker Library. Опять французского происхождения (Dalibo). Им пользуется М.Грамин в статье ниже.
AI + PG
Началось недавно, сейчас таких статей много, а будет их лавина. Делятся они грубо на 2 категории: в одних AI сочиняет SQL для запросов, в других PostgreSQL интегрирован в инфраструктуру AI.
Creating a SQL generator app with ChatGPT, PostgreSQL, and ToolJet
Тейджа Куммарикунтла (Teja Kummarikuntla) работает в ToolJet и в статье заодно хотел показать, как этот ToolJet хорош и удобен. Но задействует он и ещё одну сущность - ElephantSQL - PostgreSQL-as-a-Service в облаке. Общение с ChatGPT (GPT-3.5 Turbo) происходит через Rest API, который есть в этом ToolJet, запросы к SQL-Слону тоже посылаются через ToolJet.
Тейджа создаёт простенькую табличку с именем и возрастом. С запросами Покажи мне всех в этой таблице и Покажи мне тех, чьё имя начинается на D эта штука справляется.
А если делить не грубо, то первую задачу - помощь в кодировании - можно развернуть, как в статье How to Use ChatGPT to Write SQL JOIN Queries Хелены Александер (Helena Alexander, dbForge) на целый список задач:
SQL для DML и DDL;
помочь дебажить запросы, дать советы по исправлению ошибок и оптимизации, определение потенциальных проблем кода;
помочь информацией по синтаксису, ключевым словам и функциям;
превращать результаты запросов в отчёты на человеческих языках.
В статье, вообще-то, не PG, а MySQL, к которому подключаются, как можно догадаться, по dbForge, но не это главное. Хелена обращается к GPT (3) с подобающей вежливостью (не могли бы вы составить <такой-то> запрос), и сеть охотно (иногда начиная фразу с конечно) выдаёт запросы, реализующие виды джойнов INNER JOIN, LEFT JOIN, RIGHT JOIN, CROSS JOIN, FULL OUTER JOIN и SELF JOIN.
Кстати, поиск по теме даже находит расширение для Хрома - gpt2pg, авторства, видимо, Рауфа Чебри (Rauf Chebri). Он из Неона. Там происходит какая-то деятельность в этом направлении, ещё не оформившаяся в громкие анонсы и релизы. Есть, например, расширение PostgreSQL pg_gpt, которое может конвертировать вопросы на человеческом языке в SQL, а также пояснять сгенерированный SQL. И есть ask-neon - приложение, которое можно спрашивать по поводу PostgreSQL и Neon. Использует pgvector Эндрю Кейна (о нём мы писали в прошлом выпуске), автор - Прабин Ахария (Prabin Acharya aka pra6in), но следы тянутся тоже к Неону и его сооснователю Стасу Кельвичу.
И вот статья Рауфа на 11 минут чтения:
Building an AI-Powered ChatBot using Vercel, OpenAI, and Postgres
В статье есть диаграммы последовательности обмена сообщениями, много иллюстраций, код. Используются Edge Functions (отсюда Vercel в названии статьи), которые быстрее, чем бессерверные. Модель - text-davinci-003, способная принять 4096 токенов. Чтобы всё заработало, нужно:
получить вопрос (на человеческом языке) на входе;
генерировать эмбединги для вопроса при помощи OpenAI API;
вычислить дистанции между эмбедингами и вернуть контекст (пояснения в статье);
генерировать ответ, используя методы дописывания OpenAI.
pg_tiktoken: Postgres Extension for Fast BPE Tokenization
Это уже статья Стаса. BPE это эффективный алгоритм токенизации с кодированием пар байтов (Byte Pair Encoding). pg_tiktoken - обёртка вокруг токенайзера OpenAI, известного своим быстродействием при работе с естественно-языковыми задачами.
Итого: коллектив молодых и талантливых, кажется, серьёзно инвестирует усилия в это направление.
Генерация данных — творчество или рутина?
Максим Грамин написал дважды интересную статью: генерация текстовых данных и сама по себе тема интересная. Но он ещё и нагенерил их для разминки с помощью ChatGPT.
В ней он даже слегка пофилософствовал: Долгие годы люди стремились к всё более реалистичному изображению окружающих их вещей. Много лет прошло от симпатичных наскальных мамонтов до шедевров эпохи Ренессанса и Просвещения. Однако где‑то в 19-м веке (примерно, когда стала появляться первая фототехника, ага), что‑то пошло не так, и живопись сменила своё направление от реализма к абстракции. Дальше больше; и все «скатилось» до клякс, пятен и потёков, размазанных по холсту или любой другой поверхности стоимостью в миллионы долларов... И при этом зачастую совершенно было непонятно, кто автор «шедевра»: 3-х летний ребенок, маститый художник, нейросеть или кот, опрокинувший банку варенья.
В статье Максим решил доверить генерацию данных всё же не коту, а нейросети. И, хотя, на мой вкус, эта аналогия (назовём её для красоты аллегорией) неточна (генерация нужна именно что стохастически реалистичная - мамонты и человеки, просто не похожие на конкретных мамонтов и конкретных человеков), я лично приветствую такие лирические отступления. Но ближе к делу:
Максим берёт учебную схему Pagila (о парочке Pagila/Sakila мы рассказывали, например, здесь) и бесхитростно просит GPT сгенерировать SQL-скрипт для случайных данных в схеме Pagila. С этим заданием сеть, в общем, справляется, но Максим хочет большего. Поэтому, как ни странно, оставляет GPT в покое и дальше генерит скрипты сам, используя характерные конструкции сgenerate_series и md5(random()::text).Но сам себе не верит и пробует декартово произведение реальных имён на реальные фамилии, воспользовавшись вот этим.
Дальше он рассказывает о различных фейкерах (то есть можно было поместить эту статью в предыдущий раздел, но уж ладно) и ссылается на фейкеры для Java, Python, JS, Ruby. Всю статью пересказываеть не будем. Кстати, Максим - автор Malewicz (Postgres-клиент, я не пробовал, но за одно название можно многие недостатки - если есть - простить), поддерживает страницу Awesome DB Tools.
Репликация и бэкап
Inside logical replication in PostgreSQL: How it works
Вигнешаваран Си (Vigneshwaran C, Fujitsu) сетует, что его читатели не все присутствовали на его триумфе - докладе на PGConf India 2023, где была толпа народу, а сам доклад попал в 27 отбранных из 120 заявленных. И восполняет, пересказывая. Для первого знакомства действительно полезная статья: она удачно организована, наглядна. Вот её краткое (она и сама вполне краткая) содержание:
1. Вступление 2. Применения (use cases) 3. Архитектура 4. Публикации 5. Подписки 6. Процессы 7. Инкрементальная репликация 8. Обработка падения apply worker 9. Изменения в подписке (Altering a subscription) 10. Как работает synchronous_commit 11. Слот репликации 12. Фильтры строк 13. Список столбцов 14. Преимущества фильтров строк и списков столбцов 15. TABLES IN SCHEMA 16. Что читать дальше.
UPD: стало известно, что онлайн-доклад будет и на PGConf.Russia 2023. Он здесь называется Logical replication internals.
Introduction to Postgres Backups
Филип Хёрст (Philip Hurst) и Элизабет Кристенсен (Elizabeth Christensen) из Crunchy Data не врут: это действительно интро, самые первые шаги в изучении темы. Кроме pg_dump/pg_restore, base_backup и (конечно) pgBackRest, упоминаются WAL-E и WAL-G - в довольно неожиданном конетексте. Оказываетя, в Crunchy Data при создании Crunchy Bridge рассматривали оба варианта: WAL-G и pgBackRest: были сотрудники, поддерживавшие WAL-G, были и поддерживавшие pgBackRest. А свои изюминки есть у обоих решений. Но в конце концов выбрали pgBackRest.
The Tale of the 11TB Write Ahead Log
Под статьёй в блоге Adjust подписались трое - Артур Закиров (Artur Zakirov), Ихорь Сироштан (Ihor Siroshtan) и Андреас Шербаум (Andreas Scherbaum, теперь он глава департамента баз данных в Adjust). Они были подняты по тревоге: 80% NVMe-диска в 47ТБ забито, по расчётам осталось 30 часов. Пришлось отложить субботние дела и разбираться.
База нагенерила 11ТБ WAL в 1.3 млн. файлов. Это короткая (но поучительная) детективная история, поэтому спойлер: некорректно запустили pgBackRest. Подробности в статье.
Ещё один Крис
Everything you know about setting `work_mem` is wrong
Блог называется postgresql when it's not your job, то есть как бы любительский, Postgres как хобби. Но это кокетство: автор этого блога с адресом the build Кристоф Петтус (Christophe Pettus), гендир PostgreSQL Experts (PGX).
Кристофер шутит: если вы погуглите, как настроить work_mem в PostgreSQL, вы, скорее всего, найдёте что-то в этом роде:
Возьмите число соединений, добавьте 32, поделите на цифру, соответствющую вашему знаку зодиака (Водолей=1), конвертируйте в систему счисления по основанию 7. Готово! Прочитайте как обычное десятичное число, и вот она, нужная память в мегабайтах!
Но я спасу вас: ВСЕ формулы для work_mem лгут. Каждая формула лжёт. Не то, чтобы всегда чудовищно врёт, но, в лучшем случае, даёт первое приближение.
Что же предлагает сам Кристоф?
Предлагает итерации:
Установить по одной из формул, скажем: 50% свободной памяти + системные буферы, делить на число соединений.
Если производительность устраивает, оставить как есть.
Если нет, то заглянуть в логи, найти сообщения о создании врЕменных файлов, например таких [см в статье].
Если таких нет, оставить как есть.
Если есть, добавить памяти вдвое больше самого большого временного файла.
Это не на все случаи жизни. А вообще, пользуйтесь pgbadger , чтобы отслеживать подобные вещи, - советует Кристоф.
Домашние вдохновители PostgreSQL
После полугодового перерыва обновились PostgreSQL Pets. Очаровательный пёс принадлежит Джозефу Скьяррино/Шьяррино (Joseph Sciarrino). Интервью с ним есть в коллекции Андреаса Шербаума. Джозеф сооснователь WH Hydra, построенного на базе PostgreSQL. У него есть лицензия уличного скрипача, хотя он играл и в симфонических оркестрах. Но главное - у него есть Титус Котон де Тулеар (мадагаскарский бишон).
Предыдущими вдохновителями были:
Ещё один котик
Adopting PgCat: A Next-Gen Postgres Proxy
Напомним, что автор PG-кота - Лев Кокотов ака levkk, который поддерживает расширение pgml для машинного обучения. PgCat - пулер с шардингом, блансировкой нагрузки и аварийным переключением (failover). Но написал статью не создатель, а коллектив: Мостафа Абдельрауф, Зайн Кабани и Эндрю Теннер (Mostafa Abdelraouf, Zain Kabani и Andrew Tanner) из InstaCart. Им нужно горизонтально масштабироваться, но простое добавление реплик для чтения и/или шардирование не решало проблемы, а новых добавляло. Справлялись с Ruby-библиотекой Makara, но не хотелось привязываться к Ruby. Естественным решением стал PgBouncer. Им и пользовались, он всем (почти) хорош, но он не поддерживает failover и недостаточно гибко балансирует нагрузку.
Рассматривали ещё Yandex Odyssey. В результате в статье есть табличка с плюсами и минусами PgBouncer | PgBouncer с внешними средствами failover | Odyssey | PgCat. Победил Кот. В статье объясняют, почему. И что пришлось докрутить в Коте.
На сегодня всё, готовимся к конференции.
Kwisatz
Все как свихнулись на ИИ. В топку ии, дайте больше OLAP фичей!