PostgreSQL *

Предлагаю вашему вниманию немного дополненный доклад, который я делал на конференции PGConf.СПб 2024. В нем я рассказываю о том, как появились первые реляционные системы, как возник и всех победил язык SQL.

Хочу поделиться с сообществом свой наработкой по мониторингу бэкапов PostgreSQL.

Для того чтобы делать сами бэкапы, используется сторонний open source инструмент pg_probackup (разработка компании Postgres Professional).

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

Остается проблема мониторинга. Предположим, мы настроили pg_probackup и он трудится упорно, вызываемый регулярно через cron.

Как мы узнаем, о том, что что-то сломалось?

Для решения этой проблемы был написан небольшой экспортер метрик pg_probackup для Prometheus.

Для тех, кто устал от «зоопарка» решений по созданию отказоустойчивых кластеров, расскажем, как добиться нужной функциональности одним решением. BiHA позволяет данным «выжить», даже если один из ЦОДов был физически уничтожен. Как же мы этого добились?

В мире данных и аналитики, где каждый день генерируются огромные объемы информации, создание единой платформы для работы с данными становится неотъемлемой частью успешной стратегии бизнеса. Мы команда РСХБ.Цифра, в которой я, Кристина Проскурина, руковожу управлением бизнес-анализа данных,  а Алексей Кошевой, руководитель отдела развития витрин данных «РСХБ-Интех», руководит разработкой аналитической отчетности и платформы по исследованию данных. В этой статье мы расскажем, как наша команда разработала единую песочницу для аналитиков, которая объединила все инструменты и ресурсы в одном месте, обеспечивая эффективность, удобство и возможность совместной работы.

Приветствую всех хаброжителей и тех, кто читает мою статью. Меня зовут Александр, я являюсь ИТ директором с более 15-летним стажем, начинал в 2002 году обычным программистом в международной FMCG компании, что сильно повлияло на меня как человека и как ИТ специалиста.

Но статья не об этом, повествование пойдет о другом, об 1С и SQL, а именно о том, как быть если нужно выгружать данные из этой самой 1С, да еще, когда она не одна, да и в разных городах и странах. Трудился я в международной алкогольной компании и достался мне «зоопарк» ИТ систем (думаю, что многим понятно и известно, о чем я говорю). Среди этих систем была самописная ERP система с подчиненными базами (больше 100 штук) на базе СУБД Firebird и клиенты, написанные на Delphi и Microsoft С#, годами пока это все развивалось и росло, появились запросы и потребность в анализе данных и стали реализовываться различные выгрузки данных. Получаемые данные как тогда водилось стали выгружать в MS SQL в специально созданную базу (DWH) используя MS SSIS и потом трансформировались в OLAP кубы в MS SSAS. Еще была систем именуемая как «Бизнес-процессы» на базе 1С Бухгалтерия 1.6, с последующим обновлением и совместимостью, чтобы запустится на платформе 1С 8.3, на обычных формах с многокилометровыми модулями кода. Обшито все это было микросервисами (как сейчас это принято называть) и обменивалось между собой как-то, никому 100% не известно как.

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

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

Писать будем на PostgreSQL 13+, так как он отлично поддерживает нужные нам конструкции: FILTER, ROW_NUMBER(), CASE, NULLIF, CTE.

На PgConf 2025 было три зала, в которых параллельно шли доклады. Поэтому охватить своим присутствием все доклады не представлялось возможным. В часть залов было не попасть, так как толпа участников толпилась на входе. Такое произошло и с докладом Михаила Жилина "Как PostgreSQL может сделать больно, когда не ожидаешь". В докладе описывалось 6 актуальных проблем. Проблема "#1: Глобальные счетчики" затрагивает почти все приложения, обновляющие строки в таблицах баз данных PostgreSQL. В этой статье рассматривают детали проблемы.

Хабр, привет! Меня зовут Алексей Быков, и я занимаюсь развитием Cloud Native платформы для обработки, хранения, анализа и управления данными Arenadata One в компании Arenadata. Современные высоконагруженные системы требуют гибкого масштабирования и отказоустойчивости для обеспечения стабильной производительности в условиях постоянно растущих объёмов данных. Когда речь идёт о PostgreSQL, развёрнутом в Kubernetes, перед инженерами встают особые вопросы: как упорядочить реплики для отказоустойчивости, каким образом настроить бэкапы и мониторинг, а главное — как корректно масштабироваться в облачной среде.

В этой статье мы рассмотрим, почему «ванильный» PostgreSQL в контейнерной среде может работать ненадёжно и какие механизмы применяются сегодня, чтобы сделать базу данных по-настоящему Cloud Native. Разберём ключевые аспекты классических инсталляций Postgres, проанализируем, в чём заключаются основные сложности их переноса в Kubernetes.

Всем доброго дня! Пишу здесь впервые. На написание меня этой статьи побудило желание рассказать людям об эффективном способе миграции от внутренней базы данных Sqlite3 к внешней БД PostgreSQL. Подобной статьи на Хабре я не нашел, поэтому надеюсь будет полезно.

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

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

Рекурсивно вычисляем логические выражения и разбираем устройство двоичного сумматора.

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

Всем привет! Меня зовут Василий Куликов, я работаю ведущим разработчиком в Техплатформе Екома и Райдтеха Яндекса и последние пять лет разрабатываю фреймворк userver.

Это веб‑фреймворк, который позволяет создавать высоконагруженные отказоустойчивые сервисы на С++. Сегодня я расскажу, как написать на нём игрушечный, но рабочий сервис, который реализует функциональность pastebin.

Закончилось основное событие года в мире PostgreSQL - PgConf 2025. В статье рассматривается патч, который ускоряет закрытие месяца в 1С-ERP в 10 раз, что довольно значительно. Патч был анонсировано в докладе "Быстрое закрытие месяца в 1С:ERP на PostgreSQL" или "Закрывай месяц в 1С ERP на PostgreSQL быстро и незаметно".

С 1С:ERP я не знаком, но знаю, что для 1С выпускаются специальные сборки PostgreSQL. Наполнившись решимостью узнать, что в этом 1С происходит я пожертвовал докладом про карту видимости, который шёл параллельно и не пожалел.

Я узнал, что в 1С никто ничего не делает, кроме как месяца закрывают и больше никого ничего не интересует, а также то, что по статистике пользователи приложения 1С:ERP делают что-либо, в среднем, раз в 20 минут. "Закрытие месяца" - набор расчетов и действий, которые могут выполняться часами. При этом с первого раза месяц обычно не закрывается, так как обнаруживаются ошибки учёта, которые должны быть исправлены и закрытие месяца повторяется заново. И так несколько раз. В докладе осветили нюансы установки границы итогов, удобство использования клонов кластера баз данных, описали причины проблем.

Основная интрига доклада была в том, что "секретный патч Фёдора Сигаева" ускоряет закрытие месяца в 10 раз (на порядок!). Не каждый день встретишь ускорение на порядок.

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

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

Применяем простые операции над массивами, чтобы определить связность графов.

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

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

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

Требования, которые команда сформулировала к новому каталогу:

Порядок столбцов в таблицах влияет на компактность и производительность. При небольшом числе строк на это не обращают внимание. Если в таблицах хранится много строк, то даже небольшое уменьшение объема хранения может быть полезно. У столбцов есть оптимальный  порядок и менее оптимальные, которые отличаются размером, который используют строки при физическом хранении. Причина того, что переставив столбцы строки в таблице с теми же самыми данными, меняют размер в выравнивании (aligning) и заполнении нулями (padding). В блоке данных выравниваются все структуры: заголовки, поля строк и целиком сами строки.

На 64-разраядных операционных системах, длина любой строки и заголовка строки  выравниваются по 8 байт. То есть если строка занимает 28 байт, то физически она займёт 32 байта. В конец строки будут добавлены пустые байты. Поля выравниваются сложнее - по 4,8, 16 байт. В статье рассматривается перестановка столбцов на примере демонстрационной базы.

Выбор подходящей системы управления базами данных (СУБД) — важнейшая задача при проектировании программных систем. Разработчики и архитекторы учитывают множество факторов: модель данных (реляционная или NoSQL), поддержку транзакций, масштабируемость, требования к согласованности и многого другое. Одним из ключевых архитектурных аспектов, влияющих на эффективность и надежность системы, является модель репликации данных. Репликация означает поддержание копий одних и тех же данных на нескольких узлах (серверах), соединённых по сети​.

Зачем это нужно? Репликация позволяет: во-первых, держать данные ближе к пользователям (уменьшая задержку при запросах); во-вторых, продолжать работу системы даже при сбое отдельных узлов (повышая доступность); в-третьих, масштабировать систему, увеличивая число узлов для обслуживания запросов на чтение (повышая пропускную способность)​.

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

По прогнозу Gartner, запросы на естественном языке вытеснят SQL уже в 2026 году. Возможно, прогноз Gartner чересчур оптимистичный, но если они и ошибаются, то только в сроках — сам переход на естественный язык в работе с БД неизбежен.

Go. PgxWrappy как решение всех проблем PgX. Если вы сталкивались с неудобным сканом в структуры посредством PgX на Go, то гляньте эту либу. Она решает все проблемы сканинга.