Окончание заметок про постгрес.

1. Если у нас возник дедлок строки или какой-то запрос барабанит вечность - идем в представления pg_locks и pg_stat_activity, ищем источник проблемы и делаем с ним pg_cancel_backend или pg_terminate_backend.

2. Триггеры плохи не только сложностью отлова багов, но и тем что за счёт вызова доп функции на plsql, что трудозатратно.

3. Чистка мусора - vacuum - срабатывает автоматически при обновлении 20% записей. Можно подкрутить персональные настройки вакуумирования для таблиц.

4. Настройки постгреса идут из расчета, грубо говоря не более 8 ядер. Если на сервере ядер больше - можно просто выкручивать настройки параллельных воркеров пропорционально. Также диски где стоит postgres должны быть заполнены не более чем на половину, чтобы не было чудес.

#postgresql

Еще небольшая порция заметок про постгрес.

1. Параметры конфигурации, например work mem, можно менять непосредственно для пользователя. Соответственно, можно делать разные настройки для юзеров - аналитиков и юзеров, под которыми в базу ходят сервисы.

2. Узнал о существовании разных джоинов - hash, merge и nested loop join. Первый использует хэш таблицу, чтобы объединить данные из разных таблиц, второй - использует сортировки, третий тупо перебирает данные. Первый хорош для джоина неиндексированных данных. Второй берет сортировку исходя из индексов, соответственно хорош при наличии сортированных (btree) индексов по обеим колонкам, по которым осуществляется джоин. Третий хорош, чтобы сджоинить мизерную таблицу с большой.

3. Натуральные и латеральные джоины. Натуральный джоин бесполезен на мой взгляд. А вот латеральный очень интересен. Он позволяет склеить данные с близкими значениями, например склеить значения измерений температуры и влажности с чуть отличающимся временными метками.

#postgresql

Продолжение заметок по новым фишкам постгреса, которые я узнал на обучении. Начало выше.

1. Я узнал о существовании фильтрованных индексов. Например, при создании btree индекса по дате указываешь > 01.01.2024 - и твой индекс будет работать только на данные в указанном тобой условии. Собственно, можно оставить архивированое в архиве и работать только со свежими данными.

2. Увидел на практике, как использовать хинты для оптимизации запросов. С хинтами забавная история: контрибьюторы постгреса встали стеной против введения их в ядро СУБД. Потому японский Ростелеком в какой-то момент реализовал их в виде расширения pg_hint, которое может поставить себе любой желающий, если ему дадут админы и безопасники:)

3. Узнал некоторые особенности индексов, о которых раньше не задумывался.
   Хэш индексы немногим быстрее btree, но при этом лишены упорядочивания, ускорения запросов по интервалу, возможности сортировать таблицу по ним. Зато, если мы строим их по большим строкам, по которым надо будет искать только на условие равенства - они дают существенный выигрыш по размеру индекса. При этом, размер хэша меняется, подстраиваясь под данные так, чтобы был минимум коллизий.
   Есть такой тип индекса - BRIN. Отлично работает для индексации неизменяемого вечнохранимого набора данных, ранжированных по какому-то параметру. Занимает мизерное пространство на диске, но в большинстве кейсов бесполезен.

#postgresql

К своему стыду не осознавал применительно к работе и играм сего подхода: если уверен в успехе - не выпендривайся:

Не люблю доту, но с автором согласен ⬆️

К своему стыду не осознавал применительно к работе и играм сего подхода: если уверен в успехе - не выпендривайся:

Кстати сегодня день рождения .NET Core (да, тогда он назывался так).
27 июня 2016го года - день релиза .NET Core 1.0 :)

Некоторое время назад потыкал питоновские фреймворки на предмет быстрого создания веб апи. Мои требования:
1. Сваггер с описаниями методов и полей.
2. Типизированные модели, чтобы всякий мусор присылаемых извне отваливался на этапе десериализации.
3. Упаковка проекта в докер, желательно из коробки.

Этот набор требований - то что в c# даётся из коробки в шаблоне проекта.

Сначала я попробовал по старой памяти потыкать Flask. Читаю про сваггер. Можно подключить его десятком разных способов, в некоторых случаях мне предлагают прицепить yml описание методов.

Посмотрел в Django. Оказывается все не так плохо как несколько лет назад: туда завезли асинхронщину, не прошло и 10 лет. Сваггер описывается вроде нормально. Но тащить весь джанговский зверинец вместе с MVC для легковесной апишки мне запрещают религиозные убеждения. Плюс Django надо отдельно изучать, шарповый опыт не особо помогает понимать происходящее.

Попробовал новую для меня библиотеку - FastApi. Она вошла в употребление уже после того, как я полностью ушел от питона и она меня приятно удивила: все мои требования были удовлетворены в течении часа.

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

Тут против России внезапно ввёл санкции докер. По утру отвалилась сборка контейнеров, завязанных на DockerHub. Проектов на c# это не коснулось: базовые образы тянутся с сайта Microsoft.

Решений у проблемы несколько:
1. Использовать vpn на сервере для сборок.
2. Использовать свежезапущенный проект хуёкер: https://huecker.io/
3. Закешировать нужные для сборок базовые образы у себя в экосистеме и либо переписать докерфайлы, чтобы они тянули с ваших хранилищ, либо понадеятся на кеширование самого докера.

UPD. Я бы пока не стал пользоваться хуёкером, ибо все мы помним SDEK. А вот зеркалом Гугла (mirror.gcr.io)- вполне.