Мы продолжаем знакомить вас с самыми интересными новостями PostgreSQL.
Конференция PGConf.Online 2021
Она начинается уже 1-го марта и закончится 3-го. О ней подробно написано в статье Ивана Панченко, зам. гендира Postgres Professional.
На этой конференции (которая не вместо, а кроме офлайновой, теплой-ламповой, она ожидается в конце весны) будет рекордное число иностранных гостей — чему явно поспособствовал онлайн-формат. В том числе на этот раз поучаствует и Саймон Риггс (Simon Riggs). Доклады в 3 потока с 10 утра до 6 вечера. А также мастер-классы.
Статьи
PostgreSQL 14: Часть 4 или «январское наступление» (Коммитфест 2021-01)
Очередной must read Павла Лузанова. Крупные изменения после первых трех относительно скромных коммитфестов (июльский, сентябрьский, ноябрьский).
«Вопросы для затравки», предложенные Павлом:
- Могут ли диапазоны содержать пропуски значений?
- Зачем нужна индексная нотация типу json?
- Может ли индекс при частых обновлениях разрастаться меньше, чем таблица? А вообще не разрастаться?
- Сколько времени простаивали сеансы в
idle_in_transaction? - Как построить ER-диаграмму для таблиц системного каталога?
Deep PostgreSQL Thoughts: The Linux Assassin
Слово deep уже пугает: не про ИИ ли это. Но нет. Джо Конвей (Joe Conway, Crunchy Data) действительно копает вглубь. Даже не Постгреса, не своего же расширения plr. На этот раз тема — Жуткий Убийца, являющийся из недр Linux — OOM Killer.
Джо начинает с истории: первые дискуссии в Postgres-сообществе и первые патчи в 2003-м году — как заставить киллера работать по понятиям Postgres. Далее Джо поясняет отношения киллера и Postgres на уровне хоста (oom_score и oom_score_adj) и на уровне CGroup, поясняет, почему так важно не допустить прихода киллера.
И дальше Джо Конвей переходит к специфическим проблемам OOM Killer в Kubernetes — это, видимо, и был главный повод для написания этой статьи. Оказывается, что там, в K8s, разрушительная деятельность киллера может начаться даже при относительно благополучном состоянии памяти. В K8s своп по умолчанию выключен. До этого момента автор не трогал тему свопа, которая, вообще-то, очень даже обсуждается среди постгресистов-практиков.
Джо ссылается на обстоятельную статью Криса Дауна (Chris Down) In defence of swap: common misconceptions, причём есть и русский перевод (не автопереводчиком): В защиту свопа: распространенные заблуждения. О Postgres там нет речи, но может заинтересовать и постгресистов.
Также ссылается он на статью The weird interactions of cgroups and linux page cache in hypervisor environments в блоге компании StorPool, где в команде в основном болгарские фамилии.
Далее Джо Конвей плавно переходит к разработкам и усилиям Crunchy Data в треугольнике PostgreSQL — Kubernetes — ядро Linux.
??
Акула жуёт гугловый кабель (The Guardian??)
Things I Wished More Developers Knew About Databases
Статья не (только) о Postgres. Иногда полезно ещё разок глянуть на разные СУБД с птичьего полёта. Вот внушительный список тем, о которых стоит помнить разработчикам приложений. В статье Джоанна Доган (Jaana Dogan) не поленилась их разворачивать и развивать. Иногда в неожиданную сторону: в пункте #1 мы, например, узнаём, что гугловские кабели давеча покусали акулы. Немало SQL-примеров, схем и есть матрица PostgreSQL vs. MySQL.
- Если сеть доступна 99.999% времени, вам сильно повезло;
- ACID понимают по-разному;
- у каждой СУБД свои возможности поддержки согласованности и изоляции;
- оптимистические блокировки могут помочь, когда удерживать эксклюзивные блокировки нет возможности;
- есть аномалии кроме грязного чтения и потери данных;
- моя СУБД, в каком порядке хочу исполнять транзакции, в таком и исполняю;
- шардинг на уровне приложения не означает шардинг вне СУБД;
- AUTOINCREMENT может преподнести неприятные сюрпризы;
- устаревшие данные могут быть полезны и помогают обойтись без блокировок;
- рассогласования из-за часов;
- под задержками (latency) могут подразумевать разное;
- надо оценивать производительность не по усредненным показателям, а по критическим операциям/транзакциям;
- вложенные транзакции небезопасны;
- транзакции не должны поддерживать состояния приложений;
- планировщик поможет узнать многое о базе данных;
- миграции без останова сложны, но возможны;
- существенный рост базы данных увеличивает непредсказуемость.
Troubleshooting Performance Issues Due to Disk and RAM
Хамид Ахтар (Hamid Akhtar, HighGo, Китай) написал простенькую, но небесполезную памятку для тех, кто хочет быстро сузить круг подозреваемых при поиске проблем с железом. Начав с совсем очевидных top, free и df, он обращается к утилитам анализа производительности дисков, процессора и памяти, и предлагает полезные наборы их опций:
iostat (информация и о диске, и о процессоре), напр. iostat -dmx sda 1
sar (System Activity Report, часть пакета sysstat), напр. sar -f /var/log/sa/sa03 -b -s 02:00:00 -e 02:30:00 -r -S
dstat, напр. dstat -cdngy
А вот скриптик для анализа памяти:
#!/bin/bash grep -A3 "MemTotal" /proc/meminfo grep "Swap" /proc/meminfo grep -A1 "Dirty\|Active" /proc/meminfo.
Starting with Pg – where is the config?
Депеш (Хуберт Любашевски) в короткой заметке напоминает, как можно найти конфигурационные файлы, если они лежат в нестандартном месте. Способы, которыми он предлагает воспользоваться не сенсационны, но может быть полезен, скажем, удобный набор опций.
Например, так:
ps -fxao pid,command | grep -E 'post(gres|master)'
— на выходе будет path. И отсюда:
sudo grep -E '(hba|ident)\.conf' <путь к postgresql.conf>
Или теперь танцуем от pid:
sudo cat /proc/<подставляем pid>/environ | tr '\0' '\n' | grep ^PG | sort
Или:
sudo lsof -p <подставляем pid> -a -d cwd
— получаем каталог данных и сведения о нём.
Если такие советы не понадобились, можно порефлексировать на тему «я бы сделал по-другому». Скажем, просто-напросто используя find, например.
Кирилл Боровиков aka kilor завершил мини-серию статей про агрегаты:
— как сделать отчеты быстрыми, способы их реализации и какие «грабли» встречаются на этом пути;
Эффективная обработка потока «фактов»
— как обработать БОЛЬШОЕ (капслок kilor-а) количество записей и при этом особо никого не заблокировать, включая «набегающий поток» данных. Например, это может быть пересчет остатков и ведение сводных продаж по товарам при их постоянных отгрузках, или агрегация сальдо и оборотов по бухгалтерским счетам, при массовых изменениях проводок.
— иерархичные агрегаты в нескольких одновременных разрезах;
— как можно снизить суммарные задержки на вставку множества изменений в таблицы агрегатов за счет использования промежуточных таблиц и внешней обработки.
Облака
Babelfish: the Elephant in the Room?
Русский перевод названия этой статьи, появившейся на сайте фонда испаноговорящего сообщества FUNDACIÓN POSTGRESQL звучал бы так: "Вавилонская рыбка или слона-то я и не приметил?" Мы уже упоминали, что идея проекта сверхамбициозная: Bablefish это PostgreSQL, совместимый с SQL Server настолько, что приложения, под него написанные (в том числе с T-SQL и протоколом TDS), будут сразу работать, «не зная», что работают с PostgreSQL.
Автор статьи — Альваро Эрнандес (Álvaro Hernández Tortosa, OnGres) — начинает с рыночной конъюнктуры, чтобы дальше предъявить гамлетовский вопрос, которым авторы Вавилонской Рыбки должны были задаться: форкать или не форкать?
Babelfish пока не может работать как расширение без доработки ядра PostgreSQL. Альваро напоминает, что 25-го января заслуженный и авторитетный в сообществе человек — Ян Вик (Jan Wieck) — предложил обсудить расширяемость протокола PostgreSQL: сделать такие хуки, которые позволят реализовать протокол SQL Server в виде расширения без изменений в ядре. Но это процесс небыстрый. Заодно решили обсудить и совместимость с MySQL. Но что делать AWS с Bablefish, если сообщество проигнорирует этот путь или интеграция пойдёт ни шатко, ни валко? Вероятней всего, считает Альваро, AWS будет развивать Bablefish как форк (так уже случилось с Aurora), как бы им не хотелось бы обойтись без форка. А если всё же придётся, то AWS это по силам.
Далее Альваро привлекает Дилемму инноватора. И задаёт ещё один интересный вопрос: хотим ли мы (то есть сообщество), чтобы Babelfish стала “MariaDB у PostgreSQL”?
Персона
Очередной PG-персоной недели стал Александр Сосна, живущий в небольшом городке на Нижнем Рейне и в свободное от работы в credativ время преподающий ИТ-безопасность в Нижнерейнском Университете. Он работает над довольно необычным расширением: pg_snakeoil. Это антивирус специально для PostgreSQL: он ищет вирусы в данных так, чтобы не мешать работе базы, что отнюдь не характерно для обычных антивирусов. Как замечает Александр, за вирусами охотятся не всегда из-за их вредоносности, иногда только потому, что этого требуют нормативные документы.
Релизы
Вышли PostgreSQL 13.2, 12.6, 11.11, 10.16, 9.6.21, 9.5.25 (последний выпуск ветки 9.5). В этих релизах одолели две проблемы безопасности:
в PostgreSQL 13 можно было, имея права на SELCT одного столбца, получить при помощи изощрённого запроса все столбцы таблицы;
вторая проблема касалась версий 11, 12 и 13. Если у пользователя есть права на UPDATE партицированной таблицы, но нет прав на SELECT некоторого столбца, он мог получить данные столбца из сообщений об ошибке.
Кроме того исправлено более 80 багов.
Появился флаг --force для инкрементального режима. Теперь можно переписывать содержимое в каталоге, указанном в PGDATA, если system-identifier в целевом экземпляре и копии НЕ совпадают (раньше приходило сообщение об ошибке).
В версии 5.0 среди прочего появилась поддержка логической репликации; поддержка публикаций и подписок в Schema Diff.
Apache AGE — это расширение, добавляющее в PostgreSQL функциональность графовой базы данных. Цель проекта — единое хранилище для реляционной и графовой моделей данных, чтобы пользователи могли использовать и стандартный SQL, и языки запросов к графовым базам openCypher и GQL.
ссылка на оригинал статьи https://habr.com/ru/company/postgrespro/blog/542192/
Добавить комментарий