![](https://habrastorage.org/getpro/habr/upload_files/d8a/58d/c50/d8a58dc5049bc938014c296d442c324f.jpg)
Из жизни малышей и гигантов
Опенсорсный проект ElectricSQL явил маленькое чудо. Совсем маленькое: сервер PostgreSQL уместился в архив 3МБ.
Сервер собран как клиентская библиотека TypeScript/JavaScript, PostgreSQL можно запускать в браузере, Node.js и Bun, ничего больше инсталлировать не надо, всё есть. Имеется и некий API "live query", для реакции на изменения данных в таблицах. Утверждают, что обычные CRUD-запросы исполняются за 0.3 мс.
Ресурсы:
сайт;
репо;
каталог расширений (22 расширения Postgres, в том числе pgvector, и 1 плагин для PGlite - live);
Более того: компания Supabase уже запустила сайт postgres.new, построенный поверх PGlite. Мол, have fun.
PGlite реализован как WASM. WASM - это "ассемблер для веба". Вот, например, статья об этом на хабре за авторством Н.Зимина @nzeemin, "ленивого ведущего программиста": WebAssembly: что и как.
"Проблема эта — быстро исполнять код в браузере. Быстро — это значит, «быстрее чем JavaScript», в идеале настолько быстро, насколько позволяет имеющийся у нас процессор."
Вот PGlite и работает быстро, как положено WASM. В статье есть ещё некоторые критерии и история вопроса.
Информация о маленьком чуде появилось в виде этого сообщения на y-комбинаторе: Show HN: – in-browser WASM Postgres with pgvector and live sync. И уже обросло содержательными комментариями.
Ну а гиганты?
А вот. Из жизни НЕпостгресовых гигантов в данном случае. Мир Postgres уютный, хоть и большой. Но он часть вселенной. И Утиный раздел ниже - ещё одно окошко во внешний мир.
How Uber migrated Petabytes of Data with Zero Downtime
Uber это 10 млрд поездок в год. Они хранили транзакции оплаты поездок в AWS DynamoDB, но не все, а 12-недельные и свежее, остальные ("холодные") сбрасывали в TerraBlob, хранилище, разработанное в самом Uber, по архитектуре похожее на AWS S3. Вот там и лежали петабайты. В этой статье разъясняют, например, что такое "кошельковые СУБД" - ledger-style DBs. LedgerStore это тоже собственная разработка Uber. Миграцию они описали сами в своём блоге: Migrating Uber's Ledger Data from DynamoDB to LedgerStore. Автор - старший инженер по софту Uber Абхишек Канхар (Abhishek Kanhar).
Uber перенесла базу данных c 1 трлн записей из DynamoDB в LedgerStore
Это о том же. Автор ака @maybe_elf излагает суть не только одноименной англоязычной статьи, но и прошёлся по другим публикациям на эту тему. Есть интересные временнЫе диаграммы, описывающие такую интересную особенность LedgerStore:
LedgerStore поддерживает надёжные и согласованные индексы. Для строго согласованных индексов хранилище данных использует двухфазную фиксацию. Сначала оно сохраняет отступ в индексе, а затем — запись. Наконец, если запись успешна, намерение асинхронно фиксируется или откатывается в случае сбоя. Во время чтения любые записи с незафиксированными намерениями либо фиксируются (если чтение завершается успешно), либо удаляются (если чтение записи завершается неудачно) асинхронно. LedgerStore реализует в конечном итоге согласованные индексы, используя материализованные представления из собственной базы данных Docstore, распределённой БД, построенной на основе MySQL».
Ну вот, опять эта травматичная для нас MySQL: была когда-то неприятная новость, всколыхнувшая постгресовый мир - Why Uber Engineering Switched from Postgres to MySQL. Но это ж когда было-то ...
Релизы
А также PostgreSQL 16.4, 15.8, 14.13, 13.16, 12.20 (версия 12 заканчивает свой земной путь 14 ноября). По сравнению с 2-й бетой закрыта уязвимость и исправлено 55 багов.
Закрыли уязвимость, которую назвали CVE-2024-7348, она затрагивает версии 12 - 16: запустив зловредный SQL, можно подменить таблицу во время работы pg_dump (PostgreSQL relation replacement during pg_dump executes arbitrary SQL). Подробности есть в тексте релиза.
До этого, в PostgreSQL 17 Beta 2 тоже были некоторые изменения относительно 1-й беты, например:
теперь поведение по умолчанию
ON EMPTY
всегда корректно, если только оно не прописано в запросе SQL/JSON;поправлено владение ресурсами при использовании
pg_logical_slot_get_changes
;поправили новые структуры данных для обработки данных, связанных с вакуумом.
Вышла Postgres Pro Enterprise 16.3.2
Устранены две проблемы, которые могли возникать после выполнения обновления с PostgreSQL или Postgres Pro Standard с помощью pg_upgrade: исправлено вычисление базы xid
во время очистки страниц в куче и вычисление xmax
во время преобразования страниц из 32-битного в 64-битный формат. Эти проблемы не приводили к потере или повреждению данных, но вызывали ошибки уровня PANIC. И ещё некоторые исправления и улучшения.
Здесь же посоветую свежую статью Лохматого Мамонта (@Loxmatiymamont) об исследовании производительности PostgreSQL/Postgres Pro Enterprise: Продолжаем выжимать максимум из PostgreSQL, дополняющую сравнительные тесты Выжимаем максимум из PostgreSQL Максима (@Maksvelis), тестировщика в Selectel Lab.
Также рекомендуем ещё одну статью Лохматого по материалам разработок коллег.: С заботой о CPU: как найти узкое горлышко и сконфигурировать Postgres Pro. Эти статьи (и другие) мы планируем подробно рассмотреть в следующем выпуске.
Postgres Pro Enterprise Manager 1.5
1 июля состоялся релиз версии 1.5. В версии 9 изменений, вот некоторые:
Добавлена возможность PITR восстановления.
Добавлена страница с деревом блокировок.
Добавлена возможность управления настройками хранения резервных копий на уровне каталогов и экземпляров.
Добавлены страницы для отображения прогресса регламентных задач, на основе представлений pg_stat_progress_*
По PPEM много богато иллюстрированных материалов здесь.
Это СУБД новая и интересная, поэтому поподробней. Вообще документация по ней лежит в общем разделе документации, рядышком с PostgreSQL, Postgres Pro Standars/Enterprise и ora2pgpro.
Добавлена возможность создавать глобальную или сегментированную таблицу на основе другой глобальной, сегментированной или локальной таблицы. На данный момент есть ограничения на создание таблиц на основе локальных.
Добавлен параметр конфигурации enable_merge_append, который включает или отключает использование планировщиком планов
MergeAppend
. В частности позволяет отключить использование этих планов, если они слишком дорогие.Добавлен параметр конфигурации pgpro_stats.track_shardman_connections, который включает или отключает обработку операторов Shardman.
Удалено ограничение в 64 тысячи на количество таблиц в запросе.
К тому же теперь:
Добавлена возможность резервного копирования кластера с табличными пространствами. Теперь табличные пространства находятся в каталоге резервной копии.
Добавлена возможность восстанавливать полностью или частично работающий кластер из резервной копии, сделанной на частично работающем кластере, с использованием
shardmanctl probackup
.
В предыдущей версии - Postgres Pro Shardman 14.12.1 - тоже добавлены существенные вещи:
Добавлен параметр REMOTE команды EXPLAIN, который разрешает вывод EXPLAIN по запросам, выполняемым на удалённом сервере. По умолчанию включён.
Реализована собственная логика оценки стоимости планов. Она позволяет планировщику чаще выбирать общие планы при схожести общего и специализированного.
Добавлена поддержка исключения секций в процессе выполнения для узлов плана, выполняющих агрегацию данных на сторонних серверах. В первую очередь оптимизация необходима для устранения секций в общих планах.
В утилите управления устранены уязвимости CVE-2023-45288 и CVE-2023-44487.
Теперь немного о других релизах:
Главным отличием этой версии объявлена полная поддержка OreoleDB. До этого WAL-G умела делать инкрементальный бэкап на уровне блоков, но рассматривала данные OriolDB как набор файлов неизвестного происхождения. Теперь WAL-G распознаёт инсталлированный OrioleDB и копирует эффективно.
Такое внимание к OrioleDB закономерно и прогрессивно: интересная технология.
Ещё в этой версии появились 2 новые команды для Postgres: catchup-send
и catchup-receive
. Они очень помогают в ситуации отставания реплики.
Этот интересный инструмент для выявления уязвимостей в SQL-скриптах Postgres выложен на гитхабе Timescale. Автор - Свен Клемм (Sven Klemm) из Дрездена. Прежде всего pgspot призван выявить:
атаки через
search_path
,-
создание небезопасных объектов.
Есть документация и полезные ссылки: PostgreSQL security recommendations for extensions и PostgreSQL security recommendations for SECURITY DEFINER functions.
Сообщество
Announcing postgres-contrib.org
На официальном сайте сообщества (то есть postgresql.org) объявили о создании нового сайта, который будет специально посвящён вкладам в разработку - ещё одно следствие обсуждений в рассылках и уже действительно ключевого обсуждения на сессии Increase Community Participation в рамках PGConf.dev 2024.
Сразу объявили об участии известных в сообществе людей, поддержавших идею: Андреас Шербаум (Andreas Scherbaum), Борисс Мейяс (Boriss Mejías), Крис Эллис (Chris Ellis), Флоор Дреес (Floor Drees), Джимми Анджелейкос (Jimmy Angelakos) и Павло Голуб (Pavlo Golub) - почти все ссылки на этих людей ведут на сайт Андреаса Postgres Person of the Week. С тех пор участников прибавилось.
Вот сам сайт проекта: Contributions to the PostgreSQL Project. Там не только о коде (в ядро и в расширения/модули тоже), но и такие, например, новости:
Клер Джордано (Claire Giordano, Microsoft) запустила подкаст Talking Postgres. Сайт подкаста: Talking Postgres with Claire Giordano.
Postgres Выиграл Stack Overflow 2024 Developer Surway
С большим отрывом. В номинациях Самая Популярная База (49%), Самая Желанная (47%) и Самая Обожаемая (74%!).
Статьи
Миграция
Миграция с Oracle на PostgreSQL: подводные камни и инструменты для перехода
Это статья в блоге IBS, а написал её Александр Брейман, доцент Вышки и по совместительству эксперт Учебного центра IBS. Автор претендует на то, что этой статьей немного «очертил поляну» для дальнейшего изучения вопроса. Он рассматривает не только различия Oracle и PostgreSQL (об этом, честно говоря, говорилось много-много раз), не только кратко описывает опенсорсные инструменты миграции (ora2pg, orafce), но и предлагает использовать платный ora2pgpro, причём для миграции на PostgreSQL, а не на Postgres Pro, хотя и хвалит Enterprise за автономные транзакции, не забывая и о появившихся там pg_variables. В конце говорит вот такие приятные слова:
Отечественные разработчики проделали гигантскую работу и постарались учесть все подводные камни. Эта версия программы уже очень близка к полноценному автоматизированному переносу данных и закрывает, наверное, больше 95% задач. Проект продолжает бурно развиваться. Тем не менее риски остаются, поэтому проверить все глазами и прогнать тесты все-таки придется.
Introducing multi-version schema migrations
Эндрю Фэррис (Andrew Farries) из интересной компании Xata пишет, что у них там под капотом библиотека pgroll, которая даёт возможность поддерживать и новую, и старую работоспособные версии схемы базы. Но это не дубликаты, Xata использует свои serverless-технологии эффективного версионирования.
From Microsoft SQL server to PostGIS
По словам Флориана Надлера (Florian Nadler GIS-консультант в Cybertec) переезд на PostGIS c Microsoft дело совсем простое, надо только запустить ogr2ogr - часть библиотеки GDAL. Он переносит объекты на Азорских островах и убеждается, что всё на месте.
О ГЕО (о PostGIS) есть небольшой блок материалов ниже.
MySQL vs PostgreSQL: Which Open-Source Database is right for you?
Эта статья Аиши Букар (Aisha Bukar, Red Gate) не о миграции, и она интересна не сама по себе, в ней нет какого-то значимого сравнительного анализа. Пока. Подробный сравнительный анализ обещан в следующих статьях серии. Так что можно сделать закладку.
Расширения
Тему расширений чуть ли не монополизировал на конференциях Дэвид Уилер (David E. Wheeler) - основатель PGXN.Теперь он главный архитектор (principal architect) в Tembo - в небольшой, но содержательной статье рассказывает о разнообразных случаях использования заранее загружаемых и не загружаемых модулей. Статья ориентирована прежде всего на тех, кто сам сочиняет расширения (расширения и модули - в нашей терминологии), но полезна и представителям более широкой публики. Первое, что приходит в голову после прочтения названия, это строчка shared_preload_libraries
в postgresql.conf
, но Дэвид говорит и оsession_preload_libraries
иlocal_preload_libraries.
С этими специфическими кейсами удобно управляться, назначая соответствующие роли. Также он говорит об осторожном использовании хуков (надо знать последовательность их вызовов) и пулеров соединений. И каждый раз напоминает: разработчики, поясните в документации то-то для случая а) и то-то для случая б).
Параллелизм, мониторинг
Конечно, статья Элизабет Кристинсен (Elizabeth Christensen, Crunchy Data) не только о том, где технически возможно распараллеливание запросов, но и о том, как настроить соответствующие параметры, и о том, когда вообще имеет смысл озаботиться распараллеливанием, а когда выкинуть это из головы.
Любопытный раздел: Параллелизм в Postgres это не ..
НЕ многопоточные вычисления: это разъяснялось в докладе Марго Зельцер (Margo Seltzer, Университет Британской Колумбии) When Hardware And Databases Collide на pgconf.dev. Можно почитать дискуссию о многопоточности, ссылки здесь.
В Postgres параллелизм НЕ векторизован: векторизация это, получается у Элизабет, то же, что SIMD. Векторизация не только ускоряет вычисления, но и делает доступ к памяти более эффективным, сокращая промахи кэша CPU. Этого в Postgres пока нет. Но можно скрестить Postgres с Уткой - говорит Элизабет, ссылаясь на статью Марко Слота, см. ниже в утином разделе этого выпуска.
Built-in replanning как способ корректировать огрехи оптимизатора PostgreSQL
В нашем прошлом выпуске было много Алёны Рыбакиной. Ну что же, в этом тоже упомянем: на хабре появилась эта её статья на ту же примерно тему, что и канадские и прочие доклады:
В своей новой разработке мы решили взглянуть на проблему исправления ошибок оптимизации с другой стороны. Основная идея в том, чтобы добавить возможность перепланирования на основе полезных сведений, которые можно получить из уже частично выполненного запроса. Помимо этого нужно сформулировать критерии для плохо спланированных запросов, для которых необходимо провести перепланирование.
А вот её коллега Андрей Лепихов в статье на medium.com Designing a Prototype: Postgres Plan Freezing пишет:
При разработке расширения для заморозки плана запроса [то есть sr_plan] получились некоторые импровизированные находки, которые могут оказаться полезными и для других проектов.
Что же это за находки? Где? На более низких уровнях. Андрей залезает в деревья парсера (parse trees). Сначала Андрей исследовал состояние дел по части сохранения планов. Имеются pg_shared_plans, pg_plan_guarantee и pg_plan_advsr. Но всё это исследовательские проекты и доверия ему они не внушили. Поэтому начал искать и думать сам. Эта статья (как и многие другие его статьи) написана в жанре дневника разработчика: после А надо было сделать Б, я попробовал так, потом вот так. Очень интересное чтение, хотя не для слишком широкого круга.
Top Postgres Monitoring Tools and Best Practices in 2024
На bytebase.com Тяньжу (Tianzhou) начинает с того, что Postgres, мол, движется вперёд, подталкиваемый к лидерству успехами pg_vector, Supabase и Neon. Но дальше об этом ни слова, минимум экзотики, больше старые испытанные средства. Изложено, мягко говоря, конспективно. Но кому-то такая сводка наверняка придётся по вкусу. Там есть разделы Monitor Transaction ID Wraparound, Monitoring Locks, Avoid Blocking Operations.
Постгрес и утки
![Утка Облачная Утка Облачная](https://habrastorage.org/getpro/habr/upload_files/654/e85/f0a/654e85f0aeabaf4f88a2d217fdc5d50a.jpg)
Does PostgreSQL respond to the challenge of analytical queries?
Свежая статья Андрея с упоминания статьи, безусловно заслуживающей внимания тех, кто интересуется задачами OLAP: Unleashing Postgres for Analytics With DuckDB Integration на The New Stack. Автор - Пол Лоуренс (Paul Laurence, сооснователь Crunchy Data). Там интересно про push-down-ы, о том, где что считать и где что хранить.
Тему подхватывает коллега Пола - Марко Слот (Marco Slot). В Postgres Powered by DuckDB: The Modern Data - большую часть статьи он настаивает, что OLTP и OLAP суть два разных мира и вместе им не сойтись, как говаривал Редьярд Киплинг. Но есть же HTAP (Hybrid Transactional/Analytical Processing, не так ли? Не совсем так, говорит Марк. Обычно гибридные системы проигрывают и тем, и тем специализированным. Ну и дальше предлагается постгрес-уточное решение Crunchy Bridge for Analytics. Там данные в аналитических таблицах на основе файлов в S3, DuckDB как механизм запросов к этим таблицам, а PostgreSQL добавляет гибкости этим запросам или частям этих запросов. В DuckDB есть расширения, позволяющие самые разнообразные запросы в синтаксисе PostgrSQL исполнять параллельно, в векторном стиле, работая с колоночными Parquet-файлами. Но это не HTAP, это именно аналитическая база, к которой добавили богатый набор средств PostgreSQL.
Ну ок, идея интересная, а что есть в Postgres для её реализации? И чего нет? - размышляет Андрей в той статье. Есть FDW, конечно. Андрей перечисляет, что FDW (пока) не может.
Но многое делается. Вот, может быть, самое ценное в статье: список коммитов, которые помогли и помогут сдвинуть Postgres в сторону аналитики.
А вот и WASM, с которого мы начали этот выпуск Postgresso, на этот раз утиный. В статье Поиск удобных мест для жизни в Москве на GitHub Pages с помощью DuckDB в браузере есть раздел Встречайте DuckDB Wasm. там сказано: проект сделал кросс-компиляцию базы данных на WebAssembly в JavaScript. Сайт проекта поможет вам разобраться что же это такое.
В статье Putting DuckDB in Postgres to Query Iceberg разработчики ParadeDB рассказывают, как заменили свою же разработку pg_lakehouse на DuckDB так, что теперь PostgreSQL может передавать запросы к файлам формата Apache Iceberg на S3.
На хабре уже немало статей о DuckDB. Не думаю, что это Всё что нужно знать про DuckDB, но для ознакомления может пригодиться.
В статье Геопространственная DuckDB не только гео-картинки необыкновенной красоты и описание уткобазы с точки зрения пользователя PostGIS, но и вот такая информация:
Ведется работа над расширением, которое перенесет геопространственные функции PostGIS Пола Рэмси в DuckDB.
![Просто Утка Просто Утка](https://habrastorage.org/getpro/habr/upload_files/c9b/fcd/56f/c9bfcd56f7e1d39c5e8df62696e7c134.jpg)
Перекосы
Probing indexes to survive data skew in Postgres
И опять начинаем со статьи Андрея Лепихова - совсем свежей.
Случается, что статистика по наиболее часто встречающимся значениям (MCV, Most Common Values, об этом можно почитать здесь у Егора Рогова) дэзориентирует планировщик запросов. Андрей придумал, как его в некоторых случаях вразумить. Инструмент вразумления лежит здесь .
Элизабет Кристенсен (Elizabeth Christensen, Crunchy Data) говорит, что её статья написана по мотивам доклада Как усмирить Мастодонта (How To Tame A Mastodon: Lessons For PostgreSQL At Scale) на SCaLE 20x (Southern California Linux Expo). Поскольку на этой конференции принято обсуждать высоконагруженные системы, то и в докладе обсуждаются часто встречающиеся проблемы и решения для больших баз Postgres. На видео она выступает с Дэвидом Кристенсеном (David Christensen, тоже в Crunchy Data). Речь о нагруженной системе с такими параметрами:
25ТБ в базе и база существенно растёт,
15 реплик
150ГБ/ч WAL,
230M+/ч транзакций на primary.
Усмирение мастодонта есть и в виде статьи. Тогда Кристенсены говорили в том числе о перекосе данных и о частичных (partial) индексах. После доклада были обсуждения, поэтому Элизабет решила расписать тему более подробно в статье. Там есть, например, довольно замысловатый запрос к pg_statistic, которым можно искать эти самые перекосы. В заключение Элизабет показывает, как создать частичный индекс.
Образование
На хабре появился мемуар:
Как фронтендер сертификацию PostgresPro сдавал
Не буду спойлерить с какой попытки, а вот выводы процитирую:
Для себя, я вынес огромную пользу, вообще я считаю, что эта сертификация не про Postgres как инструмент, а скорее про систему. Я узнал много архитектурных решений, которые принимались в СУБД, о которых не имел понятия, как обеспечивается транзакционость, что такое WAL - журналы, как хранятся данные, как система взаимодействует с ОС и т.д.
Автору, Айдару Насибуллину, отрекомендовавшемуся как Fullstack-разработчик, пишут в комментариях: Спасибо Вам огромное, что написали эту статью, Вы добавили мне мотивации!
Postgres Professional обновила курс по администрированию PostgreSQL 16
Опубликован обновленный до версии 16 базовый курс - DBA1 - по администрированию PostgreSQL. В программу добавлена информация про новейшие версии 14, 15, 16, а также:
Единым обзором заменены четыре темы раздела «Управление доступом», по которым в дальнейшем появится отдельный подробный курс;
Частично изменена структура: изложение стало более логичным и последовательным;
Физическая и логическая репликации теперь рассматриваются в отдельных темах.
Помимо этого, исправлены недочёты в изложении, ошибки в скриптах демонстраций и практических заданий. Обновление выполнил Алексей Береснев.
Расширенный курс для разработчиков приложений DEV2 обновился на 16-ю версию PostgreSQL. Материалы выложены на на сайте. Радикальных изменений в курсе не произошло, но материал некоторых тем был переработан. Учтены новинки версий PostgreSQL 13-16. Обновление выполнили Игорь Гнатюк и Илья Баштанов.
9 октября в Москве пройдет конференция PGConf.Academy для преподавателей информационных технологий. Для преподавателей учебных центров участие бесплатное.
Все видео Postgres Professional — теперь и на Rutube
Теперь на Rutube сдублированы записи с конференций, видео How-to и другие ролики. Видео-уроки к курсам — тоже здесь: PGPRO Возможности Postgres Pro Enterprise 13
Администрирование PostgreSQL 13:
Разработка серверной части приложений PostgreSQL 12:
А также QPT. PostgreSQL 13. Оптимизация запросов.
Идёт процесс переноса контента в VK, следите за обновлениями.
В столице - в Элисте. Также известен как IT-лагерь Postgres Professional. Организован совместно с IT-кластером «Цифровая Калмыкия». Это школа, как пишут организаторы, для детей одаренных в области точных наук: математики, физики, информатики. Возрастные группы участников: 12-13 лет (закончившие 6-7 класс) и 14+ (закончившие 8-11 класс). Проходит 3 июня-23 августа в 6 смен.
Недавно завершилась 5-я смена лагеря, где под руководством Екатерины Соколовой, разработчика Postgres Professional, школьники изучили Python, SQL и сделали свой проект. Расписание (совсем в общих чертах) есть на сайте. Известно, что в эту смену, например, лекцию Безопасность ПО и основы фаззинга прочитал Николай Шаплов, ведущий разработчик Postgres Professional. "Взрослый" доклад на PGConf.СПб 2023 на эту тему называется Fuzzing-исследование PostgreSQL. Как мы искали, и что мы нашли.
Конференции и митапы
Надо сказать, что на этом линуксовом форуме Южной Калифорнии (в Пасадене), где Элизабет Кристенсен рассказывала про перекосы, Postgres представлен довольно солидно: 2 дня в 2 потока, около 20 докладов. В этом году, например:
Collation Challenges: Sorting it Out и PostgreSQL Ask Me Anything - (Joe Conway, Head of PostgreSQL Contributors Team в Amazon Web Services (AWS), он вообще не пропускает это мероприятие.
JSON and analytics in Postgres using index and columnar - Gleb Otochkin, Google.
Securing Your PostgreSQL Data: A Comprehensive Guide to Protecting Your Database Assets - (Henrietta Dombrovskaya, Database Architect at DW Holdings)
Цифры после названия порядковый номер, а не год, SCaLE 22x это 22-е по счёту собрание , оно пройдёт 6-9 марта 2025 в Pasadena Convention Center.
Выложили плейлист докладов. Например: How Postgres is misused and abused in the wild - Карен Джекс (Karen Jex, архитектор решений Crunchy Data). Есть там и доклад Adaptive query optimization in PostgreSQL - Алёны Рыбакиной (Alena Rybakina очно) и Андрея Лепихова (Andrei Lepikhov, заочно, оба Postgres Professional).
Доступно расписание, конференция пройдёт в Лондоне 11 сентября. Открыта регистрация. Организует это довольно компактное мероприятие Dave Page. Алёна Рыбакина будет, кажется, говорить о другом: на этот раз о том, How well do you know what the vacuum was doing? О 17-й версии расскажет Магнус Хагандер (Magnus Hagander, Redpill Linpro) в докладе A look at the Elephant's trunk.
Lowlands=Нидерланды. Компактная конференция, пройдёт 13 сентября в Амстердаме. В расписании в основном знакомые имена. Летиция Авро (Lætitia Avrot, EDB) прочтёт интригующее: The Sad Truth - Why Postgres Makes You Miserable.
Пройдёт в Санкт-Петербурге 1 октября в гостинице "Санкт-Петербург" на Пироговской набережной. Регистрация открыта.
Состоится в 4-8 ноября в Сиэттле. Он отнюдь не постгресовый, даже наоборот: PASS = Professional Association for SQL Server. Но в расписании 23 доклада помечены как имеющие отношение к PostgreSQL. Например, Ник Иванов (Nick Ivanov, EDB) расскажет о TPA (Trusted Postgres Architect), которой пользовались в EDB, а потом отдали сообществу: Trusted Postgres Architect - Automation for Deployment and Testing. А Брюс Момджан вызвался объяснять, как работает оптимизатор: Explaining the Postgres Query Optimizer.
Postgres Meetup for *. New York, online from anywhere - так написано на странице. Это не анонс конкретного митапа. Здесь публикуются объявления о встречах постгресистов в Нью-Йорке, но зайти, стало быть, можно всем. Сейчас там 3 объявления:
Fun with Postgres AI and Karaoke - Флоор Дреес (Floor Drees), презентация Tembo (а ещё совсем недавно Флоор работала в Aiven) 16 октября 2024.
Using PgBouncer for no-downtime failovers - Арка Гангули (Arka Ganguli), презентация Notion 14 ноября 2024.
12 декабря речь будет держать Клэр Джордано (Claire Giordano, Microsoft).
PostgreSQL Berlin July 2024 Meetup
Этот митап прошёл в берлинском офисе компании Adjust. Говорят, пользовался большим успехом для этого формата - собралось 58 человек. Выступала в том числе Анастасия Лубенникова (Anastasia Lubennikova, Neon), она делала доклад Vacuum and autovacuum in a managed postgres service. Некстати, но не могу не вспомнить ностальгическое: на днях попался на глаза анонс курса, который читала Анастасия - Курс «Hacking PostgreSQL» — уже скоро ["скоро" это 2015].
Йозеф Мачитка (Josef Machytka) сделал доклад Can PostgreSQL have a more prominent role in the AI boom? (слайды).
К слову: в самом Adjust ведутся интересные разработки, а Артур Закиров (Artur Zakirov) пишет интересные статьи, иногда на необычные темы, например: Saturation Arithmetic with a PostgreSQL Extension, где рассказывает об эджастовском расширении pg-saturated_int. У компании есть список расширений, доступных публике.
Планета ИИ
Thread: Planet Postgres and the curse of AI
Нет, до Планеты ИИ дело, к счастью, не дошло .. Но случилось вот что: Грег Сабино Маллейн (Greg Sabino Mullane) взбудоражил сообщество своим алармистским письмом: на святая святых - Planeta PostgreSQL - стали появляться статьи, написанные не знатными постгресистами, а LLM - большими языковыми моделями. Грег выражается более осторожно: в основном написанные LLM. Но самое плохое, - говорит он, - что они не просто собирают информацию, а синтезируют заключения и факты. Короче, они могут лгать или галлюцинировать.
На планету посты попадают автоматически. Знатные постгресисты откликнулись. Лауренц Альбе (Laurenz Albe) пишет: как автор постов и читатель (нерегулярный) Planet Postgres, не вижу тут большой проблемы. Полистал, ничего не бросилось в глаза. Может, я слишком наивен.
Однако, в следующем его письме читаем: Похоже, я действительно наивен. Álvaro [Альваро Эррера - Herrera, видимо] показал мне жирные [у Лауренца: juicy] примеры.
Ну, убедились: да, случаи были. Что делать дальше? Как определить допустимую степень участия LLM? Ведь это спектр от спелчекера, через отредактированный человеком текст к полностью сгенерённому LLM. Да ещё и о сгенерённые картинки люди используют, которые могут быть вполне адекватны тексту. Да и как отличить? Судили, рядили, сошлись (пока) на том, что никакие административные меры не нужны, надо просто смотреть: если текст бессодержательный или дезинформирующий, предупредить автора - а уж как он его сочинил, с LLM или сам - какая, в общем, разница.
Мнение моё не изменилось, - пишет в том же письме Лауренц, - доказать применение LLM сложно, да и не в этом дело. Проблема в низком уровне контента и несоответствии фактам, написал ли это ИИ или человек. Нужен механизм жалоб на плохой контент, чтобы при упорстве забанить пользователя. За штучки вроде "для увеличения производительности установите fast_mode = on и перезагрузите базу".
Рейтинг: количество постов на Планете от компаний/команд за последние 2 месяца:
EDB - 14
Crunchy Data - 11
Postgres Professional - 9 (и это, похоже, заслуга Андрея Лепихова)
Tembo - 9
Stormatics - 9
Cybertec - 8
Xata - 6
Percona - 4
PostGIS - 2
ГЕО
Подавать с (best served with) PostgreSQL 17 Beta2 и GEOS 3.12.2. Если конкретней, то альфа2 требует PostgreSQL 12 - 17, GEOS 3.8 или выше и Proj 6.1 и выше. Чтобы использовать все новшества, нужен GEOS 3.12 и выше, а для поддержки postgis_sfcgal нужен SFCGAL 1.4-1.5 и выше, а чтобы реализовать все возможности SFCGAL, он должен быть не ниже SFCGAL 1.5.
Converting DMS to PostGIS Point Geometry
Элизабет Кристенсен пишет и о PostGIS тоже. Работать с пространственными данными, признаётся она, одно удовольствие, всё это быстро конвертируется в красивые карты. А вот в собранной людьми исторической геоинформации встречаются градусы, минуты и секунды. Перед тем, как они попадут PostGIS и QGIS, их придётся конвертировать. Для этого Элизабет придумала функции с Regex.
Inside PostGIS: Calculating Distance
На этот раз сам Пол Рэмзи (Paul Ramsey) в блоге Crunchy Data рассказывает о вычислении расстояний. Не просто объясняет, не просто между 2 точками, а расстояние между многоугольниками и акцент делает на вычислительной сложности и алгоритмах.
Six Degrees of Kevin Bacon - Postgres Style
А вот в этой недавней статье Пол рассказывает, как смоделировать задачку вовсе не географическую: упорядочить коллег актёра Кевина Бейкона. Всемирной славой он обязан не (столько) ролям, сколько тому, что он - главное действующее лицо теории шести рукопожатий — Шесть шагов до Кевина Бейкона. Эта не гео задачка решается типичными средствами для решения геозадач - при помощи расширения pgRouting (руководство здесь). Из названия понятно, что оно создавалось для нахождения быстрого пути в транспортных задачах. Но оно куда более универсально. Для обхода графа Пол использует алгоритм Дейкстры, который тоже реализован в pgRouting.
Альтернативой будет обход графа при помощи рекурсивного CTE. В мире невразумительных (confusing) SQL рекурсивные CTE самые невразумительные из всех - говорит Пол.
Метод графов не требует внешних средств, всё можно сделать внутри PostgreSQL, используя pgRouting или рекурсивные CTE.
pgRouting хорош для небольших графов, особенно для тех, что генерятся динамически, отражая изменения в данных, или в графах, которые хотелось бы построить.
-
Рекурсивные CTE могут работать с графами гораздо больших размеров, но если проход по графу долгий, начинают катастрофически накапливаться промежуточные результаты.
На сегодня всё, до встречи в следующем месяце.
klimkovsky
Игорь, спасибо.
А что насчет видео учебных курсов. Youtube перестает быть общедоступной площадкой. Где смотреть/искать, если что?
Igor_Le Автор
Привет, Андрей. В обзоре же есть как раз о дублировании на Рутубе. Будет в ближ время ещё и вконтакте.