Из жизни малышей и гигантов
Опенсорсный проект 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 излагает суть не только одноименной англоязычной статьи, но и прошёлся по другим публикациям на эту тему. Есть интересные временнЫе диаграммы, описывающие такую интересную особенность LegerStore:
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.
Постгрес и утки
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.
Перекосы
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 anywhaere — так написано на странице. Это не анонс конкретного митапа. Здесь публикуются объявления о встречах постгресистов в Нью-Йорке, но зайти, стало быть, можно всем. Сейчас там 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 могут работать с графами гораздо больших размеров, но если проход по графу долгий, начинают катастрофически накапливаться промежуточные результаты.
На сегодня всё, до встречи в следующем месяце.
ссылка на оригинал статьи https://habr.com/ru/articles/828950/
Добавить комментарий