PostgreSQL *

Я уже не раз писал, что условия с несколькими неравенствами (<, <=, >=, >) обычно плохо подходят для индексирования "классическим" btree, вызывают "тормоза", и необходимо придумывать различные нетривиальные подходы в PostgreSQL, чтобы добиться хорошей производительности подобного запроса.

В этой статье мы не только рассмотрим способы решения подобных задач "в общем виде", но и покажем, как нам удалось автоматизировать их решение в рамках функционала рекомендаций индексов нашего сервиса анализа планов explain.tensor.ru и его новых возможностях.

Управление резервными копиями является одним из ключевых моментов в любой стратегии администрирования баз данных. Это гарантирует, что в случае сбоя или потери данных вы можете быстро восстановить всю информацию. pgBackRest — популярное решение для резервного копирования и восстановления PostgreSQL, которое предоставляет множество функций для управления резервными копиями. Тем не менее, по умолчанию стандартная конфигурация pgBackRest часто объединяет операции резервного копирования и удаления устаревших копий в одном процессе. 

В прошлый раз я описал, как можно поставить задачу (Job) в очередь Laravel из хранимой процедуры или триггера PostgreSQL.

В этой статье я расскажу, как можно преобразовать события, возникающие в PostgreSQL, в события Laravel.

Рабочий пример выложен на GitHub.

PostgreSQL 16 вносит немало улучшений в планировщик запросов и позволяет выполнять многие SQL-запросы быстрее, чем в предыдущих версиях PostgreSQL.

Если вы посмотрите на PG16 release notes, то увидите некоторые из этих улучшений. Но из-за объема изменений, вносимых в каждом выпуске PostgreSQL, невозможно предоставить достаточно подробную информацию о каждом изменении.

В этом посте вы получите глубокое представление о 10 улучшениях, внесенных в планировщик запросов PostgreSQL 16. Для каждого из улучшений будет сравнения выходных данных планировщика PG15 и PG16, а также примеры того, что изменилось, в виде автономного теста, который вы можете попробовать сами.

Patroni – опенсоурсный инструмент, с которым можно подключить аварийное управление для кластеров Постгресе. Т.е можно автоматически преключать работу на резервный сервер в случае сбоя основного.

Patroni может интегрироваться с различными системами распределенной конфигурации, включая etcd, ZooKeeper, Consul и Kubernetes.

Доброго времени суток. Основываясь на своём опыте хочу представить некоторые рекомендации при разработке кодовой базы на SQL.

Данные рекомендации получены горьким опытом, так что надеюсь, они Вам помогут :)

File system level backup  в Postgres это первое чему нужно научится при использовании Postgres . Никакие pg_dump \ pg_restore не заменят Полный бэкап на уровне файлов. File system level backup это первая ступень для подготовки к Continuous archiving. Понимание архитектуры хранения – это фундамент, по которому можно понять сможете ли Вы жить с Postgres на больших объемах или у Вас другой путь?

Привет, Хабр! С вами снова AliExpress Order Management System. Сегодня поговорим о том, как мы увеличивали количество шардов без длительного даунтайма. Спойлер: в конце - самое интересное ;)

Как бы вы решали такую задачу? Предположим, есть таблица с купонами, и у купонов есть некая дата устаревания valid_until. Вам надо обеспечить такое ограничение (constraint) на уровне БД, чтобы у одного человека мог быть только один действующий купон.

Т.е., таблица изначально выглядит так:

CREATE TABLE coupons (
    id  bigint primary key generated by default as identity,
    user_id bigint not null,
    created_at timestamp not null,
    valid_until timestamp not null
)

Привет, Хабр! Это снова мы — Павел Конотопов и Михаил Жилин, сотрудники компании Postgres Professional. Напомню, что Павел занимается архитектурой построения отказоустойчивых кластеров, а я анализом производительности СУБД. У каждого из нас за плечами более десяти лет опыта в своей области.

Во второй части статьи «Мифы и реалии «Мультимастера» в архитектуре СУБД PostgreSQL» мы говорили о гарантии согласованности данных и разрешение конфликтов. Разобрали как выявлять и разрешать конфликты, используя разные способы. Теперь пришла пора одной из самых важных характеристик хранения данных — надёжности.

Привет, Хабр! Это снова мы — Павел Конотопов и Михаил Жилин, сотрудники компании Postgres Professional. Напомню, что Павел занимается архитектурой построения отказоустойчивых кластеров, а я анализом производительности СУБД. У каждого из нас за плечами более десяти лет опыта в своей области.

В первой части статьи «Мифы и реалии «Мультимастера» в архитектуре СУБД PostgreSQL» мы посмотрели как развивалась технология «Мультимастер» в экосистеме PostgreSQL. Обсудили существует ли «Честный Мультимастер», какие у него реализации и как его следует применять. Теперь поговорим о надёжности хранения данных.

Привет, Хабр! Недавно мы делали доклад на конференции HighLoad 2023 — «Мифы и реалии Мультимастера в архитектуре СУБД PostgreSQL». Мы — это Павел Конотопов (@kakoka) и Михаил Жилин (@mizhka), сотрудники компании Postgres Professional. Павел занимается архитектурой построения отказоустойчивых кластеров, а Михаил — анализом производительности СУБД. У каждого за плечами более десяти лет опыта в своей области.

Порассуждаем о том, как развивалась технология «Мультимастер» в экосистеме PostgreSQL, остановимся на том, что она из себя представляет, на каких внутренних механизмах PostgreSQL основана и как её можно использовать.

Мы также поговорим о том, существует ли «Честный Мультимастер» (само понятие «Честный Мультимастер» достаточно специфично и в основном употребляется в кругу разработчиков), какие реализации у него есть и как его следует применять.

В начале 2024 года мы решили провести новое исследование производительности 1С:Предприятие на СУБД MSSQL и PostreSQL и вот что получилось...

Всем привет! Меня зовут Александр, в данное время я на фрилансе занимаюсь проектом по созданию очередного маркетплейса. В процессе работы мы столкнулись с далеко не новой проблемой организации хранения информации о товарах, имеющих различные характеристики и цену, зависящую от характеристик. На нашем проекте применяется принцип CQRS: запись осуществляется в Postgres, чтение происходит из OpenSearch, а данные между ними перемещаются по шине, реализованной на Kafka. Такой подход обусловил использование реляционной БД для решения несвойственной ей задачи.

Чтобы увидеть, почему эта задача не нак проста, как кажется с первого взгляда, представим, что в нашем каталоге есть футболки мужские всего с двумя атрибутами: цвет и размер. Мы хотим хранить товар с названием "Футболка Junior Developer", она представлена в синем, красном и зеленом цветах, и каждый цвет доступен в нескольких размерах. Добавляя немного сложности, представим, что цена конкретной футболки также варьируется в зависимости от цвета и размера. Как представить эту сущность в реляционной базе данных, с учетом того, что продавец футболки может в какой-то момент добавить новые атрибуты для своего товара, например, габариты упаковки для отправки (длина, ширина, высота)?

С одной стороны, можно использовать подход: Entity-Attribute-Value. Он позволяет гибко настраивать связи между сущностями, их атрибутами и значениями, сохраняя возможность динамического добавления новых атрибутов сущности. Однако у такого подхода есть свои недостатки. На них останавливаться не буду - в статье: "Замена EAV на JSONB в PostgreSQL" они приведены, также там есть сравнение по производительности и памяти EAV и JSONB.

В чем сила, бр..Постгреса? Сила PostgreSQL во многом заключается в его расширяемости, которая позволяет открыть больше функциональности.

В статье рассмотрим четыре популярных расширения на PostgreSQL на 2024 год.

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

Суть MERGE заключается в ее универсальности: она позволяет объединить операции INSERT, UPDATE и DELETE в одном запросе, автоматически выбирая нужное действие в зависимости от того, существует ли соответствующая запись в целевой таблице.

Вместо нескольких отдельных запросов INSERT, UPDATE, DELETE MERGE сокращает накладные расходы на сетевой трафик и уменьшает количество обращений к диску. MERGE облегчает реализацию шаблонов SCD и других сложных сценариев управления данными.

MERGE в PostgreSQL работает с соблюдением строгих стандартов SQL, обеспечивая совместимость и переносимость кода. Также PostgreSQL обрабатывает конфликты на уровне строк, позволяя тонко настраивать логику обработки данных с использованием условий WHEN MATCHED и WHEN NOT MATCHED.

Сравнивая с предшествующим подходом INSERT ON CONFLICT, MERGE предлагает больше возможностей для оптимизации и управления данными. INSERT ON CONFLICT был ориентирован преимущественно на обработку конфликтов при вставке, в то время как MERGE расширяет этот функционал.

Уже немало копий поломали в поиске грааля идеального способа интеграционного тестирования с использованием БД.

Вашему вниманию предлагается способ решения этой проблемы самым минималистичным способом без необходимости создавать угрозы безопасности вашего кластера или создавать разработчикам невыносимые условия труда. Впрочем что может быть хуже сломанной кофе-машины или отсутствия лавандового рафа?

Умер Никлаус Вирт

1-го января этот мир покинул Великий человек - Никлаус Вирт (Niklaus Emil Wirth). Его создания: Pascal, Algol-W, Euler, Modula-1, 2, Oberon-1, 2.

Но прежде всего Никлаус был главным идеологом программирования сверху вниз, структурного программирования.

Релизы

Shardman 14.10.2, 14.10.3

Ещё недавно мы писали, что в документации по Postgres на сайте Postgres Professional появился четвёртый столбец - ora2pgpro. А сейчас там 5 столбцов: появился Shardman. Всего пока 2 релиза:

Postgres Pro Shardman 14.10.2 и Postgres Pro Shardman 14.10.3.

В 14.10.3 улучшения и исправления. А в заметках к релизу предыдущего можно узнать, что:

Предисловие

Простой python-cкрипт для парсинга спортивной статистики по баскетболу с популярного сайта