PostgreSQL *

Привет всем!

Я — Ипатов Александр, backend‑разработчик в ГК Юзтех. Сегодня хочу поделиться своим опытом в интересном проекте, связанном с миграцией БД MsSQL на PostgreSQL в разрезе оптимизации хранимых процедур и функций (далее — хранимых процедур, так как процесс оптимизации не сильно завязан на том, что именно имеем на выходе).

Актуальность проектов, связанных с миграциями серверов и баз данных с зарубежных платных продуктов (Microsoft, Oracle) на аналогичные отечественные или зарубежные open‑source решения (в разрезе статьи будем рассматривать Postgres) в 2024 году очень велика. Те решения, которые были реализованы и поддерживались на протяжении 5–10 лет, потребовалось практически в формате «пожара» переносить на аналогичные. А бизнес, который привык к уже полностью сформированным и отработанным рабочим процессам, не готов к потере эффективности и, как следствие, потере клиентов сервисов, заказов и бизнес‑метрик.

В одном из таких проектов мне удалось поучаствовать. Из начальных условий: проект по переносу БД из MsSQL начался примерно 3 года назад.

На самом деле, проект был более обширный — перенос монолитного сервиса на микросервисы, в том числе, как один из элементов — перенос БД.

Хочется отметить, что перенос схем, таблиц, индексов и других элементов базы данных прошел относительно спокойно. Чего не скажешь о переносе хранимых процедур. Язык T‑SQL, на котором пишутся хранимые процедуры в MsSQL, конечно же имеет отличия от PL/pgSQL, который используется в PostgreSQL. В связи с чем, непосредственно миграция хранимых процедур заняла много времени: точное число хранимых процедур я не назову, но порядок — около 800 штук (среди которых 500 стали работать хуже после миграции, их то и предстояло оптимизировать).

В этой статье мы расскажем о том, как эффективно реализовать полнотекстовый поиск с помощью PostgreSQL. Узнайте, как улучшить скорость и точность поиска по текстовым данным, используя такие инструменты, как tsvector, tsquery и индексы GIN, и как эти возможности могут значительно повысить производительность вашего приложения.

В очередной рабочий день поступила задача обновить Gitlab. Задача в общем-то не сложная, ни смотря на то, что там он установлен в докере из многим знакомого образа от sameersbn, что впоследствии было переделано на omnibus (что бы это не значило), т.к. по моему опыту omnibus версия (установка на чистый линукс) гораздо проще и предсказуемей в эксплуатации. Впрочем статья совсем не об этом.

Но как можно понять из наличия этой статьи, что-то пошло не так...

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

Но буквально на днях вышел PostgreSQL 17 и может там что-то изменилось? И да, и нет. Та самая мана небесная в виде pg_awesome_backup_tool так и не появилась, однако в релиз попал механизм walsummarizer, который обещает нативно отслеживать изменения в файлах баз данных, что позволит делать инкрементальные бекапы нативно и без лишних приседаний.

А чтобы не рассматривать новичка в вакууме, будем сравнивать его с ptrack - нашей (Postgres Professional) разработкой, которую наши любимые конкуренты уже расхватали в свои продукты и продают их как уникальнейшие решения.

В моей работе, когда приходится исследовать и нагружать СУБД нетипичной нагрузкой и синтетическими тестами, часто встречаются случаи загадочного поведения системы: ускорение/замедление времени выполнения запроса на пару порядков, отказ использовать тот или иной индекс и тд. Объяснение странного поведения оказывается в итоге почти всегда тривиальным и хорошо известным опытным DBA. Однако встретив его в реальной эксплуатации первый раз невольно теряешься и на разбор кейса уходит много времени. Вместе с тем, это достаточно интересное упражнение - навроде того, как прорешать задачник по аэродинамике после 10 лет проектирования планеров самолётов. Поэтому предлагаю здесь попробовать формат обсуждения/изучения PostgreSQL в виде задач. Вдруг зайдёт?

Привет, Хабр! Меня зовут Михаил Герасимов. Это продолжение статьи «Как в РСХБ разработали средство генерации SQL-запроса для упрощения задач по тестированию», где описывались принципы работы QueryBuilder. 

В условиях растущего тренда на импортозамещение в ИТ-компаниях, переход с коммерческих СУБД на Open Source решения стал одной из ключевых задач для многих организаций. В частности, в проекте по автоматизации тестирования специалисты РСХБ успешно адаптировали свой инструмент генерации SQL-запросов QueryBuilder к переходу на PostgreSQL.

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

…Если паттерны доступа существенно изменятся, то может потребоваться полная повторная обработка всех данных».

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

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

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

Ещё до того, как я начал заниматься разработкой, мне пришла идея поучаствовать в создании собственной CRM-системы и глубже погрузиться в процесс её разработки. Спустя несколько лет я начал заниматься веб-разработкой, и в какой-то момент понял, что даже небольшому бизнесу, где я работал, нужна CRM. Я пробовал использовать таблицы в Google Docs, тестировал триальные версии популярных CRM, но они были перегружены ненужной информацией и казались неудобными. Так что я решил создать что-то простое, что будет удобно мне и, возможно, другим.

В своей CRM я использую Next.js. Эта система не претендует на то, чтобы обслуживать тысячи пользователей, но она точно может решить задачи 1-2 небольших отделов продаж. У меня есть репозиторий на GitHub, и если кому-то это решение покажется интересным, его можно взять и доработать под свои задачи. В этой статье я постараюсь кратко описать текущий функционал, с какими трудностями я столкнулся и что удалось внедрить в качестве новых гипотез.

Привет, Хабр! В начале октября вышло обновление нашей СРК Кибер Бэкап. Спешим поделиться обзором новинок в версии 17.1.

Чтобы объяснить, что есть Postgres Pre-Commitfest party и зачем мы в это ввязались, для начала нужно объяснить, как идёт разработка ванильного постгреса. Процесс принятия новых фичей и патчей в код разделён на так называемые коммифтесты (сокращённо CF), расписание которых всегда можно посмотреть на сайте https://commitfest.postgresql.org/. Когда разработчик предлагает свой код (неважно, будь это новая фича или багофикс), для того чтобы он был рассмотрен в рамках CF, он предварительно должен пройти процедуру ревью и быть одобрен для рассмотрения. Конечно, это совершенно не гарантирует, что код будет принят на этом CFили даже следующем, но сейчас не про это.

Найти ревьюера для своего кода зачастую задача более сложная, чем написать сам код. Человека надо погрузить в решаемую проблему, объяснить, что именно ты предлагаешь изменить, почему так, а не иначе и так далее. Прямо сейчас, в статусе Needs review, находится 29 патчей. Со свойственным нам желанием помогать, мы решили кинуть клич среди коммитеров и собрать всех желающих под одной крышей, чтобы они могли представить свои патчи, обсудить их и, возможно, найти желающего провести ревью.

Так получилось, что собрались мы в рамках проходившего Highload++ в Санкт-Петербурге. Поскольку Open Source — дело добровольное, мы просто разослали всем контактам, которые у нас были, предложение примерно следующего содержания: зовём всех неравнодушных постгресистов собраться в шатре, рассказать про свои патчи, обсудить их и хорошо провести время.

Продолжаем цикл статей по асинхронной SQLAlchemy в стиле ORM!

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

Что нас ждёт сегодня?

- Сессии и фабрики сессий: Узнаем, как эффективно управлять сессиями для взаимодействия с базой данных.

- Добавление данных в таблицы: Освоим безопасные методы добавления новых записей с использованием ORM-методов.

- Извлечение данных из таблиц: Погрузимся в мир извлечения данных. Рассмотрим простые запросы и более сложные фильтры для работы с данными.

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

Не пропустите, будет интересно и полезно!

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

Сегодня столкнулся с очередным нетипичным вариантом использования - "перекладыванием" значений из JSON-строк в столбцы.

Давайте сделаем это попроще.

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

Ниже речь будет идти о чтении данных одной БД из другой БД. В частности я решал такую проблему:

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

То есть запрос вида:

select a.id from auth.public.user a join trade.public.tenders t on a.id = t.user_id;

Вызовет ошибку "[0A000] ERROR: cross-database references are not implemented".

Что делать ?

Наконец-то пришло время взяться за то, что я давно планировал — подробный гайд по асинхронной версии SQLAlchemy 2.0 в стиле ORM. В этой серии статей я подробно расскажу обо всех аспектах: от создания моделей и установления связей между ними до миграций с Alembic и взаимодействия с данными в базе. Мы будем шаг за шагом разбирать ключевые моменты работы с асинхронной базой данных, что позволит вам глубже понять SQLAlchemy и применить эти знания на практике.

Для начала, давайте разберёмся, что такое SQLAlchemy и почему каждый разработчик, работающий с реляционными базами данных (такими как SQLite, PostgreSQL, MySQL и т. д.), должен знать о ней. После этого — настройка. Мы будем работать с PostgreSQL, но не переживайте: код, который мы напишем, универсален для всех реляционных баз данных. Мы начнем с базовой настройки SQLAlchemy для асинхронного взаимодействия, а затем перейдём к созданию таблиц в современном декларативном стиле.

Привет, друзья!

Продолжаем нашу серию статей о создании BI-системы в компании Sminex. Расскажем о наших дальнейших шагах по построению хранилища с якорной моделью.

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

Сегодня мы прокачаем PostgreSQL, добавив в него Python. А именно — PL/Python. Это расширение позволяет писать функции на Python прямо внутри базы данных. Лично для меня это как объединение двух лучших миров: любимого PostgreSQL и могучего Python.

PL/Python — это про то, когда стандартного SQL мало. Когда надо сделать что-то действительно интересное: сложные расчеты, массивы данных, или интеграция с аналитикой прямо в базе. А самое крутое — можно тянуть любые Python-библиотеки.

Для начала нужно просто установить расширение в PostgreSQL.

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

Рассмотрим классические ситуации, когда разработчики начинают жаловаться на производительность БД - а виновата-то и не она!

Привет, Хабр! Решил написать небольшую, техническую статью, о том, как мы ускорили запрос в таблицу, до которой не доходил autovacuum из-за большой нагрузки на БД примерно в 200 раз, а разгребание outbox очереди — ещё примерно в 3 раза.