👩‍💻 PostgreSQL - СОВЕТЫ ПО ЭФФЕКТИВНОЙ РАБОТЕ.
ЧАСТЬ 1.

PostgreSQL - в настоящая время одна из самых популярных СУБД на рынке. Все компании и разработчики любят Posgtres за его надежность, производительность, поддержку ACID транзакций и многое другое. Я бы сказал что PostgreSQL - это швейцарский нож в кармане любого уважающего себя backend-разработчика.

PostgreSQL - тот инструмент, который легко внедрить и использовать в production решениях. Но с ростом проекта и нагрузок на первый взгляд может показаться, что производительности PostgreSQL уже не хватает. На самом деле это не всегда так. И вот верные способы выжать ПО МАКСИМУМ из этого прекрасного слоника:

1️⃣CONNECTION POOLER

ОБЯЗАТЕЛЬНО используйте пуллер соединений. Для чего он нужен? Когда у вас много инстансов вашего приложения, становится очень сложно контролировать количество соедиенеий к Postgres, а на каждое соединение СУБД тратит не мало ресурсов на их обслуживание. Пуллеры соединения решают эту проблемлему: они становятся прокси серверами между вашим приложением и БД и контролируют заданное число соединений, да еще и утилизируют из по максимум. github.com/yandex/odyssey - один из самых лучших пуллеров соедиеней на сегодняшний день.

2️⃣НИКАКОЙ БИЗНЕС ЛОГИКИ В БД

Откажитесь от триггеров, хранимых процедур, внешних ключей, лишних и жестких сonstraint-ов, которые лишний раз валидируют то, что должно валидировать ваше приложение! В 2024 году ваше приложение должно заботиться о валидности и консистетности данных. БД - просто инструмент для хранения и получения данных. Помните: приложение масштабировать (скейлить) сильно проще, чем вычислительные ресурсы БД.

3️⃣ИЗБЕГАЙТЕ ШИРОКИХ ТАБЛИЦ

Если в вашей таблице 40+ колонок, вы что-то явно делаете не так. Дело все в том, что Postgres хранит записи таблицы в файлах по строчно друг за другом, и когда вы делаете обновление строк, на самом деле это запись новой версии строки, и, если обновляете 2-3 поля, остальные ваши поля кочуют баластом. PostgreSQL на много лучше управляет относительно небольшими строками, а если они еще и фиксированной длинны, тогда место на дисках и в кеше экономится значительно больше. Также лучше все колонки переменной длинны располагать в конце таблицы.

4️⃣ИЗБЕГАЙТЕ ТАБЛИЦ С ГИГАНТСКИМ КОЛИЧЕСТВОМ СТРОЧЕК

Тут все просто - чем больше записей в таблице - тем больше размер индекса. Чем больше размер индекса - тем больше файлов индекса требуется прочитать БД. Если индекс весит несколько гигабайт, он не умещается в оперативной памяти Postgres и тогда происходит уже чтение с диска, а это довольно медленная операция. Но как быть если записей и правда много и нам все их надо хранить? Ответ кроется в следующем пункте.