PostgreSQL *

Эксперт Postgres Professional Андрей Зубков «нырнул» в глубины VACUUM и выяснил, что детализированная статистика может выявить глубинные проблемы, которые критически влияют на производительность. Расскажем о том, что скрывалось в глубине PostgreSQL

Привет, Хабр! На связи Андрей Бородин, в Yandex Cloud я руковожу направлением разработки СУБД с открытым исходным кодом — и я попал в Яндекс через опенсорс. Я уже немного рассказывал, что и зачем мы делаем в опенсорсных БД с точки зрения облачных сервисов, где мы развиваем PostgreSQL, Greenplum, Cloudberry, Valkey и другие решения.

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

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

В общем, если придерживаться опенсорс‑философии, может возникнуть ситуация win‑win. Сегодня с коллегами Леонидом Борчуком @leborchuk и Дмитрием Сарафанниковым расскажу пару историй про то, как это бывает с опенсорсными СУБД.

Внутристраничная очистка (HOT cleanup) — это оптимизация, благодаря которой старые версии строк могут эффективно удаляться из блоков таблиц. Освобождённое место используется под размещение новой версии строки. Освобождается только место, занимаемое версиями строк, вышедшими за горизонт базы данных (xmin horizon). В статье рассматривается алгоритм работы аналогичной оптимизации для индексов. Если горизонт удерживается, то ни внутристраничная очистка, ни вакуум не могут освободить место, и тогда новая версия строки вставляется в другой блок. Увидим на примере стандартного теста pgbench, как сильно может снижаться производительность при удержании горизонта базы данных (в случае когда есть сессия с долгим запросом или транзакцией) и разберемся в причинах снижения производительности.

Если вы, как DBA устали тратить время на изучение статистики производительности, анализ логов и настройку разрозненных инструментов мониторинга при администрировании большого количества баз данных, то у нас есть решение — PPEM (Postgres Pro Enterprise Manager). Он объединяет возможности визуализации метрик, управления экземплярами и резервным копированием, анализ производительности в единую графическую консоль, позволяя локализовать проблему и быстро принять меры. Расскажем, как мы решали «головные боли» DBA по мониторингу и аналитике БД.

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

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

Этой проблеме уже не менее 15 лет.

На входе: большая база на PostgreSQL. Вполне себе типовые отчеты с не менее типовыми запросами 1C, содержащие обращение к виртуальной таблице СрезПоследних какого-нибудь регистра сведений с большим количеством строк, выполняются неприлично длительное время. Вплоть до нескольких часов.

Причина – оптимизатор строит неверный план запроса. Причем тот же запрос на MS SQL выполняется быстро и оптимизатор не ошибается.

Сейчас будем разбираться в чем ошибается оптимизатор и какие пути решения тут возможны.

Продолжаю цикл статей про использование Greenmask - инструмента, который написан на Go специально для безопасной работы с данными PostgreSQL: он помогает делать логические бэкапы, восстанавливать таблицы и при необходимости — анонимизировать чувствительную информацию.

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

PostgreSQL — одна из самых популярных СУБД, и это во многом благодаря открытому исходному коду. В статье рассказывается о том, как открытость кода влияет на развитие PostgreSQL и создание сообщества вокруг неё.

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

При нагрузочном тестировании баз данных Tantor Postgres или других на базе PostgreSQL с использованием стандартного инструмента pgbench отсутствие фиксации деталей окружения (таких как конфигурация СУБД, характеристики сервера, версии ПО) часто приводит к нерепрезентативным результатам и необходимости повторных тестов. В статье рассматривается разработанный автором инструмент pg_perfbench, который призван решить эту проблему.

Всем привет! В данной статье я поделюсь своим опытом написания сервиса. Я не являюсь опытным или профессиональным разработчиком, я пишу свой проект и мои решения могут быть не самыми оптимальными. Эта статья состоит в основном из моих решений при написании сервиса, что могут быть не идеальными. Мой путь не является правильным и потому - судите "строго". Так же порекомендую прочитать предыдущие мои статьи.)

Привет, Хабр! Сегодня мы расскажем, как «Национальная Лотерея» — компания, обрабатывающая сотни миллионов транзакций ежегодно, полностью перестроила свою работу с данными. Изначально инфраструктура данных опиралась на Excel-отчёты, ручные выгрузки и разнородные базы — подход, типичный для старта аналитических процессов. Однако со временем такие методы стали сдерживать скорость и масштабируемость аналитики.

Я думаю, что многие, кто занимается разработкой в стеке Go + PgBouncer + PostgreSQL, уже примерно поняли, о чём будет статья — о проблеме выполнения prepared statements и сравнении работы двух популярных драйверов для PostgreSQL: lib/pq и jackc/pgx.

Если интересно — добро пожаловать под кат.

Настоящее исследование посвящено комплексному анализу глобальных климатических изменений на основе исторических метеорологических данных за период с 1950 по 2024 год. Мы фокусируемся на шести ключевых странах, представляющих основные климатические зоны планеты.

Greengage DB — это массивно-параллельная реляционная СУБД на базе Greenplum OSS, которая подходит для хранения и обработки данных. Позволяет выполнять сложные аналитические запросы над большими объёмами данных, предоставляя к ним гетерогенный доступ за счёт различного рода коннекторов и средств интеграции.

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

В этой статье поговорим о не самом гламурном, но жизненно важном — маскировании данных. Маскирование может касаться имён, телефонов, номеров карт, медицинских диагнозов и другой чувствительной информации. Если ваша компания до сих пор передает данные подрядчикам или аналитикам как они есть в базе, это в один «прекрасный» момент обязательно обернётся репутационной или финансовой проблемой для бизнеса.

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

Привет! Я Андрей Сташок, бэкенд-разработчик в KTS. В этой статье я расскажу о запуске параллельных тестов через pytest-xdist.

Почему это важно?

Объясню на нашем примере. При разработке продуктов мы постоянно выполняем юнит-тестирование. Раньше мы проверяли все последовательно, и с расширением тестовой базы время проведения испытаний заметно возрастало. Распараллеливание через pytest-xdist помогло нам сильно ускориться, и сегодня я хочу поделиться этим трюком с вами.

Я расскажу, как запускать параллельные тесты для реляционной БД PostgreSQL (с драйверами asyncpg и psycopg2) и key-value БД Redis. Для подключения к реляционной БД мы будем использовать SQLAlchemy, а для Redis — библиотеку redis. Кроме того, я рассмотрю, как автоматизировать выполнение миграций при каждом запуске тестов с использованием alembic.