PostgreSQL *

• Могут ли диапазоны содержать пропуски значений?
• Зачем нужна индексная нотация типу json?
• Может ли индекс при частых обновлениях разрастаться меньше, чем таблица? А вообще не разрастаться?
• Сколько времени простаивали сеансы в idle_in_transaction?
• Как построить ER-диаграмму для таблиц системного каталога?

При поиске проблем в RDBMs разработчик обычно подозревает медленные запросы. А что, если дело не в них? О том, какого типа запросы дают нагрузку на базу данных, не позволяя вашему приложению работать должным образом, рассказал в своем докладе на конференции Saint HighLoad++ Online 2020 администратор баз данных Data Egret Андрей Сальников. 

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

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

Сегодня мы рассмотрим более сложный вариант, который зачастую начинается со слов "А заказчик захотел…" и приводит нас к иерархичным агрегатам в нескольких одновременных разрезах, которые позволяют нам в СБИС практически мгновенно строить оперативные отчеты в подсистемах организации торговли, бухгалтерского учета и даже управления активными продажами.

PostgreSQL хранит данные на каких-то носителях. И между PostgreSQL и, например, магнитной поверхностью диска находится несколько кешей: кеш самого винчестера, кеш RAID-контроллера или винчестерной полки, кеш файловой системы на уровне операционной системы и кеш самого PostgreSQL. Если первыми перечисленными кешами мы практический не можем управлять, то последними, находящимися в ОЗУ сервера, управлять можем: например, выделяя больше ОЗУ под кеш PostgreSQL в ущерб кешу ОС, или наоборот. В официальной документации можно прочитать ничем не подтвержденные рекомендации, типа выделять под PostgreSQL четверть ОЗУ. Это вызывает сомнения. PostgreSQL в виде Postgres95 впервые появился в 1995 году и, кто знает, быть может и эти рекомендации относятся к тому же году. Поэтому появилась идея эксперимента с целью разобраться, как лучше распределять ОЗУ.

Конференции

Как сообщает telegram-канал Cross Join, в репозиторий Postgres упал комит, упрощающий работу с jsonb. Теперь можно обращаться к частям jsonb с помощью квадратных скобок, причем это работает как на чтение, так и на запись.

Прощай jsonb_set  и прочие костыли типа data = data - 'a' || '{"a":5}'

Несколько примеров:

Обновляем значение объекта по ключу. 25 здесь является числом, но взято в кавычки, потому что присваиваемое значение должно быть jsonb

-- (person_data имеет тип jsonb)
UPDATE users 
SET person_data['age'] = '25'; 

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

Я столкнулся с рядом проблем при попытке подключить libpq в VS 2017: начиная с несоответствия документации по данной API с инструкциями по подключению, заканчивая умолчанием некоторых ключевых моментов.

В общем по порядку.

В общем задача звучала так: установить Redmine на сервер, где веб-сервер на nginx.

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

Предположим, вам надо обработать на PostgreSQL большое (не, не так... БОЛЬШОЕ) количество записей, чтобы посчитать какие-нибудь агрегаты. В предыдущей статье были разобраны различные варианты, как это можно организовать, а в этой посмотрим, как при этом особо никого не заблокировать, включая "набегающий поток" данных.

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

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

Вообще Postgres очень известен и о расширении ltree написано, если немного, то достаточное кол-во публикаций, в том числе и на Хабре тоже, да и сообщество Laravel довольно обширное.

Но как ни странно, я обнаружил полное отсутствие каких-либо библиотек для работы с расширением ltree (от PostgreSQL) под Laravel на GitHub.

Есть некоторые попытки для Yii2, также есть наработки для Symfony (по моему bundle для 2-й, из коробки не работает), и на этом, пожалуй, все.

Это очень грустно, что и послужило поводом написания данной статьи, как наверное и от части, желание поделиться с вами своим опытом работы с древовидными справочниками в Laravel, т.е. как мы работаем с ltree в своих проектах, собственно, почему в итоге мы выделили эти компоненты в GitHub в общий доступ.

На мой взгляд, это очень удобная библиотека, о которой я вам сегодня хочу рассказать. И буду очень рад, если вам она будет полезна.

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

Если это какая-то локальная утилита - не страшно, само ее существование у пользователя достаточно ограничено. Но если это что-то вроде нашего СБИС, который накапливает и помогает анализировать операции за все время существования бизнеса, то, по мере его роста, не только операций становится больше, но и понимания, какие именно сводные отчеты помогают в оперативном управлении.

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

Для многих систем характерен паттерн постоянного накопления данных с течением времени. Причем основная их масса больше никогда не изменяется - то есть они пишутся в режиме append-only.

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

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

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

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

Сегодня, как вы уже заметили, мы будем говорить про Postgres, про миграции Laravel, как это все вместе подружить, в общем, обо всем том, чего нам не хватает в стандартных миграциях Лары.

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

Но я все же рекомендую не пролистывать, а прочитать все до конца.

Есть такой продвинутый инструмент Scrutinizer CI.

Для OpenSource он абсолютно бесплатный и платный для приватных репозиториев.

Вы о нем слышали, наверное, а если нет, то лично я использую его для анализа кода на различного рода уязвимости, а также в качестве замены статическому анализатору типа Psalm, ну и для покрытия конечно же, т.к. при довольно простой сквозной интеграции с GitHub оно внедряется в ваши PR и можно ревьюить код, наблюдая покрытие по аналогии с Cubertura в GitLab.

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

Поэтому я решил поделиться с вами своим опытом интеграции со Scrutinizer CI, рассказать о нюансах и тд...

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

Традиционно, есть два подхода к этой задаче: запрос по требованию по "сырым" данным или предварительная агрегация. И если "просто посчитать" такой отчет по первичке - упражнение для SQL-новичка, но очень "тяжелое" для производительности СУБД, то вариант сделать так, чтобы он строился практически мгновенно при большом количестве активных аккаунтов независимых бизнесов, как у нас в СБИС, без необходимости пересчитывать агрегированную статистику каждый день судорожно по всем клиентам - интересная задача.

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