Перейти к содержимому

Введение

Базы данных — сердце любого современного приложения. Здесь хранятся данные, здесь происходит магия CRUD, транзакций и масштабирования.

graph TB
A[Databases] --> B[SQL: PostgreSQL]
A --> C[NoSQL: MongoDB]
A --> D[In-Memory: Redis]
A --> E[Design & Optimization]
B --> B1[Индексы]
B --> B2[Триггеры & Views]
B --> B3[JSON & Full-Text]
B --> B4[Партицирование]
C --> C1[Aggregation Pipeline]
C --> C2[Sharding & Replica Sets]
C --> C3[Schema Design]
D --> D1[Cache Strategies]
D --> D2[Pub/Sub & Streams]
E --> E1[Нормализация]
E --> E2[Query Optimization]
E --> E3[Transactions & ACID]
E --> E4[ORMs & Migrations]
style A fill:#3b82f6,stroke:#1e40af,color:#fff
style B fill:#10b981,stroke:#059669,color:#fff
style C fill:#8b5cf6,stroke:#6d28d9,color:#fff
style D fill:#ef4444,stroke:#dc2626,color:#fff
style E fill:#f59e0b,stroke:#d97706,color:#fff

Самая мощная open-source реляционная БД. От базовых запросов до advanced фич:

  • Индексы: B-tree, Hash, GIN, GiST — когда и что использовать
  • Триггеры: Автоматизация бизнес-логики на уровне БД
  • Views & Materialized Views: Виртуальные таблицы и кеширование запросов
  • Оконные функции: ROW_NUMBER(), LAG(), LEAD() — аналитика прямо в SQL
  • JSON/JSONB: Гибридные документы в реляционной БД
  • Full-Text Search: Поиск без Elasticsearch
  • Партицирование: Разделение больших таблиц для скорости

Документо-ориентированная NoSQL БД. Когда схема гибкая, а данные — неструктурированные:

  • Aggregation Pipeline: MapReduce на стероидах
  • Индексы: Как индексировать вложенные документы и массивы
  • Sharding: Горизонтальное масштабирование на сотни серверов
  • Replica Sets: Отказоустойчивость через репликацию
  • Транзакции: Да, в MongoDB тоже есть ACID!
  • Schema Design Patterns: Bucket, Outlier, Computed — когда какой паттерн применять

In-memory key-value store. Когда нужна сверх-скорость:

  • Структуры данных: Strings, Lists, Sets, Sorted Sets, Hashes, HyperLogLog
  • Cache Strategies: Write-through, Write-behind, Cache-aside
  • Sessions: Хранение сессий без нагрузки на основную БД
  • Pub/Sub: Real-time сообщения между сервисами
  • Streams: Event sourcing и message queues

Теория и практика проектирования схем:

  • Нормализация: 1NF, 2NF, 3NF — избавляемся от дубликатов
  • Relationships: One-to-One, One-to-Many, Many-to-Many
  • Денормализация: Когда нарушение правил — правильное решение
  • Query Optimization: EXPLAIN, индексы, covering indexes
  • Transactions & ACID: Atomicity, Consistency, Isolation, Durability

Работа с БД через код:

  • Prisma: Type-safe ORM для TypeScript/JavaScript
  • TypeORM vs Mongoose: SQL ORM vs MongoDB ODM
  • Schema Evolution: Как эволюционировать схему без даунтайма
  • Zero-Downtime Migrations: Blue-green deployments, rolling updates

flowchart LR
A[Приложение] -->|Читает| B[(Database)]
A -->|Пишет| B
B -->|Быстро| C[Redis Cache]
B -->|Поиск| D[Full-Text Index]
B -->|Аналитика| E[Aggregation]
B -->|Репликация| F[Backup DB]
style A fill:#3b82f6,stroke:#1e40af,color:#fff
style B fill:#10b981,stroke:#059669,color:#fff
style C fill:#ef4444,stroke:#dc2626,color:#fff
style D fill:#f59e0b,stroke:#d97706,color:#fff
style E fill:#8b5cf6,stroke:#6d28d9,color:#fff
style F fill:#6b7280,stroke:#374151,color:#fff

Не существует “идеальной” БД. Есть правильный выбор под конкретную задачу:

  • PostgreSQL: Когда нужны отношения, транзакции, ACID
  • MongoDB: Когда схема меняется часто, данные неструктурированные
  • Redis: Когда критична скорость, данные временные

Масштабирование:

  • Вертикальное: Больше CPU/RAM на одном сервере (PostgreSQL любит это)
  • Горизонтальное: Больше серверов (MongoDB sharding, PostgreSQL Citus)

Оптимизация:

  1. Сначала правильная схема (нормализация/денормализация)
  2. Потом индексы (но не все подряд!)
  3. Потом кеш (Redis)
  4. И только потом — переписывание запросов

Это не просто “как создать таблицу”. Это глубокое погружение в Data Engineering: от теории до production-ready решений.

Следующий урок: PostgreSQL: Основы