Базы данных (Data Base)

🎯 Типы баз данных — кратко и по делу Выбирая базу данных для проекта, важно понимать их ключевые особенности. Ниже — наглядная классификация: 🔷 Реляционные (Relational) Классика: таблицы со строгими схемами и связями. 📌 ACID, SQL, целостность данных 📌 Идеальны для: финансов, e-commerce, CRM, ERP, банков и инвентаризации 🔷 Документные (Document) Гибкие NoSQL-базы на основе JSON-документов 📌 Горизонтальное масштабирование, вложенные структуры 📌 Подходят для: CMS, каталогов, мобильных и веб-приложений 🔷 In-Memory Хранят данные в оперативной памяти — максимум скорости 📌 Используются как кэш, для сессий, real-time аналитики 📌 Примеры: Redis, Memcached 🔷 Графовые (Graph) Работают с узлами и связями — мощные запросы по связности 📌 Идеальны для соцсетей, рекомендаций, мошеннических схем 📌 Пример: Neo4j 🔷 Временные (Time-Series) Оптимизированы под работу с временными метками 📌 Подходят для метрик, IoT, логов, финансовых данных 📌 Примеры: InfluxDB, TimescaleDB 🔷 Пространственные (Spatial) Работают с геоданными и координатами 📌 Используются в GIS, логистике, экологии, городском планировании 🔷 Колончатые (Columnar) Хранят данные по колонкам — супер для аналитики 📌 Быстрые агрегации, параллельная обработка 📌 Используются в BI, отчетах, хранилищах данных 📌 Пример: ClickHouse 🔷 Ключ-Значение (Key-Value) Простые NoSQL-базы — пара ключ-значение 📌 Идеальны для кэшей, предпочтений, сессий 📌 Примеры: Redis, DynamoDB 🔍 Правильный выбор базы — залог производительности и масштабируемости проекта. #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

Антипаттерн: 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

NoSQL vs SQL в реальных проектах Краткий обзор SQL (реляционные СУБД): данные хранятся в таблицах со строго заданной схемой (schema-on-write). Пример: PostgreSQL, MySQL, Oracle. NoSQL (нереляционные СУБД): гибкие модели данных (документ, ключ–значение, граф, колоночные) и отсутствие жёсткой схемы (schema-on-read). Пример: MongoDB (документы), Redis (ключ–значение), Cassandra (колоночная), Neo4j (граф). ➡️Читать статью #db 👉 @database_info

📕 Сравнение индексации в PostgreSQL и ClickHouse для разработчиков, администраторов баз данных, инженеров и аналитиков данных На открытом уроке 3 июня в 20:00 мск мы обсудим различия в механизмах индексации между PostgreSQL и ClickHouse: 📗 На вебинаре разберём: 1. Основы и сравнение производительности разных подходов к индексации; 2. Для каких сценариев распространено использование этих подходов; 📘 В результате на практике разреберете и сравните подходы, производительность и архитектуру индексации PostgreSQL и ClickHouse. 👉 Регистрация и подробности о курсе ClickHouse для инженеров и архитекторов БД: https://vk.cc/cMuQbb Все участники открытого урока получат скидку на курс "ClickHouse для инженеров и архитекторов БД" Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Базы данных. Школа бэкенд-разработки 2025 На лекции обсудим основные понятия и принципы работы с базами данных. Рассмотрим факторы, влияющие на выбор подходящей базы данных для конкретной задачи. Познакомимся с индексами и их ролью в ускорении запросов. Поделимся советами по оптимальному использованию баз данных и рекомендациями для эффективной работы источник #db 👉 @database_info

Почему индекс в PostgreSQL не всегда спасает Индексы - мощный инструмент, но не панацея. Иногда запрос с индексом работает медленнее, чем без него. Почему? 1️⃣ Маленькая выборка - да, полное сканирование - нет Если таблица маленькая (до нескольких тысяч строк), PostgreSQL может решить, что быстрее прочитать всё целиком, чем прыгать по индексу.

    
        
EXPLAIN ANALYZE
SELECT * FROM users WHERE status = 'active';
{}
    

План покажет Seq Scan, и это не баг. 2️⃣ Индекс не помогает с функциями в WHERE Запрос вида:

    
        
SELECT * FROM orders WHERE DATE(created_at) = '2025-08-12';
{}
    

не использует индекс по created_at. Решение — переписать условие:

    
        
WHERE created_at >= '2025-08-12' AND created_at < '2025-08-13'
{}
    

3️⃣ Селективность Если по условию отбирается больше ~5–10% строк, индекс становится невыгодным — чтение с диска и так почти сплошное. 4️⃣ Статистика устарела PostgreSQL выбирает план по статистике. Если она старая - план может быть неэффективным.

    
        
ANALYZE table_name;
{}
    

- и жизнь наладится. 💡 Вывод: Индекс - не магическая кнопка «ускорить». Следи за планами запросов (EXPLAIN), обновляй статистику и оптимизируй условия. Сохрани, чтобы не наступить на этот грабельный индекс 🚀 #db 👉 @database_info

Антипаттерны JOIN-ов в SQL и как их избежать JOIN - мощная штука, но может легко превратиться в генератор тормозов и дублей. Вот топ-4 ловушек: 1️⃣ Забыли условие соединения

    
        
SELECT *
FROM orders
JOIN customers;
{}
    

Без ON это картезианское произведение - каждая строка первой таблицы умножается на все строки второй. Легко получить миллионы ненужных записей. ✅ Как избежать: Всегда указывай условие соединения. 2️⃣ JOIN по неиндексированным колонкам Если соединяешь большие таблицы по полю без индекса - готовься ждать. ✅ Как избежать: Добавь индекс на ключи соединения.

    
        
CREATE INDEX idx_orders_customer_id ON orders(customer_id);
{}
    

3️⃣ Фильтры в WHERE вместо ON

    
        
-- Плохо
FROM orders
LEFT JOIN customers ON orders.customer_id = customers.id
WHERE customers.region = 'EU';
{}
    

LEFT JOIN превратился в INNER JOIN, потому что фильтр в WHERE отсекает NULL-строки. ✅ Как избежать: Фильтруй в ON, если хочешь сохранить LEFT JOIN:

    
        
LEFT JOIN customers 
  ON orders.customer_id = customers.id AND customers.region = 'EU';
{}
    

4️⃣ SELECT *** в сложных JOIN-ах Такая выборка тянет все колонки всех таблиц. Много лишних данных + риск коллизии имён колонок. ✅ Как избежать: Явно указывай нужные поля. 💡 Вывод: JOIN - как скальпель. В умелых руках ускоряет, в неумелых - режет производительность. Сохрани, чтобы не резануть базу не туда ✂️ #db 👉 @database_info

Немного юмора) #db 👉 @database_info

Конференция, на которую нужно прийти Data Engineers🔥 23 сентября пройдет Data Internals X 2025 — единственная в России конференция, где создатели СУБД и движков обработки данных делятся опытом работы с реальными production-системами экстремального масштаба. Вас ждёт по-настоящему "хардкорная" программа. 🎯 Глубина технических решений Программа конференции сфокусирована на внутренних механизмах работы с данными — от разработки СУБД до оптимизации запросов и устойчивости к высоким нагрузкам. Это редкая возможность погрузиться в технические детали, которые обычно остаются за кадром. 🏭 Практический опыт масштабирования Все доклады основаны на реальном опыте работы с петабайтными данными, высоконагруженными системами и решением production-задач в крупных компаниях (Яндекс, Сбер, VK, Т-Банк). 🔧 Импортозамещение и Open Source Особый акцент на отечественные решения и open-source технологии, что критически важно в текущих реалиях. 🧠 Концентрированный опыт Максимум пользы для повышения квалификации за один день: 20+ докладов, рекордная плотность экспертных знаний и нетворкинг с 300+ участниками. 📌Изучить расписание и забронировать билеты на сайте конференции Приходите сами и приглашайте своих коллег 🔥 До встречи 23 сентября в Москве!