PostgreSQL *

Из ролика "Реальный собес на бекенд программиста": "А знаешь что-нибудь про горизонт событий транзакции? Знаю про чёрные дыры, а вот про транзакции не очень. Ну расскажи про чёрные дыры тогда. Вкратце."
По умолчанию утилита 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/

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

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

Занимаемся не только разработкой, но и помогаем освоиться в мире PostgreSQL новичкам. Обновлённая книга для тех, кто только начинает изучение темы СУБД, уже доступна для свободной загрузки. Кому и как поможет «Postgres. Первое знакомство», расскажем подробнее.

Привет, Хабр! В конце января мы получили сертификат ФСТЭК на нашу СУБД Proxima DB и выпустили новую версию 3.1 для редакций Proxima DB Core и Advanced.

На самом деле по количеству добавленных фич новую версию можно было бы переименовывать в 4.0 или даже в 5.0 (софтверные гиганты здесь обычно показывают гору фантиков от сникерсов и пустых стаканчиков от кофе, использованных при выпуске нового релиза). Но мы придерживаемся концепции изменения мажорной версии Proxima DB с изменением мажорной версии PostgreSQL, поэтому новая версия — именно 3.1.

В этой статье хотим поделиться:

• С какими новыми требованиями регуляторов мы столкнулись в процессе;

• Как технически реализовали новую для российских СУБД функцию мониторинга производительности в реальном времени;

• Как работают другие ключевые фичи: возможность подключать другие СУБД на основе PostgreSQL, новая роль DBaaS-сервера, упрощенный процесс инсталляции базовой редакции СУБД.

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

PL/R — это процедурный язык для PostgreSQL, который позволяет писать функции на языке R. Когда хочется использовать все богатство статистических пакетов и алгоритмов R, не покидая привычного SQL‑окружения, PL/R приходит на помощь. Плюс ко всему: нет необходимости создавать отдельные сервисы для анализа, что уменьшает задержки и упрощает архитектуру приложения.

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

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

Используем динамическое программирование для подсчета количества вариантов размещений.

В PostgreSQL 18 добавят виртуальные сгенерированные столбцы (комит).

Ранее PostgreSQL уже поддерживал сгенерированные столбцы (начиная с версии 12), но только в варианте STORED, когда результат вычислений сохраняется в таблице. Теперь появилась возможность вычислять значения "на лету" при чтении, что экономит место и даёт больше гибкости в проектировании схем данных.

Как создать виртуальный столбец?

В мире разработки всегда наступает момент, когда необходимо переосмыслить используемые технологии. В Hikasami, наблюдая за ростом используемых ресурсов и усложнением бизнес-задач, мы столкнулись с выбором: продолжать использовать привычный NestJS или искать новое решение, способное обеспечить высокую производительность и масштабируемость. Ответ оказался очевиден - нужно перейти на Go.

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

Почему Go?

Привет! Меня зовут Дмитрий Руденко, я из команды Databases Т-Банка. В последние годы наблюдается тенденция к переходу на Postgres со стороны многих команд и компаний, что приводит к увеличению количества Postgres-баз данных, требующих эффективного мониторинга и управления. 

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

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

Продолжаем следить за новостями из мира PostgreSQL 18. Январский коммитфест принес много полезных изменений в области мониторинга и не только.

А самое интересное из предыдущих коммитфестов можно прочитать здесь: 2024-07, 2024-09, 2024-11.

pg_probackup 3 — не просто обновление, а полная перезагрузка системы резервного копирования PostgreSQL. Пока сообщество затаило дыхание в ожидании релиза, мы разберем по косточкам все ключевые изменения: от полностью переработанной архитектуры и нового репликационного протокола до революционной возможности восстановления отдельных баз данных и поддержки FUSE. Узнайте, как LibProbackup3 – полноценный SDK – открывает новые горизонты для интеграции в любую инфраструктуру, а улучшенная поддержка лент и S3, наконец, решает наболевшие проблемы.