Защитите Postgres от квантов!
Why quantum-safe PostgreSQL is critical today
Только свыклись с мыслью о сосуществовании с LLM, и нате — новая напасть! Как сделать Postgres непробиваемым для квантов? Как, уже и об этом пора думать?
Автор — Тимоти Стюард (Timothy Steward) — считает, что да, пора. Статья в блоге Fujitsu Fastware, а Тимоти — главный архитектор данных по направлению энтерпрайз (Principal Enterprise Data Architect), там сейчас продвигают Fujitsu Enterprise Postgres 17.
Он говорит вот о чём: квантовые компьютеры пока мало что могут, но уже навострились ломать криптозащиту. Во всяком случае, надо к этому готовиться. Не то, чтобы заметка выдающаяся, но тема любопытная. Там есть ликбез, есть общеизвестные вещи, но есть и сведения, знакомые, наверное, только специалистам по шифрованию, есть красивые имена IBM-овских птичек, оформленные в табличку(справа — число кубитов):
2020 Hummingbird 65
2021 Eagle 127
2022 Osprey 433
2023 Condor 1121
2024 Flamingo 1386
2025 Kookaburra 4158
Тимоти утешает: AES256 обезопасит нас до 2050 (почему — не очень понятно). Но на всякий случай уже пора думать и о других алгоритмах шифрования: SIKE (Supersingular Isogeny Key Encapsulation), например.
Есть его видео (на странице заметки) и презентация на эту тему — доклад на прошлогоднем майкрософтовском PASS Data Community Summit.
Ну а вообще на тему квантовых вычислителей для работы с данными и базами статей полно. Вот, скажем, чтобы долго не думать:
Role Of Quantum Computing In Data Science.
Или научная, коллектив Китай-Хельсинки:
Quantum Computing for Databases: Overview and Challenges.
Защитите потоки!
Implementing thread-safe scanners and parsers in PostgreSQL
Питер Айзентраут (Peter Eisentraut) предупреждает, что просто хочет сбросить накопившееся в голове (brain dump) во время своей работы по реентерабельности разных сканеров (созданных Flex) и парсеров (созданных Bison) и безопасностью функций в многопоточной среде (то есть как раз thread-safety).
Статья - противоположность предыдущей: огромная, море технических деталей, куски кода. Раздел Заключение и подсказки содержит 5 абзацев рекомендаций.
Поймать и обезвредить!
Так называется полезная статья Екатерины Соколовой aka sokolcati. Стоит тег Туториал. Статья опубликована в середине января, но написана по мотивам выступления на PGConf СПб 2024. Екатерина — разработчица в Postgres Professional. Как мы писали в обзоре питерской конференции: Екатерина примеряла роль ведущей на PGConf-Academy. И получилось складно.
Как поймать и обезвредить проблемные запросы в PostgreSQL
Находим запросы — кандидаты на улучшение.
Убираем избыточные запросы, переносим несрочные.
Проверяем блокировки.
Изучаем планы долгих запросов.
При необходимости создаём или удаляем индексы, настраиваем параметры, подключаем полезные расширения.
Проверяем степень выполнения запроса.
Решаем, продолжить выполнение запроса или отменить его.
Ладно, хватит запугивать читателя. Больше восклицательных знаков не будет.
PostgreSQL 18: Часть 2 или Коммитфест 2024-09
Павел Лузанов пишет: Согласно статистике, в сентябрьских коммитфестах меньше всего коммитов. Но похоже, что для релизного цикла 18-й версии это не так. Много принятых патчей и много интересных новых возможностей, информацией о которых хочется поделиться.
И там настолько много, что всё перечислять здесь не будем. Вот, например, любопытное:
Мониторинг конфликтов логической репликации — например, в представлении pg_stat_subscription_stats появились счетчики для конфликтов всех типов.
Планировщик: теперь без 10 000 000 000 — без этой дикой константы для подъёма стоимости (cost) в небеса.
Планировщик: управление памятью и мониторинг ее использования для временного хранилища строк — к этому пункту длинный список коммитов. Ряд узлов плана запросов (список ниже) используют общий интерфейс для временного хранения строк (tuplestore). В этом интерфейсе произошли два важных изменения. Второе отразилось и на EXPLAIN (analyze): теперь он показывает тип используемой памяти (Memory или Disk) и много чего ещё интересного.
-
кстати об ANALYZE: ANALYZE ONLY и VACUUM ONLY — предупреждение говорит о том, что нет смысла запускать очистку секционированной таблицы без параметра analyze.
Напомним, что самое интересное из июльского коммитфеста можно прочитать здесь: 2024-07.
Некоторые конференции
Сначала о новой российской постгресовой конференции:
Первая «продуктовая» конференция компании. Она прошла 28 января на территории Цифрового делового пространства (ЦДП) в Москве на улице Покровка, д. 47. Это бывший кинотеатр Новороссийск, если кто помнит. На фасаде здания было панно с огромным слоном, и это был не обычный статичный слон: он размахивал хоботом.
Моё впечатление: дебют удачный. Главное (с моей зрительской точки зрения) получилось: она не похожа на PGConf.Russia, хотя было немало докладов на пересекающиеся темы. На компактной, однодневной Pro все доклады компактно умещались в 30 мин, некоторые докладывали даже быстрей, чтобы оставить больше времени на ответы на вопросы.
Некоторые слушатели говорили, что Pro не такая технологичная, как PGConf, но не в упрёк, и ни разу не слышал в кулуарах слова маркетинг. Главное (в высшем смысле) получилось: стали отчётливо видны очертания плана Postgres Professional. Куда компания движется и логика этого движения. И куда двигаться (пока) не собирается. В отдельных докладах было интересно то, что в релизах и анонсах обычно не видно: что уже есть, что появилось только что, что появится после «только что», а что в работе, временные границы которой (пока) размыты.
В этом контексте мне особенно понравился доклад Марка Ривкина: Новые возможности СУБД Postgres Pro Enterprise 17. Толковый, сконцентрированный доклад с максимально чётко расставленными акцентами было/только_что/вот_вот/в_недалёком_будущем/в_далёком. Я бы начинал знакомство с докладами конференции с этого доклада, двигаясь дальше по «лучам» более специализированных докладов.
Разумеется, были доклады по Shardman, BiHA, Proxima, PPEM, pg_probackup3, по новым расширениям. Я бы сейчас обратил ваше внимание на тему, не так часто мелькающую в контексте Postgres: Управление жизненным циклом информации — ILM: как новое расширение pgpro_ilm помогает автоматизировать распределение информации по дисковым пространствам в зависимости от частоты использования, как переносить редко используемые отношения в более дешевое хранилище по аналогии с функцией ILM в Oracle. Рассказывал Сергей Зимин.
Safreliy пишет сагу о ИИ и базах на Хабре, а мы следим. Пока 3-я серия. А на конференции Савелий Батурин представлял стенд, где можно было задать вопросы специально подкрученному LLM, и доложил об Опыте внедрения искусственного интеллекта (AI) в PostgreSQL. Из доклада я узнал, что простенький пайплайн в RAG плохо работает, что LLM не любит нормализованные таблицы. Совсем для меня неожиданным оказалось, что Савелий использовал промежуточное кодирование информации в графы, для чего использовался язык графовых запросов Cypher.
Обязательно посмотрите «круглый» стол «Чего не хватает в СУБД».
На момент написания этого обзора материалы ещё не были выложены, но, несомненно, будут. Ожидаются в этот понедельник.
Это открытая встреча Postgres Professional и Selectel 12 февраля. Зарегистрированным участникам пришлют ссылку на трансляцию, а на месте выдадут пиццу.
Много не мало. Зачем нужен выделенный сервер под облачные базы данных — это Александр Гришин из Selectel расскажет про облачные базы данных и представит новый продукт — облачную БД на физическом сервере, доступную как сервис.
А Через тернии к звездам — как засунуть Петабайт в Postgres — это Михаил Жилин из Postgres Professional поделится опытом тестирования Shardman с 1 ПБ данных.
Ещё будут Новости и вызовы кластерных технологий PostgreSQL — Павел Конотопов, Postgres Professional.
Состоится 31 марта - 1 апреля, но - внимание: 9 февраля - дедлайн подачи тезисов. Подобрать тему и подготовиться к выступлению всегда поможет Александр Фатин. Если вы хотите провести мастер-класс или разместить на конференции стенд с демонстрацией продукта, пожалуйста, обращайтесь к Марии Критской.
Ладно. Теперь продолжим запугивание читателей:
Большие данные мертвы, но есть Болота Данных
Всезнают УткоБазу. А МамуУтку — не все. Джордан Тайгэни (Jordan Tigani) — основатель и гендир МамыУтки размышляет в мамоуткином блоге вот о чём:
боялись, что данных будет так много, что железо и софт с ними не справится. Нет, железо легко переварило увеличение данных. Вопрос в другом: аналитики задаются вопросом - а что толку практикам от всего этого изобилия данных?
Джордан рассказывает, что когда работал в Google BigQuery, любил разъезжать по конференциям и там в реальном времени демонстрировал запросы к петабайтным данным — мол, подумаешь, петабайт. Нопроблем. Но обычно пожимали плечами: а кому они нужны — эти петабайты? Большинству хватало и терабайта.
Далее он говорит: вотмодная тема — разделение вычислительных возможностей и данных. Но на самом деле эти оси имеют совсем разное влияние в реальном мире. В BigQuery у нас был клиент — один из крупнейших ритейлеров в мире. Сначала у него была свой DW в 100ТБ. Потом он перешёл в облако и в конце концов нарастил объёмы до 30ПБ, то есть в 300 раз. Если б ему надо было наращивать теми же темпами вычислительные мощности, ему б пришлось потратить на аналитику миллиарды. Ничего подобного не происходило. Пришлось потратить всего лишь долю от того, что тратилось на прежние вычислительные мощности.
Те, у кого данные большие, редко делают запрос ко всему объёму этих данных. А если и делают, то что-то вроде отчёта для руководства, это можно считать неделю.
Раньше говорили Big, если данные не влезали в одну машину. Но машины растут тоже. Другое определение: «когда затраты на хранение данных меньше, чем стоимость определения, какие данным можно выкинуть» — любимое у Джордана. И вырастают не озёра данных, а огромные грязные БОЛОТА ДАННЫХ (giant, messy swamps), в которых увязнут те, кто попробует понять, что там ценно, а что можно выкинуть.
В общем, на ум приходит синдром Плюшкина.
Короче, как мы все и предполагали, большие данные совсем даже не умерли. Вымерли старые паттерны отношения к большим данным.
Но на этом утиная тема не заканчивается.
Николай Самохвалов (Nikolay Samokhvalov, основатель Postgres.ai) и Майкл Кристофайдес (Michael Christofides, основатель pgMustard) беседуют с Джо Шиаррино (Joe Sciarrino — сооснователь и гендир Гидры) и Йелте Феннема-Нио (Jelte Fennema-Nio, МамаУтка) обсуждают расширение pg_duckdb и вообще смысл встраивания DuckDB в Postgres:
Как всегда ведущие дополняют аудио полезным набором ссылок. Среди них есть даже Слон с клювом:
The problems and benefits of an elephant with a beak (просвещает Йелте)
Анонс pg_duckdb — Джордана Тайгэни и Брэта Гриффина (Brett Griffin) от MotherDuck
Разжалование
DB-Engines уже анонсировала: Postgres стал СУБД 2024, и — нате: СУБД года по последним новостям вовсе не Postgres, а Snowflake. У меня даже сохранилась в черновике ссылка с названием PostgreSQL is the Database Management System of the Year 2024, ведущая туда же, куда теперь ведёт Snowflake is the Database Management System of the Year 2024. До того это звание Postgres присуждалось в 2017, 2018, 2020 и 2023 годах.
Итак, Postgres спихнули на 2-ю ступеньку пьедестала. Ну, тоже неплохо. Но звучит не так приятно для уха.
Но это База Года. А в рейтингах популярности DB-Engines много подрейтингов, их объединяет общий — Complete, — где все первые 4 места у реляционных баз:
Oracle,
MySQL,
MS SQL Server,
PostgreSQL.
За ними MongoDB с предикатом документная. Соответственно, в этой категории она лидирует. Неполный список:
Ключ-значение: Redis,
Time Series: InfluxDB,
Графовые: Neo4j,
Векторные: Elasticsearch (Pinecone только 6-я)
Колоночная: GridGain — единственная в категории.
DB-Engines, кстати, летом была продана: DB-Engines now owned by Redgate Software.
Бенчмарк Reserva
Некто Кэл Митчел (Cal Mitchell) любит сравнивать производительность разных баз, делать обзоры на своём сайте DataSystemReviews.com. Для этого он соорудил на Go тестовый набор таблиц и функций, изображающих высоконагруженную систему проводки платежей. Там есть авторизация и аутентификация, информация об экаунтах плательщиков и получателей, пересчёт балансов и записи платежей. Операции платежей крутятся в цикле. При этом можно регулировать параллельность и задать, нужен ли DELETE.
Подробности, установку, железо Кэл описал в Fastest Open-Source Databases. В этой статье Postgres побил MariaDB и MySQL. Но как. Марию побил не сильно, а MySQL был просто разгромлен. Участвовали:
postgres:17.0-bookworm,
mariadb:11.5.2-noble,
mysql:9.1.0-oraclelinux9
- все в Docker на i7 mini PC.
Образовательные ужасы
Компания DataLemur объявила о готовности SQL Squid Game по мотивам жутковатой (говорят) Игры в кальмара. В игре 9 уровней. Выживает сильнейший в SQL.
Образование без ужасов
Свежие поступления:
Это уже 11-е издание. Текст без радикальных изменений (не считая традиционной главы про новинки), а вот обложку обещают с сюрпризом. И ещё: она в процессе перевода на английский.
Учтены изменения в 17-й версии, исправлены замеченные опечатки. Добавлен материал про использование ресурсов при планировании запросов.
Готовится к выходу продолжение книги Евгения Моргунова PostgreSQL. Основы языка SQL, отдел образования приступил к финальной вычитке и верстке. Рассчитываем завершить в течение месяца.
12 апреля вместе с Алтайским государственным техническим университетом им. И.И. Ползунова Postgres Professional проведёт открытую межрегиональную олимпиаду по программированию.
Рабочие языки конкурса: C/С++ и Python3, примеры заданий универсиады доступны на сайте. 1-й тур пройдет очно 12 апреля. Для отработки навыков также можно пройти тренировочную сессию 7 апреля. Участники: студенты и школьники от 15 лет до 21 года включительно. Победители и призеры получат +5 баллов при поступлении в АлтГТУ им. И.И. Ползунова, также финалистов ждут денежные и ценные призы, приглашения на стажировки.
Необходимо зарегистрироваться на сайте до 31 марта, количество мест ограничено.
pgPedia развивается и даже переезжает
Мне нравится этот ресурс, поддерживаемый Ианом Барвиком (Ian Barwick) из EDB. Нравится организация материала, навигация. Переезжает не вся pgPedia, а раздел pgPedia Week, да и то в соцсетях:
В качестве «неловкого жеста в приступе энтузиазма» (an awkward gesture in a moment of enthusiasm), мы решили, что больше не подобает нам постить в место, которое раньше называлось «твиттером». Пусть он провалится. Следуйте за нами на BlueSky (а можно и по RSS).
Меня очаровал раздел Version Charts: это таблички в какой версии что появилось:
Кто?
Who Contributed to PostgreSQL Development in 2024?
Ну как кто? Впереди титаны: у Эндрю Данстана (Andrew Dunstan) - 22386 строки, 33 коммита, у Тома Лейна (Tom Lane) — 17 363, 256 — заметьте, он на этот раз уступил Эндрю. А вот на третье место взошёл Никита Глухов (Nikita Gkufhov) — 9144 строки кода, 6 коммитов.
Всё это можно узнать из статьи Роберта Хааса (Robert Haas). Это его любимая рубрика.
У Никиты 9 с лишним тыс. строк кода уложились в 6 очень больших коммитов. У Питера Айзентраута (Peter Eisentraut) их аж 263 при 8253 строках.
На 42-м месте Андрей Лепихов (Andrei Lepikhov, Postgres Professional) — 980, 9. Это вовсе не скромный результат: у таких известных людей как Андрес Фройнд (Andres Freund — 929, 28) и Дэвид Уиллер (David Wheeler — 755, 7) — меньше.
Из тех, с кем доводилось здороваться за руку, закономерно вижу: 28-й - Андрей Бородин из Яндекса (Andrey Borodin — 2437, 10) и 32-й Александр Коротков (Alexander Korotkov, Oriole — Supabase — 1576, 99). А в списке самых активных в переписке появляются ещё и Александр Лахин (Alexander Lakhin, 302 письма за 2024), Александр Алексеев (Aleksander Alekseev, Timescale — 241) и Алёна Рыбакина (Alena Rybakina, Postgres Professional - 135).
Мы часто даём ссылки на статьи Андрея, а тут ещё и повод. Из недавних, на его сабстэке:
Статья о том, что мы на самом деле измеряем, когда исследуем производительность. Какова воспроизводимость результатов в статье, которую мы читаем? Насколько устойчивы результаты 113 тестов Join Order Benchmark (JOB)? Этими вопросами задался Андрей длинными тайскими тёплыми вечерами. А потом ещё и посмотрел, как работает в его случае AQO.
Does Postgres need an extension of the ANALYZE command?
Да, Андрей говорит о замене команды — она не нравится ему нестабильностью статистики — расширением.
Investigating Memoize's Boundaries
Memoize — прекрасный механизм кэширования. Но он работает не всегда. Андрей разбирает различные случаи, при этом сравнивая PostgreSQL с SQL Server.
Некоторые релизы
Postgres Pro Enterprise 17.2.2
Обновлён модуль aqo. Реализован режим auto, который работает как режим learn, но предотвращает переполнение памяти;
Приложение mamonsu обновлено до версии 3.5.11, в которую включена поддержка pgpro_stats версии 1.8.
Расширение pgpro_multiplan обновлено до версии 1.1 (pg_multiplan - это расширение на смену sr_plan);
Расширение pgpro_stats обновлено до версии 1.8.1.
В этом релизе появилась поддержка Apache Cloudberry — облачного опенсорсного форка PostgreSQL для аналитиков, на базе GreenplumDB. Исправлены баги. Загружать можно отсюда.
pg_squeeze 1.8.0 — отжим таблиц
Отжать не в смысле незаконно отобрать, а в смысле удалить лишнюю влагу. В этом релизе ничего особенного - исправили ошибку. Но мы давно не писали об этой утилите. А цель благородная и актуальная, спасибо Cybertec, хотя сам проект отнюдь не новый. В статье 2016 года Introducing pg_squeeze: auto-rebuild bloated tables Каарел Моппел (Kaarel Moppel) объясняет, что это расширение фактически заменяет pg_repack (и VACUUM FULL, и CLUSTER), используя при этом новые (на тот момент) возможности Postgres: оно задействует слоты репликации и логическое декодирование, подсматривая изменения в таблицах в XLOG (которого давно переименовали). Перестройка таблицы распараллеливается и потребляет меньше ресурсов и времени.
Лирическое отступление от релизов: некоторые предлагают прежде, чем думать, как их решать, не создавать проблемы.
Idle Transactions Cause Table Bloat? Wait, What? — как-как?
Умейр Шахид (Umair Shahid, основатель Stormatics), как бы делает большие глаза: ничего не делающие транзакции могут вызывать раздувание (распухание, разрастание — bloat) таблиц и индексов? Погодите, правда что ли? Глаза и вопрос риторические: конечно. Правда.
Коротенькая ликбезная статья с SQL-примерами. Для удобства есть оглавление:
Почему сессии в статусе Idle in Transaction порождают проблемы
Как избежать Idle in Transaction и спасти таблицы от распухания
IvorySQL — SQL на костях слона
IvorySQL — относительно новый (стартовал в 2021) проект с открытым кодом, который запустили в китайской Highgo Software. Идея в том, чтобы заинтегрировать в PostgreSQL побольше функциональности Oracle, чтобы угодить любителям PostgreSQL, которым, однако, нужна совместимость с Oracle. И, конечно, речь о миграции Oracle на IvorySQL — SQL из слоновой кости.
Вот Исходники на гитхабе. Вот исходники веб-сайта. Вот полный Changelog.
Обидно мне это слышать, но создателю — Льву Кокотову (Lev 'levkk' Kokotov, Сан Франциско) — виднее. Пёс наследует лучшему в Коте, но ещё и добавляет функции, и производительность улучшил. Оба суть пулеры с балансировкой нагрузки, автоматическим фейловером и шардингом — так их позиционирует Лев. Напомним, что postgresml тоже его проект. А это не просто тулза для работы с машинным обучением, а приспособленная для задействования GPU.
Introducing pg_karnak: Transactional schema migration across tenant databases
Где Нил, там и Карнак. Гвен Шапира (Gwen Shapira) в блоге Nile определяет их базу так: Nile — это Postgres, переделанный для мультиарендных приложений.
Она рассматривает мультиарендные архитектуры от по-базе-на-каждого до новой: база одна на всех, а каждому-по-виртуальной-базе. Назвали архитектуру Distributed DDL. Для реализации её и разработали расширение pg_karnak. Скоро отдадут его в опенсорс.
А что там с бессерверными?
Azure SQL Serverless: Increase Your Savings
Это коротенькая заметка (в блоге Red Gate — Simple Talk это жанр по умолчанию). Пишет Деннес Торрес (Dennes Torres) из Рио, который теперь живёт на Мальте и курирует MMDPUG PASS Chapter.
Он пишет просто и ясно: зачем пользоваться Azure SQL Serverless? Чтобы экономить деньги. Он приводит 2 примера:
Мой персональный случай: у меня куча баз для экспериментов. При минимальном DTU в $5 нагорает приличная сумма. В бессерверной архитектуре я плачу за них только тогда, когда пользуюсь.
Во многих корпоративных сценариях причина - это редкое использование некоторых баз.
Из технического: в Бессерверной SQL-Лазури изменились настройки важного для пользователейпараметра — автопаузы. Это время, когда по инерции приложение висит в памяти, когда к нему не обращаются. Раньше был час. Теперь можно задать вплоть до 15 минут.
На сегодня всё, have fun.