В статье рассматривается, сколько места занимают поля с пустыми значениями и стоит ли их использовать с точки зрения экономии места под хранение строк. В статье приведены расчёты и команды для самостоятельного повторения. Примеры полезны, чтобы понять, как в блоках хранятся строки с пустыми значениями. Для практического применения в конце статьи приведены результаты
На одной из конференций 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/
Ильф и Петров оживили Остапа, и по их примеру, оказавшись в определенной точке своей жизни, я решил написать продолжение своих заметок. Спойлер для тех кому лень читать дальше - у меня нет яхты, я ищу работу на заводе, и если повезет, то это будет завод по выращиванию медицинского каннабиса.
В этой статье не будет технических решений или алгоритмов, я хочу рассказать о своем опыте, который приобрел с момента опубликования предыдущего текста и перемещения меня в другую жизнь.
Занимаемся не только разработкой, но и помогаем освоиться в мире 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 приходит на помощь. Плюс ко всему: нет необходимости создавать отдельные сервисы для анализа, что уменьшает задержки и упрощает архитектуру приложения.
