NodeJS Back-end Инженер

NodeJS Back-end Инженер

Роадмап навыков для прокачки

В чём разница между вертикальным и горизонтальным масштабированием баз данных?

Databases → Database deployment → default

Основная идея

Масштабирование баз данных — способ увеличить производительность и ёмкость системы при росте нагрузки. Существует два фундаментальных подхода: вертикальное (scale up) — увеличение мощности одного сервера, и горизонтальное (scale out) — добавление новых серверов в кластер.

Ключевые аспекты

  • Вертикальное масштабирование — добавление CPU, RAM, SSD на существующий сервер
  • Горизонтальное масштабирование — распределение данных по нескольким серверам
  • Sharding — разбиение данных на части (шарды) между серверами
  • Replication — копирование данных между серверами для отказоустойчивости
  • Read replicas — реплики только для чтения

Сравнение подходов

АспектВертикальноеГоризонтальное
СложностьПростоеСложное
ЛимитОграничен hardwareПрактически безлимитно
DowntimeЧасто требуетсяМинимальный
СтоимостьДорогое железоМного дешёвых серверов

Частые ошибки на собеседованиях

  • Не знают про потолок вертикального масштабирования
  • Путают sharding и replication
  • Забывают, что горизонтальное масштабирование усложняет JOIN-ы и транзакции
  • Не понимают CAP-теорему при горизонтальном масштабировании

Введение и проблематика

При росте проекта база данных становится узким местом: запросы замедляются, место на диске заканчивается, соединения исчерпываются. Масштабирование — это способ адаптировать инфраструктуру базы данных к возрастающей нагрузке.

Понимание масштабирования критично для backend-разработчика, потому что неправильный выбор стратегии может привести к дорогостоящим переделкам архитектуры в будущем.

Когда возникает потребность в масштабировании?

  • Время отклика запросов увеличивается
  • CPU или память сервера постоянно загружены на 80%+
  • Дисковое пространство заканчивается
  • Количество одновременных соединений достигает лимита

Базовая теория

Вертикальное масштабирование (Scale Up)

Вертикальное масштабирование — это увеличение мощности существующего сервера: добавление процессоров, оперативной памяти, замена HDD на SSD, увеличение дискового пространства.

graph LR subgraph "До" A[Server<br/>4 CPU, 16GB RAM] end subgraph "После" B[Server<br/>16 CPU, 64GB RAM] end A -->|Scale Up| B

Пример в облаке:

text
AWS RDS: db.t3.medium → db.r5.2xlarge
- vCPU: 2 → 8
- RAM: 4GB → 64GB
- Network: до 10 Gbps

Горизонтальное масштабирование (Scale Out)

Горизонтальное масштабирование — это добавление новых серверов и распределение нагрузки между ними.

graph TB subgraph "До" A[Один сервер БД] end subgraph "После" B[Сервер 1] C[Сервер 2] D[Сервер 3] E[Сервер 4] end A -->|Scale Out| B A -->|Scale Out| C A -->|Scale Out| D A -->|Scale Out| E

Методы горизонтального масштабирования

Репликация (Replication)

Копирование данных с master-сервера на slave-серверы. Все серверы содержат одинаковые данные.

  • Master-Slave: запись на master, чтение с любого
  • Master-Master: запись и чтение с любого (сложнее в управлении)
graph TB App[Приложение] M[Master<br/>Запись + Чтение] S1[Slave 1<br/>Только чтение] S2[Slave 2<br/>Только чтение] App -->|Write| M App -->|Read| S1 App -->|Read| S2 M -->|Sync| S1 M -->|Sync| S2

Сравнение подходов

КритерийВертикальноеГоризонтальное
Сложность реализацииПростое (увеличить ресурсы)Сложное (архитектурные изменения)
ПотолокОграничен hardwareПрактически неограничен
DowntimeЧасто требуется перезагрузкаМинимальный (rolling updates)
СтоимостьДорогое железоМного дешёвых серверов
ConsistencyЛегко обеспечитьСложнее (CAP-теорема)
JOIN и транзакцииРаботают нативноТребуют distributed transactions
FailoverSingle point of failureАвтоматический failover

Пограничные кейсы

⚠️

Replication lag: При чтении с реплики данные могут быть устаревшими. Для критичных операций (например, проверка баланса после пополнения) читайте с master.

⚠️

Cross-shard queries: Если данные распределены по шардам, JOIN между таблицами на разных шардах становится очень дорогим или невозможным.

Когда какой подход выбрать?

text
Вертикальное масштабирование:
✅ Небольшой/средний проект
✅ Нужна простота
✅ Текущая нагрузка не критична
✅ Бюджет позволяет мощный сервер

Горизонтальное масштабирование:
✅ Highload проект (миллионы запросов)
✅ Большой объём данных (терабайты)
✅ Нужна высокая доступность
✅ Географическое распределение пользователей

Практические примеры

AWS RDS — вертикальное масштабирование

bash
# Изменение класса инстанса (вертикальное масштабирование)
aws rds modify-db-instance \
  --db-instance-identifier mydb \
  --db-instance-class db.r5.2xlarge \
  --apply-immediately

MongoDB — горизонтальное масштабирование (sharding)

javascript
// Включение шардирования коллекции
sh.enableSharding("mydb")
sh.shardCollection("mydb.users", { "country": "hashed" })
 
// Теперь данные автоматически распределяются по шардам
// на основе хэша поля country

Вопросы интервьюера

Q: Что выбрать для стартапа — вертикальное или горизонтальное?

Начинайте с вертикального — проще и дешевле на старте. Горизонтальное масштабирование внедряйте, когда вертикальное достигнет потолка или станет экономически невыгодным.

Q: Можно ли сочетать оба подхода?

Да, это типичный паттерн. Например: вертикальное для master + горизонтальное (read replicas) для чтения.

Q: Что такое CAP-теорема и как она связана с масштабированием?

CAP: Consistency, Availability, Partition tolerance — можно обеспечить только 2 из 3. При горизонтальном масштабировании приходится выбирать между строгой консистентностью и доступностью.

Q: Как обеспечить транзакции при шардировании?

Distributed transactions (2PC), Saga pattern, или проектировать схему так, чтобы связанные данные были на одном шарде.

Источники