Антипаттерн: N+1 запросов и как его избежать

Что такое N+1?
При выборке связанных данных ORM (или вручную) сначала делается 1 запрос за основными записями, а потом N дополнительных — по одной для каждой записи, чтобы получить связанные объекты. Например, получить 10 пользователей и для каждого — список их заказов ⇒ 1 запрос к users + 10 запросов к orders. 🚩

# SQLAlchemy-пример “N+1”:
users = session.query(User).all()              # 1 запрос
for u in users:
    print(u.orders)                            # для каждого пользователя — отдельный запрос

Почему плохо?

🔹 Высокая нагрузка на базу: запросы “в тоненькую” вместо одного “тяжелого”.
🔹 Задержки сети: множество раунд-трипов увеличивает время ответа.
🔹 Масштабируемость страдает: при росте N время растёт линейно.

Как победить N+1

1. Eager loading (предварительная загрузка)
Загрузка связей сразу вместе с основными объектами.

   # SQLAlchemy, joinedload — делает JOIN и подтягивает данные сразу
   from sqlalchemy.orm import joinedload

   users = session.query(User).options(joinedload(User.orders)).all()
   for u in users:
       print(u.orders)  # не генерирует дополнительных запросов
   

✅ Сокращает число запросов до 1.

2. Batch loading (групповые запросы)
Если JOIN приводит к дублированию полей, можно сделать два запроса:

   -- 1: получить user_id
   SELECT id FROM users WHERE active = true;
   -- 2: получить все заказы для этих пользователей
   SELECT * FROM orders WHERE user_id IN (...список id...);
   

✅ Баланс между сложностью и производительностью.

3. DataLoader / кеширование
В GraphQL и приложениях на Node.js часто используют DataLoader:

🔹 Собирает все ключи за тиковый цикл
🔹 Делает один общий запрос
🔹 Раздаёт результаты обратно

4. Правильное проектирование API
— Предусматривайте, какие связи нужны на фронтенде, и загружайте их сразу.
— Разделяйте endpoints: если нужны только пользователи без заказов — делайте лёгкий запрос.

Best practices & подводные камни

🔹 EXPLAIN ANALYZE для проверки плана: убедитесь, что JOIN-ы и IN (…) не приводят к полному сканированию таблиц.
🔹 Пагинация: всегда ограничивайте выборку через LIMIT/OFFSET или курсоры.
🔹 Будьте осторожны с joinedload на “много ко многим” — может раздувать размер результата.

Сохрани этот пост, чтобы не забыть, и поделись с коллегами!
А у тебя были случаи, когда N+1 съедал всю производительность? Как борешься?

#db

👉 @database_info

Мини-гайд по трём ключевым сущностям PostgreSQL: соединения, буфер и WAL

1. Соединения (Connections)
PostgreSQL по умолчанию позволяет одновременно до 100 соединений (max_connections).

🔹 Проблема: слишком много прямых соединений создают нагрузку на память и CPU.
🔹 Решение: используйте пуллинг через PgBouncer или Pgpool-II.

  [databases]
  mydb = host=127.0.0.1 port=5432 dbname=mydb

  [pgbouncer]
  listen_addr = 0.0.0.0
  listen_port = 6432
  pool_mode = transaction
  max_client_conn = 500
  default_pool_size = 20
  

🔹 Совет: на проде стремитесь держать max_connections < 200 и масштабируйте через пуллер.


2. Буфер (Shared Buffers & Work Mem)
PostgreSQL активно использует память для кэширования страниц и сортировок.

🔹 shared_buffers – основной буфер кэша:

  shared_buffers = 4GB        # ≈25% от RAM на выделенном сервере
  

🔹 work_mem – память на сортировку/слияние одного потока:

  work_mem = 64MB             # для сложных запросов с сортировками и хэш-джоинами
  maintenance_work_mem = 512MB # для VACUUM/CREATE INDEX
  

🔹 Best practice:

🔹 Установите shared_buffers ≈ 25% RAM.
🔹 Настройте work_mem исходя из числа параллельных операций, не превышайте общий объём памяти.



3. WAL (Write-Ahead Log)
WAL обеспечивает надёжность и репликацию.

🔹 wal_level – детальность логирования:

  wal_level = replica       # для потоковой репликации
  

🔹 checkpoint_timeout и max_wal_size:

  checkpoint_timeout = 10min
  max_wal_size = 1GB
  

🔹 Архивация WAL для резервных копий:

  archive_mode = on
  archive_command = 'cp %p /mnt/backup/wal/%f'
  

🔹 Рекомендации:

🔹 Увеличьте max_wal_size, если у вас большие всплески нагрузки.
🔹 Настройте сжатие WAL (pg_wal) для экономии места.



💡 Сохрани, чтобы не забыть!
А как вы оптимизируете соединения, буфер и WAL в своих проектах?

#db

👉 @database_info