System Design
Основы баз данных
Цели урока
- Понять когда использовать SQL vs NoSQL
- Изучить ACID и BASE модели
- Разобраться в типах NoSQL баз
- Освоить репликацию и шардинг
- Научиться выбирать базу данных под задачу
Предварительные знания
- Основы масштабирования (предыдущий урок)
- CAP теорема
2007 год. Amazon публикует статью о Dynamo - внутренней key-value базе данных. Проблема: корзина покупок должна быть доступна даже если несколько датацентров недоступны. SQL с ACID-транзакциями не мог обеспечить такую доступность без жертвы производительностью. Dynamo выбрал availability и eventual consistency. Статья запустила волну NoSQL движения и изменила то, как индустрия думает о хранении данных: не 'лучшая база данных', а 'правильная база для конкретной задачи'.
- **Discord** хранит триллионы сообщений в Cassandra (затем ScyllaDB) - time-series pattern с высоким write throughput
- **Instagram** использует PostgreSQL для пользователей и постов, Redis для кеша лент - классический polyglot persistence
- **Stripe** обрабатывает платёжные транзакции в PostgreSQL с ACID - финансовые данные требуют strong consistency
Werner Vogels и NoSQL революция Amazon
Статья 'Dynamo: Amazon's Highly Available Key-value Store' (SOSP 2007) стала манифестом NoSQL. Проблема: при пиковой нагрузке (Black Friday) Amazon не мог позволить себе ни секунды недоступности корзины покупок. Реляционные БД не могли обеспечить нужную availability при распределении по датацентрам. Команда под руководством Giuseppe DeCandia разработала систему с eventual consistency и tunable consistency levels. Stateless сервисы + Dynamo-style persistence стали blueprint для современных микросервисов. Werner Vogels (CTO Amazon) популяризировал концепцию 'you build it, you run it' и polyglot persistence.
SQL базы данных
**SQL (Relational) базы данных** - классический подход к хранению структурированных данных. Данные организованы в таблицы со связями между ними.
PostgreSQL, MySQL, Oracle, SQL Server - все используют **реляционную модель**: таблицы, колонки, строки, связи через foreign keys.
**ACID - фундамент надёжности:**
PostgreSQL - универсальный выбор для большинства проектов. Поддерживает JSON, full-text search, geo queries. Начинать с PostgreSQL, мигрировать на NoSQL когда появятся конкретные проблемы с масштабом.
Какую проблему решает Atomicity в ACID?
NoSQL базы данных
**NoSQL** - общее название для баз данных, которые не используют реляционную модель. «Not Only SQL» - это не замена SQL, а альтернатива для специфических задач.
NoSQL появился как ответ на ограничения SQL при работе с большими данными и высокими нагрузками. Google (Bigtable), Amazon (DynamoDB), Facebook (Cassandra) - все создали свои NoSQL решения.
NoSQL не лучше SQL - это другой инструмент. «Когда в руках молоток, всё кажется гвоздём». Выбирать инструмент под задачу, не под хайп.
Почему NoSQL легче масштабировать горизонтально?
Типы NoSQL баз
Не существует «просто NoSQL». Есть разные типы, каждый оптимизирован под свои задачи.
Какой тип NoSQL лучше всего подходит для хранения сессий пользователей?
Репликация и Шардинг
**Репликация** и **Шардинг** - два основных паттерна масштабирования баз данных. Они решают разные проблемы и часто используются вместе.
Золотое правило: Replication для read-heavy, Sharding для write-heavy или большого объёма данных. Часто используют оба: sharded cluster с репликами каждого shard.
База данных имеет 10TB данных и 100K writes/sec. Какой паттерн поможет?
Выбор базы данных
На System Design интервью часто спрашивают: «Какую базу выберете?». Важен не ответ, а **обоснование** через требования.
На интервью: «Начать с PostgreSQL для основных данных и Redis для кеша. Если нагрузка вырастет до X - рассмотрю Y. Вот почему...» Показывать эволюцию, не финальное состояние.
Проектирование системы логирования с 1M events/sec. Какая БД подойдёт лучше?
Ключевые идеи
- **SQL (PostgreSQL, MySQL)**: ACID транзакции, схема, JOINs - для структурированных данных с гарантиями целостности
- **NoSQL типы**: Document (MongoDB) для гибкой схемы, Key-Value (Redis) для кеша и сессий, Wide-Column (Cassandra) для time-series, Graph (Neo4j) для связей
- **Replication** для read scaling и redundancy, **Sharding** для write scaling и больших объёмов - часто используются вместе
- **Polyglot persistence**: production системы используют несколько БД - PostgreSQL + Redis + Elasticsearch - каждая под свою задачу
Вопросы для размышления
- Стартап проектирует Instagram-like приложение. На старте выбирают одну PostgreSQL. При каком масштабе (MAU, QPS, объём медиа) каждый из компонентов потребует замены или дополнения? Какую архитектуру БД предложить для 10M MAU?