PostgreSQL *

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

В этой статье быстро разберём, как устроен PostgreSQL – от хранения данных в Heap и работы с FSM/VM до создания своего FDW с компрессией на базе zlib.

"Postgres масштабируется" - нет других двух слов, которые вызывали бы больше споров. По крайней мере, в кругах, где я общаюсь, в подвале компании, где инфраструктурные эльфы заставляют Rails-приложение работать. Многие верят, вопреки всему и маркетинговым кампаниям Big NoSQL, что знакомая технология лучше, чем новый неизвестный инструмент, о котором только что рассказали на совещании руководства.

Честно говоря, я понимаю их позицию. Заставить Postgres писать больше данных может быть сложно. Вам нужно больше оборудования. В большинстве случаев его можно получить, просто нажав кнопку "Обновить". Но когда вы дошли до экземпляра r5.24xlarge с 5 репликами такого же размера, и ваши процессы vacuum всё ещё отстают от графика, ситуация становится довольно пугающей.

Именно здесь начинается испытание для настоящего инженера. На пределе возможностей. Я говорю не о WebAssembly. Я говорю об инженерном духе, который смотрит на проблему под давлением руководства и вместо того, чтобы бежать к ближайшей команде продаж с большими обещаниями (но малым количеством фактов о вашем конкретном случае), решает её, используя базовые принципы.

А базовый принцип говорит нам, что нам нужно. У Postgres закончилась пропускная способность для записи. Либо из-за блокировок при работе с WAL, либо что-то застопорило vacuum. Вероятно, это та неактивная транзакция, которая открыта уже 45 секунд, пока приложение делает запрос к Stripe, но это не наша забота. Мы - инфраструктурная команда, и наша задача - заставить базу данных работать.

Подпрограммы (функции и процедуры) со свойством SECURITY DEFINER выполняются с правами владельца. Это даёт возможность непривилегированному пользователю выполнить маскировку объектов, к которым относятся не только таблицы, но и подпрограммы и выполнить команду с правами владельца подпрограммы. Если владелец является суперпользователем, то можно выполнить любую команду с правами суперпользователя. В статье рассматривается, как выполнить маскировку функции и как создавать безопасные подпрограммы.

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

На одной из конференций PGConf мы обнаружили, что комьюнити с большой опаской относится к использованию JSONB-полей в своих системах. Интернет при этом не столь радикален. Наша же команда в это время вовсю использует JSONB у себя в проекте. Мы решили поделиться нашим вполне успешным кейсом в реальной нагруженной системе с сотнями миллионов строк в таблицах, где эти поля используются.

Привет, Хабр! Сегодня разберём, как реализовать A/B-тестирование на чистом PostgreSQL, без выгрузки данных в сторонние системы. Рассмотрим полный цикл: от структуры таблиц и оптимизации запросов до статистического анализа (T-тест, Манна-Уитни, байесовские методы) и визуализации результатов.

Если экземпляр PostgreSQL был некорректно остановлен, то перед восстановлением файлов выполняется синхронизаций всех файлов кластера. Способ синхронизации определяется параметром конфигурации recovery_init_sync_method. В статье рассматривается, как ускорить запуск экземпляра и резервирование, если в директории PGDATA много файлов.

Если данные в БД растут как на дрожжах, а вместе с ними и расходы на хранение, то пора познакомиться с концепцией управления жизненным циклом информации (ILM). Мы уже внедрили в Postgres Pro Enterprise 17 возможность для внедрения автоматического переноса редко используемых данных в более дешёвые хранилища. Подробности в статье.

В мире разработки и работы с базами данных Bloom-фильтры – это мощный, но малоизвестный инструмент, который может значительно ускорить выполнение запросов и снизить нагрузку на систему. Однако, несмотря на их потенциал, многие разработчики даже не знают, что Postgres поддерживает Bloom-фильтры "из коробки" (функциональность Bloom-фильтров доступна сразу после установки Postgres, при включении соответствующего расширения) через расширение bloom.

Bloom-фильтры особенно полезны в ситуациях, когда нужно быстро проверить, принадлежит ли элемент к множеству, или когда требуется оптимизировать запросы с несколькими условиями. Например, они могут ускорить JOIN-запросы, поиск по нескольким столбцам или агрегатные функции.

В этой статье мы разберем, что такое Bloom-фильтры, как они работают в Postgres, и в каких случаях их использование может быть полезным. Мы также рассмотрим практические примеры и покажем, как Bloom-фильтры могут помочь в оптимизации запросов.

Из ролика "Реальный собес на бекенд программиста": "А знаешь что-нибудь про горизонт событий транзакции? Знаю про чёрные дыры, а вот про транзакции не очень. Ну расскажи про чёрные дыры тогда. Вкратце."
По умолчанию утилита pgbench запускает тест "TPC-B (sort of)" и используется для быстрой оценки производительности PostgreSQL. Горизонт удерживается на время выполнения любого запроса или транзакции. В статье рассматривается насколько удержание горизонта базы данных (vacuum cleanup horizon) уменьшает прозводительность (например, значение tps тестов). Также приводится запрос для мониторинга горизонта баз данных и параметры, которые используются для защиты от долгих транзакций и запросов.

При создании индексов типа btree в PostgreSQL есть опции DESC и NULLS FIRST. В статье рассматривается как эти опции влияют на производительность и размер btree-индексов PostgreSQL.

По умолчанию индекс строится в возрастающем порядке (ASC), то есть в дереве индекса "слева" меньшие значения, "справа" большие. При создании индекса можно указать обратный порядок: DESC. Свойство ASC и DESC при создании индекса не влияет на эффективность использования индекса планировщиком (ORDER BY ASC или DESC).

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

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

Дважды применяем волновой алгоритм для нахождения единственного кратчайшего пути и самосоединение для поиска "читов".

При выполнении тестов периодически сталкивался с неожиданными изменениями результатов тестов после рестарта linux и при обновлении версии linux. Причиной оказался источник времени. В статье рассмотрен как влияет источник времени на выполнение команды explain analyze

Здесь я описываю результаты разработки одного расширения Postgres, которое сделал просто ради любопытства. Суть его состоит в автоматическом управлении расширенной статистикой по колонкам таблицы. Идея родилась в момент, когда заканчивая работу над очередным "умным" query-driven продуктом улучшения качества планирования Postgres я осознал, что архитектура этой СУБД пока ещё не готова к полностью автономной работе - автоматическому детектированию плохих планов и подстройки оптимизатора. Так может быть зайти с другой стороны, и попробовать сделать автономный data-driven помогатор?

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

Быстрый путь вставки в индексы

В PostgreSQL есть оптимизация вставки в индекс типа btree, позволяющая не спускаться с корня дерева индекса. Серверный процесс, который выполнил вставку в правый листовой блок, запоминает ссылку на него и при последующей вставке, если новое значение больше предыдущего (или пусто) и не проходит путь от корня до листового блока. Оптимизация используется при числе уровней в индексе начиная со второго (макрос BTREE_FASTPATH_MIN_LEVEL).

Если строка не помещается в блок (страницу), то в PostgreSQL применяется техника выноса полей в отдельную таблицу, называемую TOAST-таблица. Техника выноса и хранения называется TOAST (The Oversized-Attribute Storage Technique, техника хранения атрибутов большого размера). В статье достаточно детально рассматривается алгоритм работы TOAST. Знание алгорима и его граничные значения полезно, чтобы понимать каким образом хранятся данные в таблицах.

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

Продолжаем серию статей о создании BI-системы в компании Sminex. Сегодня поговорим об автоматизации и оптимизации работы инженеров данных и BI-разработчиков. Работа с данными всегда требует поиска баланса между удобством, скоростью и качеством. В этой статье мы сосредоточимся на удобстве.

В статье описан алгоритм вакуумирования PostgreSQL и приводится сравнение числа сканирований индексов в 17 версии PostgreSQL и предыдущих версиях.

Есть пять фаз вакуумирования каждой таблицы, mwiew, toast и индексов на них: SCAN_HEAP,  VACUUM_INDEX,  VACUUM_HEAP,  INDEX_CLEANUP,  VACUUM TRUNCATE. Помимо них есть подготовительная фаза инициализации и завершающая фаза.

Поиск — это сложно. Важная часть многих приложений, которую нелегко реализовать правильно. Особенно в случае с RAG-пайплайнами, где на качество поиска завязан весь процесс.

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

Эрик Закариассон, разработчик и автор блога Anyblockers, рассмотрел в своей статье, как использовать Postgres для создания надёжной поисковой системы. В рамках задачи автор объединил три техники:

1. Полнотекстовый поиск с tsvector

2. Семантический поиск с pgvector

3. Нечёткое сопоставление с pg_trgm

4. Бонус: BM25

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

Предыдущий пост: https://habr.com/ru/articles/677290/

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

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