Базы данных
Polyglot Persistence
Netflix обслуживает 260 миллионов подписчиков с 8 разными БД: MySQL для billing, Cassandra для viewing history, DynamoDB для metadata, Redis для session, Elasticsearch для search, S3 для media. Каждая БД - лучший инструмент для своей задачи. Но Netflix имеет 10,000+ инженеров для этого стека. У стартапа из 4 человек другой ответ.
- **Uber**: MySQL + Redis + Cassandra + Elasticsearch + ClickHouse - каждый сервис имеет свою специализированную БД
- **Stack Overflow**: SQL Server + Redis на 50M пользователей - доказательство что простой стек может масштабироваться
- **Shopify**: MySQL + Redis + Elasticsearch с Kafka для синхронизации - outbox pattern для надёжной репликации данных
Polyglot Persistence: один размер не подходит всем
Polyglot persistence - использование нескольких специализированных баз данных в одной системе. Термин ввёл Martin Fowler в 2011. Идея: разные типы данных имеют разные требования к хранению, поиску и масштабированию. Одна PostgreSQL не может быть одновременно лучшей для транзакций, полнотекстового поиска, кеша, графовых запросов и аналитики.
Uber production stack в 2023: MySQL (trips, users), Redis (dispatch, caching), Cassandra (GPS history, activity), Elasticsearch (search), ClickHouse (analytics), Docstore (document storage на MySQL). Каждая БД решает задачу в которой она лучшая - это polyglot persistence в промышленном масштабе.
Компания хранит данные в PostgreSQL и добавляет Redis для кеширования. Это polyglot persistence?
Decision Matrix: как выбрать БД
Выбор БД определяется несколькими ключевыми вопросами: структура данных (схема vs schema-free), тип запросов (точечный vs аналитика), масштаб (тысячи vs миллиарды), consistency требования (ACID vs eventual), read/write ratio, и нужен ли full-text поиск или граф-обходы.
Stack Overflow в 2023 году работает на Microsoft SQL Server для всей основной логики + Redis для кеша. Команда из 5 разработчиков обслуживает 50M+ активных пользователей в месяц. Принцип: не усложнять без необходимости - одна хорошо настроенная SQL БД лучше пяти плохо интегрированных.
Какой тип данных требует граф-ориентированной базы данных (Neo4j) а не реляционной?
Синхронизация данных между БД
Главная проблема polyglot persistence - consistency между разными БД. Если продукт обновился в PostgreSQL, Elasticsearch должен знать об изменении. Паттерны синхронизации: dual writes (писать в обе), CDC (Change Data Capture через WAL/binlog), event streaming через Kafka, или outbox pattern.
LinkedIn использует Kafka как центральный hub для синхронизации данных между 30+ сервисами и БД. Debezium (Red Hat) - популярный open source CDC коннектор для PostgreSQL, MySQL, MongoDB -> Kafka. Shopify использует outbox pattern для синхронизации основной MySQL с Elasticsearch для поиска по товарам.
Почему dual write (писать одновременно в PostgreSQL и Elasticsearch) ненадёжен?
Операционная сложность polyglot систем
Каждая БД в polyglot стеке - это отдельная операционная забота: мониторинг, backup, масштабирование, обновление версий, обучение команды. Добавление новой БД - это не только техническое решение, но и организационное. Команда из 3 человек не может хорошо поддерживать 7 разных БД.
Instagram в 2012 году (13 человек, 30M пользователей): PostgreSQL + Redis + Solr. Простой стек позволял маленькой команде поддерживать систему без перегрузки. Facebook купил их именно с этой командой и стеком - не потому что он идеален, а потому что команда его хорошо знала.
Polyglot persistence - всегда лучший подход, нужно использовать специализированную БД для каждого типа данных
Polyglot добавляет значительную операционную сложность - добавлять новую БД только когда PostgreSQL реально не справляется с конкретной задачей
Преждевременная оптимизация через polyglot создаёт fragmented data, проблемы синхронизации, и операционный overhead. Stack Overflow обслуживает 50M пользователей на SQL Server + Redis. Начинать с минимально сложного стека и добавлять специализацию только при реальной необходимости.
Команда из 4 разработчиков рассматривает добавление Neo4j для социальных связей (5% запросов). Стоит ли добавлять?
Итоги
- **Специализация** - каждая БД оптимизирована для своего use case: Redis для кеша, Elasticsearch для поиска, ClickHouse для аналитики
- **Синхронизация** - outbox pattern или CDC (Debezium) надёжнее dual write: атомарность внутри одной БД, eventual consistency между ними
- **Операционная стоимость** - каждая новая БД = мониторинг, backup, scaling, обучение; добавлять только когда польза превышает затраты
Связанные темы
Polyglot persistence объединяет технологии из всего курса баз данных:
- Redis структуры данных — Redis - самый частый компаньон PostgreSQL в polyglot stack: кеш, session, rate limiting, pub/sub
- Elasticsearch и полнотекстовый поиск — Elasticsearch добавляется поверх реляционной БД для full-text search и faceted navigation
- Мониторинг БД — Каждая БД в polyglot стеке требует отдельного мониторинга метрик и алертов
Вопросы для размышления
- Startup использует PostgreSQL + Redis + Elasticsearch + MongoDB + ClickHouse. Команда 3 человека. Какие БД кандидаты на удаление и как провести consolidation без downtime?
- Outbox pattern гарантирует at-least-once delivery в Kafka. Как consumer должен обработать дубликаты событий из outbox?
- Выбор между synchronous dual write и asynchronous CDC через Kafka: в каких сценариях приемлема задержка синхронизации (eventual consistency), а в каких - нет?