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 раза.

Идея спасти мир и при этом заработать немного шекелей витала у меня в голове уже давно. Имея неплохой накопленный опыт в области геоинформационных систем и защитивши в свое время диссертацию с их применением мне не хватало знаний разработчика. Окончив IT-курсы и получив доступ к «Святому Граалю знаний» я понял, – пора, и завертелось!

Летом 2024 года мы в составе команды «Arrow» одержали победу, заняв третье место в хакатоне «Лидеры цифровой трансформации» и вошли с нашим проектом в топ-100, став резидентами «Академии инноваторов» у нас появился свой стартапп.

Общая идея такова. Arrow - это платформа для анализа и обработки спутниковых снимков, использующая технологии машинного обучения и нейросетей для мониторинга окружающей среды, строительства и природопользования. Наш продукт помогает бизнесу и государственным структурам автоматизировать выявление экологических нарушений и незаконных построек, обеспечивая более точное и своевременное реагирование. Это в «розовом» будущем, а пока это только проект «Мобильное приложение для управления антропогенной нагрузкой на особо охраняемых природных территориях Камчатского края», занявшее призовое место, хотя и этот результат тоже когда-то был только в мечтах.

Я хочу открыть целый цикл статей в котором постараюсь осветить историю жизненного цикла нашего проекта «Arrow», которая будет писаться на ваших глазах. Здесь будет все: и фронт и бэк и мобильная разработка, будет и деплой в облако. В этих статьях, которые к стати буду писать не только я, но и ребята с моей команды, мы хотим осветить все начиная от создания MVP (минимально жизнеспособный продукт) и заканчивая выводом проекта в продакшн, анализ целевой аудитории и поиск первых клиентов, привлечение первых инвестиций, подбор команды, в общем все этапы через которые нам предстоит пройти для достижения своей цели, - получения интересного и востребованного продукта. Начнем же…

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

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

Процесс-зомби (zombie process) — дочерний процесс в Unix-системе, завершивший своё выполнение, но ещё присутствующий в списке процессов операционной системы, чтобы дать родительскому процессу считать код завершения. Обычно, когда процесс завершает выполнение и работу, операционная система собирает статус завершения дочернего процесса с помощью системных вызовов wait() или waitpid(), выполненные родительским процессом. Если родительский процесс не вызывает эти функции вовремя, информация о состоянии дочернего процесса не может быть удалена из ядра, что приводит к тому, что процесс остается в состоянии "зомби". Попытка удалить зомби-процесс с помощью kill -9 неэффективна, поскольку он не занимает ресурсов CPU или памяти, а лишь сохраняет номер процесса (PID) и небольшое количество информации о состоянии.

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

Недавно, на хабре вышла статья про один нюанс в оптимизаторе PostgreSQL [1]. Будучи предельно технической и скучной по-определению, она триггернула интересную дискуссию в комментах и дала мне, как разработчику систем баз данных, возможность взглянуть на систему с точки зрения разработчика приложений. Это оказалось крайне продуктивным и даже привело к патчу и треду в сообществе. Возможно, нам нужно больше таких небольших и узко-специализированных постов? Данная статья - попытка развить это направление.

[1] Странное поведение планировщика запросов PostgreSQL

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

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

Немного теории. Patroni — это инструмент для управления высокодоступными кластерами PostgreSQL. Он упрощает настройку и управление репликацией благодаря автоматическому переключению на резервные узлы и восстановлению после сбоев.

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

Зачем мы это делаем?

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

Итак, приступим.

Привет, Хабр. Сегодня мы, Юрий Темкин и Алексей Федоров, расскажем о том, как в нашем Кибер Бэкапе устроена поддержка PostgreSQL и СУБД на ее основе, а также обсудим новинки, появившиеся в версиях 16.5, 17.0 и 17.1.

Enums VS Tables для создания типов моделей...

Зачем использовать вообще одно из этих решений?

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

Привет, Хабр! Меня зовут Дмитрий Королёв, я инженер по нагрузочному тестированию Platform V Pangolin — целевой СУБД в Сбере и не только. Эту статью я написал вместе с моим коллегой Алексеем Хорохориным @AlexeyHorohorin. Наш продукт — специальная сборка PostgreSQL с доработками (крупных больше 30, а всего уже больше 70) в области безопасности, производительности, отказоустойчивости.

Условия для нас таковы: мы тестируем продукт целиком, в разных версиях, на разных ядрах. У нас работает три версии в параллель для восьми разных ОС, и тестировать нам нужно при использовании и неиспользовании разных фич. А теперь представьте, сколько тут интеграций…

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