PostgreSQL *

Привет! Меня зовут Васильев Виктор, я DBA в компании UIS и CoMagic. В этой статье на реальных примерах расскажу, как можно сэкономить время разработчика, администратора баз данных и ресурсы сервера(ов), используя утилиту pg_rebuild_table. Сопровождая большие, высоконагруженные системы, с бо’льшей вероятностью каждый сталкивался с кейсами, о которых будет рассказано дальше. Некоторые технические подробности пройду без детализации, чтобы сильно не усложнять и не делать статью очень громоздкой. Лучше отвечу на вопросы в комментариях.

В этом году наша компания впервые провела конкурс по базам данных в рамках международной олимпиады IT-Планета по информационным технологиям. Раньше на олимпиаде использовалась СУБД Oracle; наш коллега Евгений Бредня в свое время делился таким опытом.

Олимпиада проходила в три этапа. Первым шел заочный теоретический тест, который преодолели примерно двести человек из двух тысяч зарегистрировавшихся.

На втором этапе участникам было предложено подумать над пятью задачами, каждую из которых следовало решить одним SQL-запросом. Этот этап также проводился заочно: на раздумья было дано примерно три недели. Условия всех задач были опубликованы одновременно, но у каждой был свой крайний срок; поэтому первыми шли задачи полегче, чтобы на более сложные осталось больше времени. Задачи проверялись на корректность (автоматическими тестами) и на качество кода (вручную). По результатам мы отобрали двадцать человек для последнего, очного этапа.

Третий этап состоялся 27 мая в Сочи. К сожалению, из двадцати приглашенных приехать смогли только четырнадцать; между ними и состоялось соревнование. Задачи этого этапа также предполагали решение одним запросом, но сами задания были объединены общей темой, навеянной игрой Го, и строились так, что решение одной задачи помогало подступиться к следующей.

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

В данной статье будет описано, как создать простой kafka producer и kafka consumer, а затем протестировать их.

Привет, Хабр! В прошлой статье я  писал о том, как реализовать end-to-end тестирование telegram-бота. А сегодня расскажу о том, как реализовать полнотекстовый поиск в Postgres посредством SQLAlchemy и как его проиндексировать. 

Меня зовут Михаил Выборный, я python-разработчик, backend-developer в облачном провайдере beeline cloud. Вы узнаете, как подготовить файл миграции для alembic. В конце статьи я приведу ссылку на небольшой репозиторий, где реализовал сервис-класс для удобной интеграции поиска в свой проект. 

По долгу службы, мы много работаем с деньгами. Складываем, вычитаем, считаем проценты. Любому школьнику известно, что для этих расчетов не подходят обычные встроенные в язык типы: флоаты не сойдутся у финансовых аудиторов, большие целые принесут кучу проблем при конвертации (например, йены обходятся без дробных единиц, а в одном оманском риале — 1000 баиз, а не сто, как у всяких плебейских долларов и евро), и так далее. Существуют целые комитеты, определяющие стандарты (ISO 4217 — коды валют и ISO 24165 — идентификаторы цифровых токенов). Во всех более-менее современных языках есть библиотеки для работы с денежными суммами, реализующие стандарты и скрывающие от нас адовую арифметику без потерь точности.

В мире эликсира, почти всем, что связано с имплементацией комитетских стандартов, занимается Кип Коул. Удобной работе с деньгами мы обязаны тоже его библиотекам: ex_money — для собственно арифметики и money_sql для персистенса.

Кто не любит убирать мусор? Думаю практически все, а вот в Postgres это обязательный ритуал для эффективной работы. Как эффективно настроить уборку за 1С в Postgres можно прочитать в этой статье и еще раз задуматься о бесплатности Postgres.

Spring Data JPA: замена нескольких запросов одним и почему это очень важно.

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

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

Beta!

Это Beta 1 - PostgreSQL 16 Beta 1. После неё будут ещё беты, число которых заранее не известно - по обстоятельствам. После появится релиз-кандидат, скорее всего тоже не один. Официальный релиз запланирован на конец 2023-го. Можно заглянуть в Beta Testing в случае заинтересованности.

Представьте: вы – крупный производитель и ритейлер товаров для дома, который обрабатывает в сутки тысячи заказов по всей стране. Но при этом у вас нет единого алгоритма расчета стоимости доставки – из-за этого суммы почти всегда разные, иногда завышенные.

Меня зовут Артём Кияшко, я руковожу группой аналитиков в крупной ИТ-компании. В этой статье расскажу о том, как мы разработали и внедрили сервис расчёта стоимости доставки. 

Возможно ли не замечать «лишних» 30 Tb данных на SSD при живом настроенном мониторинге и героически их обслуживать? Запросто, а ответы на вопросы кто же эти наблюдательные люди, как им это удалось и причем здесь PostgreSQL — ниже.

1. В монолите концентрировалось большое количество бизнес-процессов, которые охватывали сразу несколько потребителей: пользователей облачной платформы, сейлз-менеджеров (через CRM-систему), администраторов, обработчиков метрик. Получилась такая одна большая точка отказа сразу для 4 групп бизнес-процессов.
2. Каждый бизнес-процесс потребляет свой объем ресурсов. Например, для обработки метрик нужно 5 подов (чтобы запараллелить и ускорить обработку), для администрирования хватит и одного. Так как у нас все в одном сервисе, при масштабировании монолита мы будем ориентироваться на самый «прожорливый» бизнес-процесс. Часть ресурсов будет просто простаивать.
3. Хотелось добиться гранулярности, чтобы независимо писать и деплоить код для каждого бизнес-процесса. И не переживать, что какие-то изменения в одном бизнес-процессе неожиданно отрикошетят в соседний.

Недавно на одном из проектов для телекоммуникационной компании нам пришлось дополнительно (не без помощи коллег из ИБ J) проработать вопрос безопасного использования паролей для подключении к базе данных PostgreSQL кластера Zabbix.

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

Но вернемся к нашей задаче. Изучив входные данные об инфраструктуре заказчика, мы сразу обратили внимание, что коллеги в сегменте ИБ уже используют решение от HashiCorp — Vault, что и стало для нас отправной точкой:

— во-первых, Zabbix отлично интегрируется с решениями от HashiCorp;

— во-вторых, у нас есть опыт работы с HashiCorp Vault.

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

Итак, в этом посте пройдемся по нескольким шагам:

1. Рассмотрим нашу схему работы HA Zabbix и дадим краткую характеристику данному стеку.

2. Рассмотрим предполагаемый вариант использования Vault в связке с HA Zabbix.

3. Предложим конфигурацию для данного решения.

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

Эта статья посвящена двум более сложным миграциям:

- обновление большой таблицы
- разделение таблицы на две

Рассмотрим подходы, которые позволяют провести миграции с минимальным простоем для приложения.

Продолжим погружение в код PostgreSQL. Сейчас посмотрим, что происходит, когда вы хотите выполнить запрос сложнее, чем в прошлый раз: добавим WHERE, GROUP BY, HAVING, ORDER BY, LIMIT.

Плюс:

• Системный кэш

• Сходство обращения к столбцам и вызовов функций

• Предсказание количества возвращаемых кортежей

• Работа с простыми типами

• Маркировка столбцов при использовании FOR UPDATE

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

Все побежали, и я побежал… Строго говоря, историю о том, как мы научили наше приложение работать с СУБД PostgreSQL и провели первую миграцию боевой системы одного из наших заказчиков, можно было рассказать ещё три года назад. Именно тогда мы это сделали впервые. Сейчас за нашими плечами уже 11 внедрений «Единого клиента» на PostgreSQL. Две миграции на эту СУБД с Oracle пройдут в этом году. 

В статье поделюсь нашими наработками. Будет полезно тем, кто только собирается пойти по такому пути. Если тема интересна, можете посмотреть и выступление моего коллеги Вадима Зайцева на CDI Tech Conf.

В данной статье описан простой пример написания docker-compose.yml файла на примере контейнеризации приложения с использованием Spring Boot на бэкенде, React на фронте, PostgreSQL в качестве базы данных и pgAdmin - для просмотра данных в базе.