PostgreSQL *

Пару дней назад был опубликован пост с решением на MySQL загадки Джиндоша (она же загадка Эйнштейна).

Предложенное решение показалось мне "неспортивным" - помимо необходимости жестко учитывать в структуре запроса количество исходных элементов ("джойнить" нужные таблицы нужное количество раз), так еще и условия в запросе приходилось многократно дублировать.

Поэтому я попробовал решить эту задачу "в общем виде", используя возможности PostgreSQL, и вот что из этого получилось.

Однажды нам нужно было уменьшить мастер кластера PostgreSQL по CPU и памяти. План был надёжный: дождаться низкой нагрузки на кластер, сменить мастер на одну из асинхронных реплик, переконфигурировать виртуальную машину с бывшим мастером и сделать switchover обратно. Казалось бы, что могло пойти не так?

Карта видимости - это достаточно простой механизм в СУБД PostgreSQL, но даже он имеет множество интересных тайн, если погрузиться в детали реализации.

В этой статье мы выясним:

1. Какие особенности есть у механизма сбрасывания и установки бита полной видимости.

2. Как Index only scan использует бит полной видимости.

3. Зачем записывать информацию об изменении карты видимости в WAL.

4. Каким образом карта видимости участвует в оптимизации предвыборки Bitmap scan.

5. Зачем механизму оценки селективности нужна карта видимости.

Продолжаю публикацию расширенных транскриптов лекционного курса "PostgreSQL для начинающих", подготовленного мной в рамках "Школы backend-разработчика" в "Тензоре".

В первой части лекции мы узнали, что такое план выполнения запроса, как и зачем его читать (и почему это совсем непросто), и о каких проблемах с производительностью базы он может сигнализировать. В этой - разберем, что такое Seq Scan, Bitmap Heap Scan, Index Scan и почему Index Only Scan бывает нехорош.

Как обычно, для предпочитающих смотреть и слушать, а не читать - доступна видеозапись (часть 1, часть 2) и слайды.

В 1970-х годах известный программист Эдгар Кодд разработал математически выверенную теорию организации данных в виде таблиц (реляций). С тех пор утекло немало воды — появилось большое количество различных коммерческих и open-source реляционных систем управления базами данных (РСУБД). Скоро стало понятно, что эффективное получение данных из базы — задача далеко не тривиальная. Если говорить прямо, она нелинейная и в общем случае NP-сложная.

Когда SQL-запрос становится немного сложнее: SELECT * FROM table, у нас появляется огромная вариативность его исполнения внутри системы — и не всегда понятно, какой из возможных вариантов эффективнее как по памяти, так и по скорости. Чтобы сократить огромное количество вариантов до приемлемого, обычно используются так называемые эвристики — эмпирические правила, которые придуманы человеком для сокращения пространства поиска на несколько порядков. Понятное дело, эти правила могут отсечь и сам оптимальный план выполнения запроса, но позволяют получить хоть что-то приемлемое за адекватное время.

В последние годы в связи с активным развитием ML начали развиваться и нейронные оптимизаторы запросов —особенность которых в том, что они самостоятельно, без участия человека, находят необходимые закономерности в выполнении сложных планов исходя из обучения на огромном количестве данных. Тенденция началась приблизительно в 2017 году и продолжается до сих пор. Давайте посмотрим, что уже появилось в этой области в хронологическом порядке и какие перспективы нас ждут.

В этом тексте хочется подробнее рассмотреть хранение данных в PostgreSQL на физическом уровне.

Для начала определимся с общеизвестными вещами. Данные хранятся в таблицах, таблицы находятся в схемах, схемы, в свою очередь, в базах данных. Под данными я тут подразумеваю одну или несколько строк. В качестве примера будем рассматривать эталон критики, по моему личному мнению, цитаты Линуса Торвальдса.

После выхода релиз-кандидата версии 17 в плане выпуска осталась последняя незакрытая дата: 26 сентября 2024 года. На этот день намечен официальный выпуск PostgreSQL 17.

В этой статье рассказывается о патчах, принятых в ходе последнего мартовского коммитфеста. Предыдущие статьи о коммитфестах 17-й версии: 2023-07, 2023-09, 2023-11, 2024-01.

Все вместе они дают подробное представление о новой версии СУБД.

Привет, Хабр! Меня зовут Вячеслав Смирнов, я руковожу техническими писателями в Platform V Pangolin. Три года назад я пришел в продукт в качестве DBA, а спустя год организовал команду техписов и стал разрабатывать документацию.

Давным-давно команда Pangolin состояла из 15-20 человек. Документация по продукту была в зачаточном состоянии. Разработчики сами пилили фичи и сами же их описывали. Но потом Pangolin вырос, вышел на внешний рынок и нам стали нужны профессиональные технические писатели.

А мир техписов разнообразен: здесь есть и редакторы-корректоры, и технари, умеющие развернуть дистрибутив. Техписы без технического опыта не всегда готовы разбираться в сложном продукте. Но, как выяснилось на практике, и технарям, пришедшим в команду, не хватало погружения в тему СУБД, чтобы писать документацию. Попробовав разные варианты, мы нашли для себя такой выход: наши техписы обязательно проходят базовые курсы DBA, и мы берем в команду не только техписов, но и DBA, желающих писать доку.

Под катом расскажу, почему я считаю, что техпису обязательно погружаться в продукт настолько глубоко. Буду рад вашим мнениям.

Кластеризация необходима для большинства СУБД уровня Enterprise. Есть много способов создать или развернуть кластер: от бесплатных до дорогих, от простых до сложных. У разных вендоров свои приоритеты: одни делают настройку кластера в пару кликов (как в MS SQL), другие фокусируются на надежности и функциональности (Oracle).

В мире СУБД на базе PostgreSQL на сторону которых всё активнее переходит российский IT, тоже есть свои кластерные инструменты и решения: как бесплатные и открытые Patroni, Stolon, pacemaker/corosync, так и проприетарные. Лидер по популярности среди открытых решений – Patroni. Сегодня я расскажу, почему настраивать кластеризацию на нем руками весело только первые пару раз. Поговорим об особенностях поддержки Patroni в Proxima DB, снижении порога входа для новичков и повторяемости конфигураций. 

Из жизни малышей и гигантов

PGlite 0.2

Опенсорсный проект 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.

Отчасти это действенный совет, отчасти — вопрос к читателям.

Совет: при создании нового приложения, требующего постоянного хранения данных, как это и бывает в случае большинства веб-приложений, по умолчанию следует выбирать Postgres.

В апреле этого года мы, команда производительности из Postgres Professional, совместно с коллегами из Selectel решили протестировать несколько дистрибутивов PostgreSQL и узнать, как они себя поведут на разных архитектурах. С результатами можно ознакомиться в этой статье, но, как сразу было верно отмечено читателями, там был один важный косяк –  мы не сравнили производительность ванильного PostgreSQL с применением всем известных настроек по улучшению производительности и Postgres Pro Enterprise из коробки as is. Терпеть такое не было решительно никакой возможности, поэтому сегодня будет продолжение истории и ответ на важный для многих вопрос: «А есть ли у нашего форка хоть какое-то преимущество перед бесплатной ваниллой?» Или мы просто накатили общеизвестный конфиг и занимаемся импортозаместительным переклеиванием наклеек?

Привет, Хабр! Меня зовут Семен Попов, я отвечаю за разработку хранилища клиентских данных в Сбере. Расскажу, как мы в эксплуатации перешли с одной базы данных на другую — а именно, с Oracle на Platform V Pangolin, разработку СберТеха на основе PostgreSQL, доработанного в области безопасности, надёжности и производительности.

Думаю, вы знаете, что поиск эффективных решений – это половина успеха. Я сам прошел через все эти тернии, когда работа с данными казалась слишком сложной и запутанной. И именно тогда я открыл для себя потрясающие возможности PostgreSQL, которые значительно упростили мою жизнь.

Сегодня я хочу поговорить о трех фичах PostgreSQL, которые помогут сделать работу более продуктивной и вдохновить на создание более сложных и интересных проектов.

Эти фичи уже не раз выручали меня в сложных проектах, и я уверен, что они станут надежными помощниками и в вашей разработке.

Хочу поделиться примером‑инструкцией как получить инсайты из геоданных без регистрации, смс (только open‑source и бесплатные инструменты: OSM, python, Портал открытых данных Правительства Москвы, DataLens).

Как сделать так, чтобы дашборд не "умер" от количества точек и тяжелых полигонов, работал сравнительно быстро и давал пользователю представление общей картины, читайте под катом.

Оговорюсь, заголовок кликбейтный, и примерно последние 2 года своей трудовой деятельности в рамках своей компании считаюсь фуллстек разработчиком, но все же моя база это фронтенд и специального образования я не имею.

Я хочу поделится тем, каким образом я подготовился к сертификации. Какого рода вопросы были. Насколько сложно это было для человека, который о СУБД не знал ничего и пользовался БД на уровне элементарных запросов. И не большая часть моих размышлений на тему того на сколько это вообще нужно.

СУБД Postgres Pro – сложный механизм, который можно гибко настраивать под конкретный тип нагрузки. Для этого в нём имеется множество параметров и инструментов. Например, одним из главных потребителей ресурсов CPU является оптимизатор/планировщик запросов, который отвечает за построение оптимального плана выполнения. Существует большое количество параметров, которые прямо или косвенно влияют на работу планировщика, но к их изменению надо подходить очень осторожно, т. к. возможен обратный эффект. Например, параметры _collapse_limit могут и помочь оптимизатору рассмотреть большее количество вариантов планов, и негативно повлиять на время планирования.

Сегодня я расскажу, как мы решали реальную проблему производительности и высокой (> 90%) утилизации ресурсов CPU на промышленном «боевом» сервере с СУБД Postgres Pro Enterprise 15, обслуживающем запросы бизнес-приложения, какие для этого использовали инструменты и что мы изменили в настройках СУБД.

Данная статья является продолжением: PostgreSQL 16. Изоляция транзакций. Часть 2.

В этой части мы рассмотрим, из каких частей состоит страница в PostgreSQL, как выполняются операции CRUD (создание, чтение, обновление, удаление) для строк с сохранением нескольких версий одной и той же строки в таблице и как на это влияют транзакции. Также рассмотрим вложенные транзакции.

Добрый день, уважаемые читатели Хабра. В один день для моего pet-проекта понадобилось сделать добавление адресов клиентов, и проверка входит ли этот адрес в зону доставки. 

Так как статей на эту тему на хабре раз и обчелся, то вот держите еще одну 😁

В этой статье мы разберем, что такое геометрия, как с ней можно работать в sql и no-sql базах данных. Приступим.

Привет, Хабр! Меня зовут Юрий Мишин, я технический директор в департаменте банковского ПО компании R‑Style Softlab. В этой статье я расскажу о масштабном проекте по переводу одного из ключевых продуктов компании 一 автоматизированной банковской системы (АБС) 一 на импортозамещенный стек.