Быстрый старт в маскировании данных с pg_anon

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

Чтобы избежать финансовых и репутационных рисков, в работе с БД обязательно нужны гибкие инструменты обезличивания. Один из них — разработанный нами opensource-инструмент pg_anon. Он маскирует конфиденциальные данные, помогая соблюдать закон, защищая информацию и сохраняя её пригодность для анализа.

В новой статье в нашем блоге на Habr:

➡️ Разберем разработанный нами бесплатный инструмент от установки до использования
➡️ Создадим словарь анонимизации
➡️ Снимем дамп с маскированием и проверим результат!


↗️Читать статью

#Tantor #TantorPostgres #1C #Anonimization #Habr #Tantor1C

Вечер пятницы. Время отвлечься от работы и… почитать про PostgreSQL.

Наша новая статья на HABR посвящена внутристраничной очистке для индексов. Если вы DBA или разработчик и хотите лучше разбираться в тонкостях работы Tantor Postgres и других СУБД на базе PostgreSQL на низком уровне, понимать возможные причины замедлений, – эта статья для вас.

Что исследуем:
➡️ Принцип работы: Как PostgreSQL удаляет устаревшие версии строк (MVCC) из индексных страниц для эффективного повторного использования пространства
➡️ Ключевое ограничение: Очистка возможна только для версий, вышедших за горизонт базы данных (xmin horizon)
➡️Проблема удержания горизонта: Что происходит, если в системе есть долгая транзакция или запрос? Как это блокирует очистку как внутристраничную, так и VACUUM
➡️ Последствия для производительности: На реальном примере pgbench показываем, как удержание горизонта транзакцией или запросом приводит к тому, что новые версии строк вынуждены размещаться в новых блоках индекса, и это сильно снижает производительность поиска по индексу актуальной версии строки (процесс вынужден просматривать все версии строк).

↗️Читать статью

#Tantor #TantorPostgres #Habr

Когда pg_stat_statements замедляет вашу БД? Разбираем сэмплирование!

Сбор статистики SQL-запросов (количество запусков, общее и среднее время их выполнения, число возвращённых строк и др.) позволяет анализировать их поведение во времени, выявлять проблемные участки и принимать обоснованные решения по оптимизации. Но знаете ли вы, что расширение pg_stat_statements, которое помогает собирать такую статистику, само может стать узким местом и вызывать просадки производительности?

К выпуску СУБД Tantor Postgres 17.5.0 мы запускаем серию публикаций в нашем корпоративном блоге на Habr о наиболее интересных новинках релиза. В сегодняшней статье на практических примерах разбираем:

➡️ В каких сценариях расширение pg_stat_statements становится источником проблем
➡️ Как устроено сэмплирование и в каких случаях его применение позволяет снизить «накладные расходы»
➡️ Как сэмплирование реализовано в СУБД Tantor Postgres 17.5.0

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

↗️Читайте статью

#Tantor #TantorPostgres #Habr

Настройка OAuth-авторизации в Tantor Postgres 17.5 и PostgreSQL 18: практическое руководство на примере Keycloak

Мы продолжаем цикл статей, в которых описываем нововведения СУБД Tantor Postgres 17.5.0. В прошлый раз мы писали об оптимизации нагрузки на систему за счет сэмплирования сбора статистики с pg_stat_statements. Сегодня хотим спросить — знаете ли вы, что Tantor Postgres 17.5.0 поддерживает авторизацию по OAuth 2.0 Device Authorization Flow (эта же возможность ожидается в PostgreSQL 18)? Это позволяет отказаться от паролей на клиенте и централизовать управление доступом через провайдеров.

В новой статье в нашем блоге на Habr — детальное руководство по реализации авторизации OAuth 2.0 на примере Keycloak:
➡️Настройка Keycloak как провайдера идентификации (Realm, Users, Client scopes, Clients)
➡️Подготовка PostgreSQL (настройка pg_hba.conf, pg_ident.conf, параметра oauth_validator_libraries)
➡️Реализация валидатора токенов на C с обработкой JWT и проверкой scope
➡️Процесс авторизации через psql с использованием Device Flow

Материал предназначен для широкого круга разработчиков, в частности, администраторов БД и ИБ-инженеров, внедряющих современные механизмы аутентификации.

↗️Читать статью

#Tantor #TantorPostgres #PostgreSQL #OAuth #Habr

Как создаются патчи для PostgreSQL?

Разработчикам, расширяющим функционал PostgreSQL, иногда требуется добавлять в существующие команды новые параметры. Однако порядок модификации исходного кода — подчас непростая задача:
➡️Где взять списки файлов, в которые нужно вносить изменения?
➡️В какие места в этих файлах их вносить?
➡️Какой, собственно, вносить код?
➡️Как повысить шансы на принятие патча сообществом?

В новой статье «Пример создания патча для PostgreSQL» в корпоративном блоге Tantor на Habr детально разбирается процесс такого рода доработки на примере добавления нового колоночного атрибута в системный каталог, с возможностью установки значения через команду ALTER TABLE.

Статья написана по реальному кейсу, описанному одним из наших разработчиков в докладе на конференции PG BootCamp 2025 в Екатеринбурге, и может служить своего рода руководством.

↗️Читать статью

#Tantor #TantorPostgres #Habr

pg_dphyp: учим PostgreSQL соединять таблицы по другому

Планировщик PostgreSQL предлагает оптимальный способ соединения таблиц, опираясь на алгоритмы DPsize (динамическое программирование) и GEQO (генетическая эвристика). Мы задались вопросом: а что если взять алгоритм DPhyp, основанный на гиперграфах и реализованный в некоторых других СУБД, и «вшить» его в PostgreSQL без правок ядра?

В нашей новой статье на Habr – подробный R&D-отчёт о прототипировании расширения pg_dphyp, реализующего этот алгоритм. В центре попытки его создать — задача реализации преимуществ гиперграфного подхода без изменения существующей инфраструктуры планировщика. В результате в одном из тестов удалось ускорить планирование конкретного сложного JOIN-запроса в 600 раз.

Кейс показал, что DPhyp способен не просто разнообразить арсенал PostgreSQL, но в отдельных сценариях прирастить производительность. Недостатки у алгоритма есть, но значит, есть и пространство для будущих размышлений и исследований!

↗️Читайте статью в нашем блоге на Habr

#Tantor #Habr

Механизм работы временных таблиц PostgreSQL и его влияние на таблицы системного каталога

При создании и удалении временных таблиц в PostgreSQL изменяются до 13 таблиц системного каталога, при этом особенно сильно разрастаются pg_attribute, pg_class и pg_depend. Массовое создание и усечение временных таблиц активно применяется в том числе в 1C:ERP.

В нашей новой статье в блоге на Habr — разбор механизмов и особенностей работы с временными таблицами: мониторинг роста, работа автовакуума, замеры падения производительности и нагрузок на буферный кэш. Особое внимание уделено решению этой проблемы в СУБД Tantor Postgres 17.5: параметр enable_temp_memory_catalog переносит метаданные временных таблиц в память процесса, исключая изменения в системных таблицах. Результаты тестов показывают стабильную работу без падения производительности.

↗️Читать статью

#Habr #TantorPostgres #Производительность #Tantor1C

Почему PostgreSQL иногда делает «неправильный» выбор индекса — и как это исправить?

Бывает так, что после миграции «1С» на Postgres часть запросов внезапно начинает работать в разы медленнее из-за того, что когда есть несколько индексов с одинаковыми ведущими столбцами, планировщик выбирает не самый подходящий. Типичная ситуация: есть «широкий» индекс, покрывающий все условия запроса, и «узкий», обслуживающий другие запросы, и планировщик выбирает узкий, потому что его стоимость представляется более низкой. Это приводит к избыточному чтению данных и многократному увеличению времени выполнения.

В свежей статье на Хабре подробно разбираем, как PostgreSQL оценивает стоимость индексного доступа, в каких формулах кроется подвох, почему селективность может быть «запредельной». Показываем, как можно использовать расширенную статистику и что даёт наш патч, который исправляет выбор индекса в Tantor Postgres 17.5.

Если вам интересна работа планировщика и технические детали работы индексов — читайте статью. Она поможет понять, почему "всё медленно", когда всё вроде бы правильно.

↗️Читать статью

#TantorPostgres #PostgreSQL #1C #Производительность #Habr

На Хабре вышла наша новая статья — настоящая ретроспектива длиной в восемь лет. Рассказываем историю патча с 64-битным счётчиком транзакций: всё началось ещё в 2017 году, и с тех пор он прошёл через десятки версий. Показываем, как менялся подход к реализации, какие проблемы возникали при переносе между версиями и почему сообщество до сих пор не приняло патч, несмотря его на важность для высоконагруженных систем.

Вы узнаете:
➡️Чем опасен wraparound — циклическое переполнение 32-битного счетчика;
➡️Почему штатного механизма заморозки (freeze) для высоконагруженных систем бывает недостаточно;
➡️Почему даже сегодня патч остаётся коммерческой технологией;
➡️Как именно реализуют 64-битный счетчик.

В общем, история — про настойчивость, collaboration и вызовы, которые принимает open-source сообщество. Приглашаем к чтению и обсуждению всех, кому интересна глубокая разработка СУБД и будущее PostgreSQL!

↗️Читать статью

#TantorPostgres #PostgreSQL #Habr

Мониторинг и администрирование PostgreSQL в масштабе — непростая задача. Как строить работу, когда инстансов много, а использование ручных проверок и фрагментированных решений начинает доставлять неудобства? В свежей статье на Хабре разбираем три класса решений:

➡️Классические системы на базе Prometheus + Grafana. Подходят большинству команд: гибкость, кастомизация, но скудный функционал без предиктивной аналитики и средств управления, а оценивать состояние можно только глубоко разбираясь в самих системах.

➡️Специализированные решения open source для PostgreSQL. Готовые метрики и дашборды «из коробки», упрощённая интеграция. Хорошо подходят для малых и средних инсталляций, но отсутствует масса функций, необходимых крупным компаниям.

➡️Коммерческие продукты enterprise-уровня. Поддержка большого числа инстансов, развитая аналитика и алертинг, централизация мониторинга, аналитики запросов и управления, предиктивная аналитика и автоматизация, роли и мультитенантность.

В статье — подробный разбор: архитектуры, схемы, плюсы и минусы, а также рекомендации по выбору подхода.

↗️Читать статью

#Tantor #ПлатформаTantor #Habr

При логировании соединений с БД системы мониторинга создают сессии для сбора метрик и проверки его доступности. Это генерит большое количество записей в диагностическом журнале, что затрудняет его анализ. Приходится либо отключать логирование, либо…
 
В новой статье на Хабре рассматриваются использование параметра log_disconnections, который обеспечивает отключение логирования, а также расширений pgaudit и pgaudittofile, которые входят в СУБД Tantor Postgres и позволяют выводить логирование соединений в отдельный файл аудита, минуя диагностический лог PostgreSQL.


↗️Читать статью

#Tantor #TantorPostgres #Habr

Временные данные в PostgreSQL: искусство правильного хранения

Кэш сессии, промежуточные результаты расчётов, данные для ETL — эти «временные гости» должны покидать базу сразу после выполнения своей задачи. Но где их размещать на время работы? Ошибочный выбор способа ведёт к излишней нагрузке на WAL или накоплению мусора.

В нашей новой статье на Habr — обзор пяти способов хранения временных данных, сравнение их функциональности и производительности:
➡️ Обычные таблицы;
➡️ Нежурналируемые таблицы;
➡️ Материализованные преставления;
➡️ Временные таблицы;
➡️ Память серверного процесса (с расширением pg_variables).

↗️Читать статью

#Tantor #TantorPostgres #Habr

В семейство СУБД Tantor Postgres входит специализированная редакция Special Edition 1C, адаптированная под работу с бизнес-приложениями на основе продуктов фирмы «1С».

↗️В новой статье на Хабр публикуем подробный обзор всех новинок нового релиза для 1С-систем.

#TantorPostgres #1C #Habr

Блог Tantor на Habr: наша коллекция знаний по Tantor и PostgreSQL для вас 🐘

Друзья, наш блог на Хабре появился полгода назад, и за это время мы опубликовали целую библиотеку материалов. Мы не только пишем код и рассказываем о новинках, но и делимся тем новым, что изучаем и узнаем. Собрали для вас все статьи в тематические подборки:

🧑‍💻 Решение конкретных задач для администраторов БД и DevOps-инженеров

▪️Как мониторить сотни инстансов PostgreSQL и не сойти с ума
▪️Настройка OAuth-авторизации в СУБД Tantor Postgres
▪️Быстрый старт в маскировании данных с pg_anon
▪️Как провести нагрузочное тестирование БД PostgreSQL и ничего не забыть
▪️Кластер Patroni в Docker-контейнерах
▪️Трассировка запросов в Postgres с расширением pg_trace
▪️Логирование (аудит) сессий в PostgreSQL

Тонкости оптимизации для разработчиков и архитекторов БД

▪️Выбор индекса при соединении по нескольким столбцам
▪️Когда может быть полезно семплирование в pg_stat_statements
▪️Работа с временными таблицами в PostgreSQL
▪️Работа с длинными строками в PostgreSQL
▪️Хранение временных данных в PostgreSQL

Экспертный уровень и R&D

▪️Сравнение транзакционных систем Oracle и PostgreSQL (перевод)
▪️wpg_dphyp: учим PostgreSQL соединять таблицы по-другому
▪️Пример создания патча для PostgreSQL
▪️Внутристраничная очистка в индексах PostgreSQL
▪️64-битный счетчик транзакций в PostgreSQL

Для специалистов по 1С

▪️Обзор улучшений для 1С в СУБД Tantor Special Edition 1C 17.6
▪️Обзор улучшений для 1С в СУБД Tantor Special Edition 1C 17.5

Какие темы хотите обсудить в следующих статьях вы? Просто дайте нам знать через ↗️ форму на сайте.

#TantorPostgres #Habr #1С