Все потоки
Поиск
Написать публикацию
Обновить
108.88

PostgreSQL *

Свободная объектно-реляционная СУБД

Сначала показывать
Порог рейтинга

19 сентября — СУБД-митап Tantor JAM

Митап от разработчика СУБД Tantor Postgres и машин баз данных Tantor XData пройдет в Москве. Это отличный повод встретиться для всех, кто интересуется развитием российских СУБД и будущим сферы управления корпоративными данными.

Зарегистрироваться

В программе мероприятия:

  • Стратегия «Тантор Лабс» на 3 года;

  • Новая версия платформы Tantor — ведущего enterprise-решения для администрирования и мониторинга любых БД на основе PostgreSQL;

  • Новинки СУБД Tantor Postgres для более высокой производительности и защищённости данных;

  • Инструментарий для управления интеграциями и загрузкой данных, осуществления миграций с минимумом даунтайма;

  • Особое внимание будет уделено Tantor XData — первой российской машине баз данных от вендора СУБД, созданной для самых сложных промышленных задач, высоконагруженных защищённых систем и крупномасштабной аналитики в стратегически важных отраслях.

Митап пройдет 19 сентября 2025 г. на 40-м этаже башни Mercury Space по адресу: Москва, 1-й Красногвардейский проезд, 15. Регистрация участников стартует в 12.00.

Участие бесплатное, требуется предварительная регистрация.

Будем рады видеть вас и ваших коллег!

Теги:
+2
Комментарии0

Вебинар «Low-code разработка на PostgreSQL с XSQUARE»

16 сентября в 17:00 мы проведем вебинар о том, как упростить и ускорить разработку приложений с помощью low-code платформы XSQUARE и PostgreSQL.

Что будет

🔹 Создание приложения за 5 минут.
🔹 Онлайн-таблицы (Google Sheets/Excel) на базе PostgreSQL.
🔹 Превращение PostgreSQL в REST API.
🔹 Импортозамещение Oracle Apex, Forms, MS SQL.

Вебинар будет полезен разработчикам, администраторам и аналитикам.
Участие бесплатное, нужна только регистрация.

🎙 Спикеры

Константин Ващенков (CTO XSQUARE)
Станислав Погоржельский (технологический евангелист VK Cloud)

➜ Зарегистрироваться

Теги:
0
Комментарии0

Как мы выиграли ProcessTech 2025 с проектом TechSupport 360

В начале сентября Блок ИТ Страхового Дома ВСК, получил награду «Лучший пилотный проект» на премии ProcessTech 2025.
Наш проект TechSupport 360 занял первое место в номинации — и мы хотим поделиться, как всего за 4,5 месяца удалось пройти путь от гипотез до результата, который оценили бизнес-заказчики, ИТ-команды и жюри конкурса.

С чего всё началось
В начале 2025 года мы поставили себе задачу: проверить, как технологии Process Mining и BI-аналитики могут изменить работу ИТ-поддержки и эксплуатации.
Так родился пилотный проект TechSupport 360.

Мы сформулировали три гипотезы:

Process Mining для SLA

  • Оцифровать карты ИТ-процессов (каталог — 1432 услуги).

  • Найти избыточные нормативы SLA.

  • Сократить время решения без потери качества.

  • Перезаключить SLA с бизнес-подразделениями на новых условиях.

BI-аналитика метрик

  • Автоматизировать подготовку отчетности по ИТ-поддержке и инфраструктуре.

  • Снять нагрузку с аналитиков.

  • Построить дашборды Proceset, позволяющие искать причины отклонений по принципу «от общего к частному».

Автоматизация KPI

  • Оцифровать и перевести в BI-формат 52 ключевых KPI Центра эксплуатации ИТ.

Как мы это делали
Пилот длился всего четыре с половиной месяца — с января по май 2025 года. За это время удалось пройти полный цикл: от выработки гипотез и технических интеграций до демонстрации результатов топ-менеджменту и бизнес-заказчикам.
В январе команда определила ключевые направления для проверки и закрепила три гипотезы: управление инцидентами, BI-аналитика ИТ-процессов и автоматизация KPI. Параллельно аналитики прошли самообучение работе с инструментами Proceset и настроили интеграции с системами — Jira Service Desk, Zabbix, vROps и внутренними утилитами.
В феврале мы собрали и подготовили массивы данных, разработали техническое задание и методологию для проверки гипотез. Именно на этом этапе началась активная работа с SQL и REST API для подготовки расчетов и моделей.
Март стал переломным месяцем: появились первые результаты по всем трем гипотезам. Карты процессов были построены и согласованы с владельцами, первые BI-дашборды прошли апробацию на рабочих группах, а KPI начали отображаться в автоматическом режиме.
В апреле мы вынесли итоги пилота на обсуждение с бизнес-заказчиками и топ-менеджментом: Proceset показал свою эффективность, а команды получили прозрачный инструмент для поиска узких мест и принятия решений.
Финальной точкой стал май: мы запустили переподписание SLA-соглашений с бизнес-блоками, включили результаты работы в PI-планирование по SAFe и подготовились к выступлению на ProcessTech.

Что получилось

Гипотеза 1. SLA и инциденты

  • Построены карты 1432 процессов.

  • Оптимизированы нормативы SLA в 356 процессах (дельта: от 12 до 2 часов).

  • 100% SLA-соглашений переподписаны с бизнес-блоками.

  • В Proceset разработан калькулятор прогнозных SLA для управления ожиданиями.

Гипотеза 2. BI-аналитика

  • Автоматизированы 105 метрик (75 по ИТ-поддержке, 30 по инфраструктуре).

  • Разработан 21 BI-дашборд.

  • Высвобождено 2048 чел.-часов в год (подготовка отчетности).

  • В 7 раз ускорено получение данных (с раз в неделю до ежедневного).

  • Review-сессии и рабочие группы теперь проходят без PowerPoint и Excel — сразу в BI.

Гипотеза 3. KPI

  • Автоматизированы 52 KPI Центра эксплуатации ИТ.

  • Высвобождено 315 чел.-часов в год на подготовку.

Почему проект оказался «лучшим пилотом»
Пилот показал, что можно изменить мышление внутри ИТ-команд. Если раньше аналитика процессов велась преимущественно в Excel, то теперь Proceset стал целевым инструментом для review-сессий и планерок. Это не только ускорило работу, но и дало общий язык для обсуждения метрик и показателей. В совокупности эти факторы и сделали TechSupport 360 «лучшим пилотом»!

Для нас эта награда — не финиш, а подтверждение того, что цифровая аналитика ИТ-процессов — рабочий инструмент, который помогает делать сервис для бизнеса быстрее, прозрачнее и удобнее.

Теги:
+1
Комментарии0

Лутаем Open Source #24. Они наконец-то починили MongoDB! Перенеся его на PostgreSQL...

DocumentDB – БД от Microsoft, которая состоит из 3-х частей:

  1. PG расширение, добавляющее BSON формат (написанный, на С)

  2. CRUD API поверх него (С)

  3. Сервис трансляции Mongo Query в SQL (Rust)

Для кого это?

И вроде как: "PG – классная база, а MongoDB Query + BSON популярные технологии" – и можно было бы поразмышлять чем это круто, но сначала важно ответить на один туманный вопрос: "кому такая БД может быть нужна?"

Классический PG

Сначала рассмотрим кейс, когда мы накладываем DocumentDB на обычный PostgreSQL.

Те, кто используют MongoDB если попробуют переехать на такой сэтап столкутся с тем, что:

  • Там нет шардинга (и насколько бы он не был сложно реализован в MongoDB, он есть и им активно пользуются)

  • Придется использовать двойной тулинг: Compas, чтобы наблюдать за корректностью данных с MongoDB Query, и SQL если надо посмотреть что там внутри

  • MongoDB поддерживает Uncommitted Read и Write Majority, что странно накладывается на PG: если разраб достаточно продвинутый и намеренно использовал Uncommitted, то с PG он потеряет скорость и Availability из-за PG Committed, а если он использовал Write Majority, то PG не совсем дает такую гарантию (обвал диска при WAL репликации – менее надежен, чем Write Majority)

  • А самое главное: когда ты работаешь с MongoDB ты можешь открывать 1000 коннекшенов и он вполне себе все это сожрет, потому что (1) коннекшен это тред, (2) при запросах нет никакой проверки реляционной целостности, да и в целом проверка сильно проще, чем в PG, а значит придется потанцевать с пуллерами и даже менять где-то запросы, чтобы не упасть по скорости

То есть, у mongo-юзеров это заберет все особенные фичи MongoDB и при этом не даст фишки PostgreSQL.

Distributed PG-like

А что, если мы положим DocumentDB на что-нибудь из серии CockroachDB, YugabyteDB, AWS Aurora, Citus или Neon?

Все 3 проблемы решаются:

  • Шардинг из коробки

  • Достаточно высокая скорость записи и чтения

  • Отсутствие проблем с коннектами

В такой ситуации DocumentDB начинает играть новыми красками.

Но если в Neon и Citus (и может YugabyteDB) еще есть шанс добавить текущий DocumentDB BSON плагин, то в для других представителей придется писать его с нуля (причем под каждый свой, потому что они построены каждый на своем KV хранилище).

Переезд в Linux Foundation

А еще они сейчас в процессе переезда из Microsoft в Linux Foundation, из плюсов они будут полностью под MIT лицензией и пейвола, за который будут прятать полезные фичи, из минусов, Microsoft могут и забросить, а никто другой не подхватить.

Итоги

Неоднозначная технология, пока имеет смысл в каких-то тонких кейсах, но в общем и целом, не вижу пока где тут middle-ground, может, вы что-то подскажете?

P.S.

А еще приглашаю вас к обсуждению в свой паблик в телеграмме 🦾 IT-Качалка Давида Шекунца 💪

Теги:
+4
Комментарии2

Нагрузочное тестирование GP6 vs GP7 vs Cloudberry

Насколько лучше производительность в GP7 и Cloudberry относительно GP6? Насколько стабильно работают GP7 и Cloudberry? Стоит ли мигрировать с GP6 в 2025? И если да, то на что? Ответы на эти вопросы — в партнерском материале по нагрузочному тестированию GreenPlum 6.X, GreenPlum 7.X и Cloudberry ведущего архитектора группы компаний GlowByte Марка Лебедева.

Материал был анонсирован в статье «Тестирование систем и движков массивно-параллельных вычислений. Часть II. TPC-DS» и продолжает серию публикаций о нагрузочных тестированиях технического руководителя решений Data Ocean Nova и Data Ocean Flex Loader Евгения Вилкова.

Теги:
Рейтинг0
Комментарии0

Расширению PostgreSQL Hacker Helper исполнился год.

Это расширение VS Code для разработки исходного кода PostgreSQL. Почти год назад я сделал пост о его создании, а буквально пару дней назад (9 августа) наступил год со дня релиза 1.0.0 версии.

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

Самый яркий пример - это List , динамический массив. Что в нем такого особенного? Во-первых, структура данных одна, но внутри себя он хранит (либо-либо) указатель/int/TransactionId/Oid. Во-вторых, его реализация зависит от версии - раньше он был реализован как связный список, а сегодня - это массив.

Еще один занятный пример - Value. Сегодня этой структуры нет, так как она разбилась на отдельные String, Integer, Float, Boolean и BitString (src/include/nodes/value.h). Это также нарушает изначально красивую картину, так как приходится добавлять логику - название структуры не соответствует типу хранимого узла.

За этот год я добавил множество фичей:

  • Рендеринг выражений (переменные, представляющие выражения отображаются выражением, которое они представляют)

  • Отображение содержимого хэш-таблиц

  • Указатели на отношения из переменных типа Relids

  • Форматирование файла с помощью pgindent

  • Бутстраппинг новых расширений (создание шаблонных файлов)

  • Дамп представления узлов в лог или отдельный текстовый файл (через pprint/nodeToString)

Если же говорить о нефункциональных особенностях:

  • Большая расширяемость за счет файла конфигурации

  • Поддержка нескольких расширений отладчиков

  • Тестирование и CI-пайплайн для этого

Больше всего мне запомнилось добавление поддержки отладчика CodeLLDB. Этим я занимался 5 дней с утра до ночи. В то же время и добавил тестирование.

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

Глядя на все это осознаю, что теперь это можно назвать целой IDE для PostgreSQL. Хотя и кажется, что все что можно было написать уже сделано, но постоянно нахожу новые возможности для его развития.

Ссылки: репозиторий и расширение.

P.S. За это время у меня накопилось множество историй о том, как я это расширение писал и с какими проблемами столкнулся. Если интересно почитать об этом - дайте знать!

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Взгляд на BI дашборды PROCESET сквозь призму повседневных задач.

Автор: Алексей Терехин, Центр эксплуатации ИТ, Руководитель направления автоматизации ИТ-процессов, Страховой Дом ВСК

Когда на утренней планёрке перед глазами появляется картинка с ключевыми метриками — понимаешь, как далеко ушла ручная работа с отчётами. BI дашборды PROCESET в нашем Центре эксплуатации ИТ помогают увидеть главные цифры одним взглядом, а ещё — сэкономить время и силы команды. Расскажу, как это работает простыми словами.

Почему дашборд лучше связки Excel-Power Point

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

К тому же, дашборд позволяет пользователям взаимодействовать с данными в реальном времени, фильтровать и настраивать представление информации по своему усмотрению прямо во время планерки.

Нельзя забывать о возможности дашборда собирать данные “всех мастей” в одном месте: таблицы из базы, CSV файлы и даже ответы от внешнего API — всё конвейером попадает в один экран.

Дополнительным преимуществом является способность анализа больших объемов данных: BI-дашборды PROCESET способны на это, в то время как excel будет испытывать трудности с производительностью.

Если вы ещё не читали, как мы внедряли процессную аналитику загляните в нашу статью.

Как мы это сделали (без сложных терминов)

  1. Собираем данные // Представьте, что ETL — это робот курьер. Он каждый час ездит за нужными таблицами, файлами и ответами от сервисов и привозит их в хранилище.

  2. Готовим и сглаживаем // Робот перебирает свежие цифры, превращает разрозненные форматы в единый вид (например, переводит все даты к одному стилю) и отбрасывает лишнее.

  3. Создаем визуализацию // Каждый дашборд выстраивается по 4-м уровням: панель управления дашбордом; карточки с ключевыми метриками; графики с динамикой метрик по периодам и графики с дополнительной детализацией или группировкой метрик.

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

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

Что вы получите в итоге

  • Экономия времени: вместо нескольких часов на подготовку отчётов — пару кликов и готово.

  • Прозрачность: все видят одни и те же цифры, нет разночтений «кто/что/куда внёс».

  • Быстрый анализ: от «почему упал KPI» до «где утечка заявок» — без прыжков между Excel и презентацией.

Пару советов для старта

1. Выберите одну ключевую задачу — например, автоматизацию утреннего отчёта по инцидентам.

2. Настройте расписание — пусть "робот курьер" привозит данные раз в час.

3. Повесьте дашборд на монитор — и посмотрите, как команда сама начинает держать цифры под контролем.

И помните: чтобы узнать, как мы шаг за шагом внедряли эту систему и связали её с процессной аналитикой, обязательно загляните в нашу статью «Синергия Process Mining и BI: как Страховой Дом ВСК строит эко-систему процессной аналитики Proceset в ИТ».

Буду рад вашим вопросам и историям внедрения — пишите в комментариях!

Теги:
Всего голосов 6: ↑5 и ↓1+6
Комментарии1

Выпущена новая версия СУБД Picodata — Picodata 25.3 

Компания Picodata (входит в Группу Arenadata) выпустила новую версию СУБД Picodata — Picodata 25.3. Обновление включает расширенные возможности SQL, механизм автоматического обновления схемы данных, а также повышение стабильности кластера.

Улучшение обратной совместимости

В Picodata 25.3 реализовано автоматическое обновление схемы данных при переходе инстансов на новый релиз Picodata. Этот механизм учитывает сделанные изменения в системных таблицах и сохраняет обратную совместимость при обновлении на следующий релиз СУБД: при переводе кластера на новую версию Picodata необходимые DDL/DML-команды выполнятся без вмешательства администратора, а требуемые в новой схеме внутренние функции также будут созданы автоматически.

Новые возможности SQL

В релиз добавлены новые возможности языка SQL в Picodata, в частности:

  • поддержка NULLS FIRST/LAST при сортировке результатов запроса (ORDER BY);

  • обработка конфликтов при вставке данных в глобальные таблицы (INSERT INTOON CONFLICT DO FAIL/REPLACE/NOTHING);

  • новая встроенная оконная функция LAST_VALUE();

  • оператор % для определения остатка деления по модулю для целых чисел;

  • возможность определения лидера raft-группы через функции pico_raft_leader_id() и pico_raft_leader_uuid();

  • возможность определения версии текущего инстанса с помощью функции version();

  • изменение, связанное с совместимостью: вместо скалярной функции instance_uuid (которая теперь объявлена устаревшей), рекомендуется использовать новую функцию pico_instance_uuid.

Улучшенная совместимость с PostgreSQL

Picodata теперь поддерживает безопасное соединение при обращении к внешнему LDAP-серверу. При подключении через протокол PostgreSQL (например, с помощью клиента psql) с методом аутентификации LDAP можно задействовать TLS-шифрование (при условии, что оно включено на LDAP-сервере). На стороне Picodata для этого потребуется установить значения у трёх переменных окружения. Например:

export TT_LDAP_URL="ldap://127.0.0.1:1389"
export TT_LDAP_DN_FMT='cn=$USER,ou=users,dc=example,dc=org'
export TT_LDAP_ENABLE_TLS=true

Изменение в конфигурации

Добавлен новый параметр instance.pg.advertise — публичный адрес сервера для подключения по протоколу PostgreSQL. По умолчанию, его значение соответствует значению instance.pg.listen. Этот параметр пригодится в ситуации, когда снаружи инстанс доступен по адресу, отличающемуся от адреса во внутренней сети.

Улучшенный веб-интерфейс

Команда Picodata продолжает развивать компонент webui для Picodata. В версии Picodata 25.3 веб-интерфейс не просто выглядит лучше, он также стал удобнее и информативнее:

  • на панели Cluster ID отображается больше полезной информации, включая список включённых плагинов;

  • в области просмотра сведений об инстансе теперь присутствует адрес подключения по протоколу PostgreSQL.

Механизм плагинов

При подключении плагина к кластеру Picodata теперь допускается расхождение минорных версий плагина и инстанса (например, плагин, собранный для версии 25.3.1, будет работать в Picodata 25.3.2).

Полный список нововведений и список исправленных ошибок доступны в документе CHANGELOG.

Роль Picodata для Ansible

Выпущена новая версия роли Picodata для Ansible, которая совместима с Picodata 25.3. Изменения в роли:

  • при сборке информации при сбое (тег crash_dump) можно исключить сборку snap- и xlog-файлов;

  • добавлена возможность выполнять lua-команды на инстансах кластера (тег command);

  • исправлена работа с несколькими плагинами в инвентаризационном файле и ряд прочих ошибок.

Для установки Picodata 25.3 следуйте инструкциям на сайте. Готовые пакеты доступны для следующих дистрибутивов Linux:

  • Astra 1.8

  • Debian 12 (bookworm)

  • RHEL/Rocky 9

  • Fedora 41–42

Инструкции и руководства по установке, использованию и администрированию Picodata размещены на портале документации Picodata.

Теги:
Всего голосов 4: ↑2 и ↓20
Комментарии0

Обновили кейс с Гринатом — и не просто освежили текст, а напомнили себе, насколько масштабный и значимый это проект.

Разработка Платформы доверенных сервисов (ПДС) продолжается, и вместе с АО «Гринатом» мы последовательно развиваем систему, которая стала цифровым фундаментом юридически значимого документооборота в атомной отрасли.

В рамках проекта мы реализовали:
— выпуск и учёт всех типов электронных подписей (УКЭП и УНЭП);
— автоматизированную систему управления сертификатами и СКЗИ;
— интеграцию с кадровыми базами, ЕСИА и СМЭВ;
— удобные API для других ИТ-систем;
— масштабирование до 100 000+ пользователей.

Впереди — новые этапы развития: интеграция с ЕБС и другими сервисами. Мы продолжаем делать ПДС удобным, масштабируемым и устойчивым решением для всей отрасли.

Прочитайте обновлённый кейс на сайте и посмотрите, как именно мы решаем нетривиальные задачи в высокорегулируемой среде.

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

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

В Облаке Рег.ру повысили лимит на количество баз данных — в 100 раз

В Облачной платформе Рег.ру обновили лимит на количество баз данных в кластерах DBaaS: теперь пользователи могут добавлять до 1000 баз. Расширили возможности системы в 100 раз для повышения гибкости и масштабируемости проектов пользователей. 

Мы часто получаем запросы на развитие платформы, и этот релиз — результат обратной связи от наших клиентов. Спасибо вам!

Напомним, что в облаке Рег.ру доступно два вида управляемых БД — PostgreSQL и MySQL. Добавить новые базы данных в существующем кластере можно в личном кабинете, а узнать подробнее про возможности DBaaS — здесь.

Теги:
Всего голосов 3: ↑3 и ↓0+3
Комментарии0

GIN индексы в PostgreSQL

Сегодня хочу рассказать о GIN индексах в PostgreSQL. Это один из мощных инструментов, которые есть в БД PostgreSQL. Но почему-то очень многие незаслуженно обходят его стороной.

Что такое GIN индекс

GIN (Generalized Inverted Index) – это инвертированный индекс, который предназначен для ускорения поиска в структурах данных, содержащих составные типы. Он имеет встроенную оптимизацию, позволяющую искать по элементам внутри сложных структур. По своей сути, это обратный индекс, где для каждого уникального элемента хранится список указателей на записи, в которых он встречается. Это дает возможность быстро находить записи, соответствующие запросу.

Для каких типов данных используется GIN индексы

GIN-индексы особенно эффективны для следующих типов данных:

  • Массивы

    • Хранение списков значений

    • Быстрый поиск по элементам массива

    • Пример: теги, категории, списки ID

  • JSONB

    • Хранение полуструктурированных данных

    • Быстрый поиск по ключам и значениям

    • Поддержка сложных запросов к JSON-документам

  • Полнотекстовый поиск

    • Индексация текстовых полей

    • Быстрый поиск по словам и фразам

    • Поддержка различных языков

Преимущества GIN индексов

  • Эффективность поиска по структурам данных: Хорошо подходит для обработки массивов и структурированных данных типа JSONB. Позволяет быстро находить нужные строки даже среди миллионов записей. Хранит только уникальные элементы и их местоположение, вследствии этого более экономный по сравнению с полным сканированием.

  • Поддержка различных типов данных: Работает с различными типами - строки, числа, массивы, объекты JSONB и даже геопространственные данные.

  • Подходит для оптимизации полнотекстового поиска: Улучшает производительность запросов с использованием операторов @@ и функций вроде to_tsvector() и to_tsquery(). Особенно полезен там, где требуются операции пересечения (&&), включения (@>), проверки существования элементов массива (?, ?&) и другие специфические условия.

Недостатки GIN индексов

  • Обновление: Каждый раз, когда изменяется запись, содержащая поля, входящих в GIN индекс, индекс обновляется целиком. Это увеличивает нагрузку на систему при частых изменениях данных.

  • Больший размер: GIN индекс занимает больше места на диске по сравнению с традиционными B-tree индексами, так как хранит список всех значений, содержащихся в колонке.

  • Низкая производительность на малых объемах данных: При небольших объемах данных GIN индекс может быть менее эффективным.

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

Заключение

При работе с массивами, JSONB полями и полнотекстовым поиском стоит рассмотреть использование GIN индексов для данных полей. Это позволит повысить эффективность и производительность БД PostgreSQL. Но, в то же время, стоит учитывать особенности его обслуживания и требования к системе. Очень аккуратно применять к часто изменяемым данным.
Очень хорошая статья о GIN индексах https://habr.com/ru/companies/postgrespro/articles/340978/

Более подробно с примерами у меня в телеграмм

Спасибо за внимание!

Теги:
Всего голосов 1: ↑0 и ↓1-1
Комментарии3

Дополняем EXPLAIN Postgres'a информацией об использованной статистике.

Незадолго до код-фриза PostgreSQL 18, Роберт Хаас закомитил возможность, разрешающую внешним модулям добавлять в EXPLAIN дополнительную информацию.

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

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

В список опций EXPLAIN был добавлен параметр STAT, принимающий булевы значения ON/OFF. Если он включён, то в конец эксплейна будет вставляться информация об использованной статистике: наличии MCV, гистограммы, количестве элементов в них. А также значения stadistinct, stanullfrac и stawidth.

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

Можно, но этого не всегда достаточно. Мы знаем алгоритмы, но обычно нам недоступны данные. Поэтому мы не можем с уверенностью определить, какие конкретно статистики есть в pg_statistic по конкретной колонке и что конкретно было доступно бэкенду на момент эстимации.
Посмотрим на пример:

CREATE TABLE sc_a(x integer, y text);
INSERT INTO sc_a(x,y) (
SELECT gs, 'abc' || gs%10 FROM generate_series(1,100) AS gs);
VACUUM ANALYZE sc_a;
LOAD 'pg_index_stats';

EXPLAIN (COSTS OFF, STAT ON)
SELECT * FROM sc_a s1 JOIN sc_a s2 ON true
WHERE s1.x=1 AND s2.y LIKE 'a';

Nested Loop
-> Seq Scan on sc_a s1
Filter: (x = 1)
-> Seq Scan on sc_a s2
Filter: (y ~~ 'a'::text)
Statistics:
"s2.y: 1 times, stats: {

MCV: 10 values, Correlation,
ndistinct: 10.0000, nullfrac: 0.0000, width: 5 }
"s1.x: 1 times, stats: {

Histogram: 0 values, Correlation,
ndistinct: -1.0000, nullfrac: 0.0000, width: 4 }

Здесь можно увидеть, что была использована статистика по колонкам s1.x и s2.y.
При этом, у нас всего десять MCV значений по y, а по х MCV статистика отсутствует вовсе; гистограмма вроде есть, но нулевой длины. И никаких нуллов в обеих колонках.

Таким образом, мы имеем некоторую полезную информацию, которая может подсказать логику выбора плана оптимизатором. Учитывая, что клиент, который не может предоставить данные, крайне редко может предоставить дамп таблицы pg_statistic, то такая достаточно безобидная информация может оказаться полезным подспорьем и вскрыть возможные причины проблем с выбором плана запроса.

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

А какие вы видите варианты применения возможностей расширения вывода эксплейна? Насколько в действительности безобидна даже такая ограниченная информация?

THE END.
12 апреля 2025, аэропорт "Шереметьево"

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

В начале 2024 года, в условиях активного импортозамещения и опасений возможных принудительных мер со стороны властей по переходу на отечественное ПО, мы начали искать альтернативные решения. Основываясь на опыте использования 1С, которое активно применяется в России, и после изучения материалов Гилева, мы решили рассмотреть PostgresPro Ent.

Проведя базовые тесты, нас устроила его функциональность, встроенная кластеризация BiHa PostgresPro Ent и административная панель PPEM. Все выглядело красиво и удобно. В итоге было принято решение закупить лицензии на PostgresPro Ent для двух серверов и развернуть на них часть баз 1С.

Развертывание прошло быстро и без значительных затруднений. Мы создали несколько инстансов для удобства восстановления, так как в отличие от MSSQL, в Postgres нельзя работать с резервными копиями отдельных баз данных без риска потери данных, а только с инстансом целиком.

В процессе эксплуатации выявились некоторые неприятные особенности. В частности, очень долгое резервное копирование с использованием pg_probackup. База 1С на MS SQL, объемом около 100 ГБ, копируется на сервер резервного копирования за 5-10 минут, в то время как аналогичная база на PostgresPro Enterprise требует более 2 часов. Многие могут предложить использовать более мощное оборудование или смотреть в сторону инкрементальных бэкапов (в плане обслуживания MSSQL мы используем как полные таки и инкрементальные). Но проблема заключается в самой логике работы pg_probackup, которая не позволяет сразу архивировать все файлы в один архив и далее работать уже с ними, а фактически учитывая структуру базы 1С там не одна тысяча мелких файлов которые очень "замечательно" копируются по сети, даже 10GBps не изменяет ситуацию. Также возникло множество мелких вопросов, требующих дополнительных компетенций, но пути решения были найдены, хотя и не всегда оптимальные. Вывод: PostgresPro требуется значительного много времени что бы догнать MS SQL в удобстве использования и обслуживания.

Однако главная особенность PostgresPro Enterprise заключается в следующем: при покупке бессрочной лицензии PostgresPro Enterprise, после окончания базовой подписки на техническую поддержку, вы не можете использовать ПО как вам хочется. Вы становитесь привязанными к тому оборудованию, на которое было установлено ПО (вспомним OEM лицензии от MicroSoft), и ваша бессрочная лицензия фактически превращается в лицензию по подписке. Этот факт выяснился через год после покупки, когда мы решили заменить серверы на более новые. Доступ к репозиторию уже был закрыт, так как закончился срок базовой техподдержки. Обращения в техническую поддержку не дали результатов: ответ сводился к предложению купить подписку на техническую поддержку или отказаться от использования ПО.

Таким образом, могу посоветовать: тщательно взвесить все за и против перед переходом на отечественное ПО, чтобы избежать подобных проблем.

p.s. Если у администрации ресурса возникнут сомнения в правдивости этого поста, могу предоставить номера обращений и даже предоставить скрины ответов PostgresPro Enterprise.

upd: Сравнение скорости создания резервных копий на MSSQL и PostgresPro производилось на аналогичных лезвиях в одной и той-же корзине, бэкапы льются в одно и то-же хранилище.

upd2: Покупая MSSQL вы имеете "вечный" доступ к загрузке дистрибутива, обновления в в рамках релиза, обновления безопасности до конца времени поддержки данной версии и так далее, в случае с PostgresPro без наличии активного сертификата на тп вы не имеете ничего.

Теги:
Всего голосов 3: ↑2 и ↓1+1
Комментарии2

Ближайшие события

Расскажем как эффективно работать с большими таблицами в PostgreSQL и упростить задачи администрирования на онлайн-митапе.

25 марта в 11:00 приглашаем на бесплатный онлайн-митап «PGMeetup: Механизмы секционирования больших таблиц». Это вторая встреча из цикла «Работа с данными в Postgres Pro Enterprise», и она посвящена одной из важных тем для любого DBA, работающего с большими объемами данных – секционированию таблиц.

Чем этот вебинар будет полезен именно администратору баз данных?

  • Узнаете, как секционирование позволяет значительно повысить производительность запросов к большим таблицам, разгрузить вашу систему и сделать работу пользователей комфортнее.

  • Поймёте, как секционирование облегчает обслуживание больших таблиц, включая резервное копирование, восстановление и реорганизацию данных. Освободите свое время для более важных задач!

  • Разберётесь в возможностях секционирования Postgres Pro, включая декларативное секционирование и автоматизацию с помощью pgpro_autopart. Повысьте свою квалификацию и добавьте ценный навык в свой арсенал.

  • Получите практические знания о различных вариантах секционирования (hash, range, list), сценариях их применения и ограничениях. Применяйте проверенные решения в своей работе.

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

Митап проведет Владимир Пудовченко, технический консультант Postgres Professional, эксперт с многолетним опытом работы с Postgres Pro. 

Когда: 25 марта в 11:00 (онлайн, участие бесплатное по предварительной регистрации).

Формат: онлайн-трансляция на платформе PGConf (после мероприятия запись будет доступна).

Будет интересно и полезно администраторам баз данных, разработчикам и всем, кто работает с PostgreSQL.

Теги:
Всего голосов 5: ↑5 и ↓0+5
Комментарии0

Обновили курс DBA2 «Администрирование PostgreSQL 16. Настройка и мониторинг»

Компания Postgres Professional выпустила обновление курса DBA2 «Администрирование PostgreSQL 16. Настройка и мониторинг». Переработку и актуализацию материалов выполнили специалисты отдела образования Игорь Гнатюк и Илья Баштанов.

Обновлённая версия курса учитывает возможности, появившиеся в PostgreSQL 14, 15 и 16. Ряд тем был переработан, чтобы лучше отражать современные функции и возможности СУБД.

Этот курс – логичное продолжение DBA1. Если вы уже знакомы с основами PostgreSQL и Unix, то DBA2 – это следующий шаг. Он позволяет получить навыки, необходимые для:

  • тонкой настройки конфигурационных параметров с пониманием внутренней организации сервера;

  • эффективного мониторинга сервера с дальнейшей итеративной настройкой;

  • работы с параметрами, связанными с локализацией, управления расширениями и обновления сервера.

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

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

Курс уже находится в свободном доступе:

https://postgrespro.ru/education/courses/DBA2

Теги:
Всего голосов 6: ↑6 и ↓0+7
Комментарии1

5 утра, чашка кофе, такси, самолёт ...

#PostgresPro #pgproday спасибо за интересный и познавательный день. Новые знакомства, новые знания и новые возможности. Организация мероприятий как всегда на высшем уровне.

До встречи на Pg Conf 2025.

Теги:
Всего голосов 4: ↑3 и ↓1+2
Комментарии0

PGConf.Russia 2025 ждёт доклады

Мы ищем тех, кто горит PostgreSQL так же, как и мы. Если вы администратор баз данных, разработчик, архитектор или DevOps-инженер, и в вашей работе PostgreSQL играет важную роль – нам есть что обсудить.

PGConf.Russia 2025 пройдёт 31 марта – 1 апреля в Центре международной торговли в Москве и онлайн. 

О чём рассказать?

Возможные темы для докладов на PGConf.Russia 2025:  

  • Практический опыт администрирования PostgreSQL, оптимизация производительности и автоматизация задач.

  • Архитектурные решения для обеспечения отказоустойчивости и масштабирования PostgreSQL: резервное копирование, восстановление, кластеризация, шардирование.

  • Инструменты и методики эффективной миграции на PostgreSQL с других СУБД или устаревших версий.

  • Опыт использования новых возможностей и расширений PostgreSQL, их применение и перспективы.

Почему сто́ит выступить?

PGConf.Russia 2025 — это:

  • Большая аудитория. 1 500+ увлечённых профессионалов, готовых учиться, обмениваться опытом и задавать каверзные вопросы. 

  • Признание и уважение. Ваш опыт ценен для сообщества. Выступление на PGConf.Russia – это возможность заявить о себе, повысить профессиональный статус и получить заслуженное признание.

  • Бесплатное участие и размещение. Мы ценим вклад спикеров. Для докладчиков участие в конференции и размещение – за наш счёт.

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

Как подать заявку?

До 23 февраля 2025 года зайдите на сайт PGConf.Russia 2025 и нажмите кнопку «Подать доклад». Заполните название и аннотацию доклада, выберите формат, если нужно, оставьте дополнительный комментарий для программного комитета.

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

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

И ещё раз о внешних ключах

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

Мой тестовый пример (все имена реальных объектов заменены, планы и цифры реальные). Выполняю 3 варианта валидации FK c разными настройками сессии, план исполнения смотрю через расширение pg_query_state.

Исполнение "по умолчанию" выбирается merge join.
ALTER TABLE child_t VALIDATE CONSTRAINT fk_child_parent;

select plan from pg_query_state(1483434);
                                                          plan
------------------------------------------------------------------------------------------------------------------------
 Merge Anti Join (Current loop: actual rows=0, loop number=1)                                                          +
   Merge Cond: (fk.entity_egrn_id = pk.id)                                                                             +
   ->  Index Only Scan using child_t_idx1 on child_t fk (Current loop: actual rows=1, loop number=1)    +
         Index Cond: (entity_egrn_id IS NOT NULL)                                                                      +
         Heap Fetches: 1                                                                                               +
   ->  Index Only Scan using parent_t_pkey on parent_t pk (Current loop: actual rows=113215, loop number=1)+
         Heap Fetches: 113215
(1 row)

SET enable_mergejoin TO false;
ALTER TABLE child_t VALIDATE CONSTRAINT fk_child_parent;

 select plan from pg_query_state(1483434);
                                             plan
-----------------------------------------------------------------------------------------------
 Hash Anti Join (Current loop: actual rows=0, loop number=1)                                  +
   Hash Cond: (fk.entity_egrn_id = pk.id)                                                     +
   ->  Seq Scan on child_t fk (Current loop: actual rows=1, loop number=1)            +
         Filter: (entity_id IS NOT NULL)                                                 +
   ->  Hash (Current loop: actual rows=0, loop number=1)                                      +
         Buckets: 67108864  Batches: 8  Memory Usage: 165802kB                                +
         ->  Seq Scan on parent_t pk (Current loop: actual rows=33979819, loop number=1)

SET enable_hashjoin TO false;
SET enable_mergejoin TO false;
ALTER TABLE child_t VALIDATE CONSTRAINT fk_child_parent;

select plan from pg_query_state(1483434);
                                               plan
---------------------------------------------------------------------------------------------------
 Nested Loop Anti Join (Current loop: actual rows=0, loop number=1)                               +
   ->  Seq Scan on child_t fk (Current loop: actual rows=329042, loop number=1)           +
         Filter: (entity_id IS NOT NULL)                                                     +
   ->  Index Only Scan using parent_t_pkey on parent_t pk (actual rows=1 loops=329041)+
         Index Cond: (id = fk.entity_id)                                                     +
         Heap Fetches: 329041

Почему всё это может быть важно:
1. Вы банально могли что-то делать в своей сессии и манипулировать её состоянием, например, "форсить" вычитку через Nested Loop, а затем запустить построение/валидацию FK на громадных таблицах.
2. По каким-то причинам PG выбрал неподходящий план, и вы знаете, что другой способ будет наверняка лучше :)

Теги:
Всего голосов 3: ↑3 и ↓0+3
Комментарии0

И ещё раз о внешних ключах

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

Представлю мой тестовый пример (все имена реальных объектов заменены, планы и цифры реальные). Выполняю 3 варианта валидации FK c разными настройками сессии, план исполнения смотрю через расширение pg_query_state.

Исполнение по умолчанию выбирается merge join.
ALTER TABLE child_t VALIDATE CONSTRAINT fk_child_parent;

select plan from pg_query_state(1483434);
                                                          plan
------------------------------------------------------------------------------------------------------------------------
 Merge Anti Join (Current loop: actual rows=0, loop number=1)                                                          +
   Merge Cond: (fk.entity_id = pk.id)                                                                             +
   ->  Index Only Scan using child_t_idx1 on child_t fk (Current loop: actual rows=1, loop number=1)    +
         Index Cond: (entity_id IS NOT NULL)                                                                      +
         Heap Fetches: 1                                                                                               +
   ->  Index Only Scan using parent_t_pkey on parent_t pk (Current loop: actual rows=113215, loop number=1)+
         Heap Fetches: 113215
(1 row)

SET enable_mergejoin TO false;
ALTER TABLE child_t VALIDATE CONSTRAINT fk_child_parent;

 select plan from pg_query_state(1483434);
                                             plan
-----------------------------------------------------------------------------------------------
 Hash Anti Join (Current loop: actual rows=0, loop number=1)                                  +
   Hash Cond: (fk.entity_egrn_id = pk.id)                                                     +
   ->  Seq Scan on child_t fk (Current loop: actual rows=1, loop number=1)            +
         Filter: (entity_id IS NOT NULL)                                                 +
   ->  Hash (Current loop: actual rows=0, loop number=1)                                      +
         Buckets: 67108864  Batches: 8  Memory Usage: 165802kB                                +
         ->  Seq Scan on parent_t pk (Current loop: actual rows=33979819, loop number=1)

SET enable_hashjoin TO false;
SET enable_mergejoin TO false;
ALTER TABLE child_t VALIDATE CONSTRAINT fk_child_parent;

select plan from pg_query_state(1483434);
                                               plan
---------------------------------------------------------------------------------------------------
 Nested Loop Anti Join (Current loop: actual rows=0, loop number=1)                               +
   ->  Seq Scan on child_t fk (Current loop: actual rows=329042, loop number=1)           +
         Filter: (entity_id IS NOT NULL)                                                     +
   ->  Index Only Scan using parent_t_pkey on parent_t pk (actual rows=1 loops=329041)+
         Index Cond: (id = fk.entity_id)                                                     +
         Heap Fetches: 329041

Почему всё это может быть важно:
1. Вы банально могли что-то делать в своей сессии и манипулировать её состоянием, например "форсить" вычитку через Nested Loop, а затем запустить построение/валидацию FK на громадных таблицах.
2. По каким-то причинам PG выбрал неподходящий план, и вы знаете, что другой способ будет наверняка лучше :).

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Module Info в бинарных файлах модулей Postgres

Если вы мэйнтейнер расширения Postgres, модуля без UI или просто пользуетесь некоторым набором расширений на регулярной основе, то ваше мнение будет здесь очень полезно.

Каждый модуль, который вы попытаетесь загрузить в Postgres, в обязательном порядке содержит в своём теле информацию о версии ядра, для которого оно было собрано и параметрах его сборки. Обоснование необходимости этого можно найти в треде с обсуждением этой фичи, однако идея прозрачна: это сделано для того, чтобы предотвратить ошибку загрузки несовместимого модуля и связанные с этим нестабильности в работе инстанса СУБД.

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

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

Гораздо проще было бы, если бы ядро содержало в себе фунцию, например, module_info(module_name), которая позволяла бы изнутри СУБД (например, в консоли psql) определить полный путь и имя файла, содержащего искомый модуль. Более того, при наличии двух версий одного модуля в ядре (да, бывает и такое!), мы получаем возможность обнаруживать потенциальные конфликты. При этом, появляется возможность автоматизировать обнаружение модулей и их версий в системе другими модулями - да, я ненавижу использовать функцию SerializeLibraryState и другие грязные хаки для этой цели!

Ещё одна причина (уже глубоко техническая) связана с тем, что теперь (с апреля 2024 г.) расширения для текущей и последующих версий Postgres могут использовать dynamic shared memory (DSM) без необходимости быть загружаемыми при старте инстанса. Это открыло путь разработки легковесных модулей, которые могут быть загружены динамически в каждом отдельном бэкенде. Помимо производительности преимущество здесь в том, что появляется возможность реализовать технику онлайн-апгрейда расширения - установив новую версию модуля в системе под другим именем и загружая такую новую версию во вновь стартующих бэкендах мы имеем обновление функциональности на лету, без остановки инстанса! - по крайней мере, у меня в голове вырисовывается именно такой сценарий.

С другой стороны, проект omnigres (автор Yurii Rashkovskii) также пришёл к идее версионирования модулей, хотя и делает это внешним, по отношению к ядру, путём.

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

Перед тем, как начинать долгий путь обсуждения кода в hackers mailing list будет очень полезно аккумулировать опыт и мнения других разработчиков и мэйнтейнеров расширений Postgres. Нужна ли такая фича? Должна ли она быть опциональной или обязательной? Какая информация о модуле нужна (или просто будет полезна) в ваших инсталляциях?

Предлагайте ваши идеи и делитесь своим мнением в комментах, или в github-дискуссии сообщества PGEDC разработчиков расширений Postgres. Каждое мнение имеет ценность!

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Вклад авторов