PostgreSQL *

Aurora DSQL

Эта Аврора наделала шуму. Откликов на анонс много. Люди говорят о сомнительной (но громко заявленной) совместимости с Postgres. Официальный анонс был такой:

AWS Announces New Database Capabilities Including Amazon Aurora DSQL- the Fastest Distributed SQL Database

Мэт Гарман (Matt Garman), гендир AWS, объявил на сборище re:Invent в Лос-Анджелесе в присутствии 60 тыс. очных и 400 тыс (это ж почти полмиллиона!) онлайновых гостей о принципиально новой, геораспределённый СУБД Aurora DSQL. Более того: это была его инаугурационная гендирская речь. Так что ставки высоки. Видео есть на сайте re:Invent. Документация Aurora DSQL здесь.

Это гео‑распределённая SQL‑база с доступностью 99.999%, практически неограниченной масштабируемостью, строгой согласованностью и нулевыми заботами об управлении инфраструктрой.

Главная целевая аудитория — те, у кого приложения, обслуживающие миллионы клиентов по всему Земному Шару.

У СУБД архитектура active‑active (т. е. примерно мультимастер), и все транзакции, записанные в одном регионе, согласованно отображаются на другие регионы. И вообще утверждается, что удалось избавиться от компромиссов «или‑или» (trade‑offs): она И быстрая, И надёжная. Для этого пришлось «переизобрести» архитектуру — отвязать обработку транзакций от хранения. Обещано, что чтение и запись будут в 4 раза быстрее, чем у конкурентов.

Aurora DSQL при синхронизации узлов использует Amazon Time Sync Service на каждом экземпляре Amazon Elastic Compute Cloud (EC2), а там всё привязано к атомным часам, связь с которыми через спутники. Этот же механизм используется для работы глобальных таблиц DynamoDB.

DSQL Vignette: Aurora DSQL, and A Personal Story

В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.

Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.

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

Всем привет! На связи Ришат Садыков из Spectr. Сегодня мы поговорим про explain в Postgres. Это объемная тема, по ней можно найти много материала. В статье я постарался собрать только ту информацию, которой достаточно для начала использования explain. Материал поможет эффективно использовать его для повышения производительности запросов тем, кто этим никогда не занимался.

Это третья и заключительная часть цикла статей по настройке памяти в PostgreSQL. Полагаю, она получилось уже не такой заумной, как предыдущие две, и представляет из себя некий сухой остаток с собирательным примером, в котором показано как выбирать параметры PostgreSQL по настройке оперативной памяти. Если же хочется погрузиться в руду, то милости просим в Часть 1 и Часть 2. Тем не менее, цепочка логических рассуждений сохранена – как делаем, зачем и почему.

Ситуация: у вас PostgreSQL, в котором копятся гигантские таблицы. Вы попытались их разбить по времени или по ID, но все уперлось в рутинный менеджмент: надо создавать новые партиции, чистить старые, не забыть настроить индексы... Короче, превращается это в сериал на сто сезонов. А может, вы используете встроенное декларативное партиционирование, но хочется чего-то поудобнее? Вот тут хорошо поможет pg_partman. Это расширение — фактически «менеджер по партиционированию», который сделает половину этой рутины за вас.

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

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

Но на практике вышло так, что наши клиенты всё чаще сталкиваются с проблемами, которые породил этот подход. Например, в международном комьюнити постгреса считается, что 64 ядра — это предельный размер сервера, где его вообще можно запустить. А мы всё чаще видим, что это становится минимальной типовой конфигурацией. Другим таким узким местом стал счётчик транзакций, ситуация с которым намного более интересная. Поэтому о нём мы сегодня и поговорим. В чём там проблема, как мы её решили, и что на эту тему думает международное комьюнити.

Мы успешно обновили кластер PostgreSQL с версии 13 до 16, обеспечив минимальный простой и высокую производительность. Процесс включал в себя создание новой реплики через логическую репликацию, перенос роли мастера на обновлённую реплику и настройку потоковой репликации. Несмотря на некоторые сложности, такие как управление LSN и проблемы с подписками, нам удалось сохранить данные и обеспечить синхронизацию.

Подробности читайте в статье.

Привет, Хабр! Сегодня поговорим о VACUUM в PostgreSQL — штуке, которая спасает базы данных от захламления.

PostgreSQL использует MVCC для управления транзакциями. То есть каждая операция вставки, обновления или удаления оставляет после себя версию строки. Старые версии остаются в таблице, пока VACUUM их не зачистит.

В то время, как пользователи видят позитивные стороны технологий, мы, разработчики, обычно сталкиваемся с ограничениями/недоработками/багами и видим наш продукт с совсем другой стороны. Вот и в этот раз: после публикации результатов сравнительного тестирования где я прогонял запросы теста Join-Order-Benchmark на базе с партициями и без, меня не отпускало ощущение, что всё-таки что-то я не досмотрел и при наличии партиций постгрес должен строить план хуже, чем без них. И это должен быть не просто баг, а технологическое ограничение. И вот, методом разглядывания потолка удалось-таки найти тонкое место - запросы с лимитами.

Сегодня посмотрим на примере задачки из Advent of Code зачем и как можно обойти ошибку aggregate functions are not allowed in a recursive query's recursive term, возникающую при попытке агрегировать какие-то данные внутри шага рекурсии на PostgreSQL — «если нельзя, но очень хочется, то можно».

Привет, Хабр!

Когда мы говорим о PostgreSQL и оптимизации запросов, большинство тут же вспоминает B-Tree индексы, GIN, GiST и так далее. Но вот BRIN иногда остается в тени, хотя в некоторых сценариях он способен творить чудеса с производительностью, особенно когда ваши таблицы размером с космический лифт, а места на диске жалко. Сегодня я расскажу, как именно работает BRIN.

Оптимизация Asymmetric Join (AJ) — это новый подход к объединению партицированных связей (partitioned relation, PR) и непартицированных связей (non-partitioned relation, NR). Она заключается в том, что каждая партиция присоединяется с помощью NR, а результаты объединяются путём APPEND. Всё это выглядит как эволюция техники partitionwise join (PWJ).

Меня зовут Сергей Гребенюк, я лидер разработки Sidec (Росреестр). Расскажу, как решили задачу объединения двух топиков с соотношением один ко многим и почему не устроило решение на Kafka-streams (kafka docs) и RocksDB (github). А также о том, как, опираясь на гарантии доставки exactly-once (EOS) (confluent docs), смогли снизить требования к ресурсам в несколько раз.

На иллюстрации показаны два подхода к объединению топиков: с persistent cache и in-memory cache. Мы перейдём от первой схемы ко второй. 

Поддержка полей JSONB в СУБД PostgreSQL стала результатом большой работы команды PostgresPro и приблизила использование форматов и инструментов для работы с JSON в этой базе данных к статусу полноценной. В отличии от текстового в своей основе типа JSON, JSONB позволяет строить индексы по содержимому поля, что должно значительно ускорить поиск по таким данным. Также он реализует некоторые оптимизации, например не поддерживает дубликаты ключей в рамках одного уровня JSON-структуры, а если они все-таки встречаются, использует последнее значение.

В этой статье мы попробуем подключить и использовать функционал JSONB-полей в нашем java-приложении на фреймворке Jmix. Если вы используете Spring, решения по настройке и, может быть, даже использованию могут слегка отличаться, т. к. там используется ORM Hibernate.

Эта история начиналась с процесса валидации FK на очень больших таблицах (1TB+).
Далее я расскажу, какие нетривиальные проблемы встретились по пути, как я их решал, и каким образом можно исследовать довольно сложные проблемы производительности базы данных Postgres.

Работа над ошибками

PostgreSQL: Out-of-cycle release scheduled for November 21, 2024

Дело прошлое - уже вышла 17.2 со свитой из более почтенных версий, где всё поправили. Но история поучительная.

Итак: вышла новость, с восклицательным знаком, как обычно: PostgreSQL: PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 Released!

Ура! Прикрыли дыру CVE-2024-10976: в таблицах с безопасностью на уровне строк можно было подсмотреть или изменить те строки, в которые лезть не положено. После CVE-2023-2455 и CVE-2016-2193 многое поправили, но пропустили случаи подзапросов, запросов с WITH и другие. И всё это в версиях с 12 по 17. Ещё и закрыли уязвимость CVE-2024-10979. Но:

A change to ResultRelInfo - A Near Miss with with Postgres 17.1

Всем привет. Меня зовут Сергей, я — эксперт компании Bercut. За плечами — более 20 лет работы с различными СУБД (PostgreSQL, Oracle, MS Access, MS FoxPro, Borland InterBase) и высоконагруженными системами на их основе.

В Bercut мы занимаемся разработкой и развитием IT‑продуктов, решений для операторов цифровых услуг и мобильных сервисов. Наши системы работают на различном железе, разных СУБД и обслуживают 24×7x365 в режиме онлайн сотни миллионов абонентов.

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

Это не лонгрид (как кажется с первого взгляда), а краткое практическое руководство.Есть навигация, можно сразу перейти на нужные пункты.

Сегодня поговорим о мощной штуке в PostgreSQL, которая одновременно помогает и открывает портал в ад: динамические SQL‑запросы. Динамика — это когда SQL собирается на лету, а не пишется заранее статичным текстом. Звучит неплохо, но при неправильном подходе легко превращается в катастрофу.

Продолжаем исследовать и настраивать память в PostgreSQL. Начало см. здесь.

Будет ешё итретья — заключительная часть, где я постараюсь максимально доступным языком рассказать уже методику выбора настроек. А пока предлагаю набраться терпения и ознакомиться со следующей порцией исследования по выбору настроек оперативной памяти PostgreSQL. Предупреждаю, будет не просто и, наверняка, не каждый доберется до конца.

В первой части были рассмотрены параметры shared_buffers, maintenance_work_mem, autovacuum_work_mem. А сегодня на повестке параметры temp_buffers и work_mem.

Привет, Хабр! Меня зовут Игорь, и я один из разработчиков НОТА ЮНИОН. При подборе сотрудников (рекрутменте) есть много рутинных задач, отнимающих немало времени. Чтобы рекрутеры могли больше времени уделять, скажем так, творческой части своей работы, есть решение «Нота Юнион». Это набор инструментов для автоматизации подбора сотрудников. И в этом году мы перевели его базу данных с MariaDB на PostgreSQL. Задача оказалась масштабной, пришлось изрядно потрудиться. Хочу рассказать о том, почему мы решили поменять базу и как это реализовали. Возможно, вам это поможет сразу выбрать более подходящий под ваш продукт вариант.