PostgreSQL *

По долгу службы, мы много работаем с деньгами. Складываем, вычитаем, считаем проценты. Любому школьнику известно, что для этих расчетов не подходят обычные встроенные в язык типы: флоаты не сойдутся у финансовых аудиторов, большие целые принесут кучу проблем при конвертации (например, йены обходятся без дробных единиц, а в одном оманском риале — 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 - для просмотра данных в базе.

Решим сегодня простую, казалось бы, задачу: как на PostgreSQL можно в строке провести замены по набору пар строк. То есть в исходной строке 'abcdaaabbbcccdcba' заменить, например, 'а' -> 'x', 'bb' -> 'y', 'ccc' -> 'z' и получить 'xbcdxxxybzdcbx'.

Фактически, мы попробуем создать аналог str_replace или strtr.

В 1С у нас есть редкая свобода перехода с одной СУБД на другую (MS SQL, Oracle, Db2, Postgres). Но чем больше база, тем больше цена свободы. Данная статья позволяет спрогнозировать время, которое Вы потратите на переход с MS SQL на Postgres простой конвертацией через Dt.

Дисперсионный анализ (ANOVA) — это статистический метод, который используется для сравнения средних значений двух или более выборок. Он позволяет определить, различаются ли средние значения между группами, или же различия случайны. ANOVA используется в различных областях, включая науку, инженерию, медицину, социологию и многие другие, где необходимо доказать связь между переменными.

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

Правильное применение ANOVA может доставить большую пользу и сделать исследование намного более информативным.

Здравствуй, дорогой читатель. Каждый разработчик, независимо от его специальности, сталкивался (или столкнётся во время своей профессиональной карьеры) с задачей, в которой необходимо разработать проект, имеющий базу данных, серверную часть и конечный продукт, взаимодействующий с пользователем. Данная статья поможет новичку разобраться с данной задачей.

В статье будут затронуты такие важные темы, как теория баз данных, реляционная база данных PostgreSQL, Spring Framework и Android разработка. Также будет рассмотрен базовый, не очень сложный пример, который поможет разобраться во всех этих темах и "потрогать" их руками.

Статья предназначена для начинающего разработчика, но имеющего базовые знания о разработке программного обеспечения и языках программирования Java и Kotlin.

Все материалы и исходный код можно найти здесь.