Как выбираешь СУБД на новом проекте?

Выбор СУБД на новом проекте

Это один из важнейших архитектурных решений, потому что изменить БД потом очень дорого. За 10+ лет я менял СУБД в production только один раз (был болезненный процесс). Поэтому выбираю осторожно и обоснованно.

Шаг 1: Определяю характер данных

Все начинается с вопроса: какие данные будут храниться?

// Вопросы
1. Структурированные данные (users, orders)?
   → SQL база

2. Гибкая схема (CMS, пользовательские поля)?
   → NoSQL (MongoDB, Firestore)

3. Графические данные (социальная сеть, рекомендации)?
   → Graph database (Neo4j)

4. Time-series данные (метрики, логи)?
   → InfluxDB, TimescaleDB, Prometheus

5. Поиск по текстам?
   → Elasticsearch, MeiliSearch

6. Кэш и сессии?
   → Redis, Memcached

Шаг 2: Анализирую требования к масштабируемости

// Read/Write patterns
const requirements = {
  // Сколько RPS (requests per second)?
  rps: 1000,
  
  // Сколько данных?
  dataSize: '500GB',
  
  // Ratio read:write?
  writeHeavy: false, // true для IoT, sensors
  readHeavy: true,   // true для большинства SaaS
  
  // Нужна ли транзакция?
  transactions: true,
  
  // Нужна ли high availability?
  ha: true,
  
  // Нужна ли geo-distribution?
  geo: false,
};

Примеры:

// SaaS приложение (Slack, Notion, Figma)
- Много read, мало write
- Транзакции нужны
- Strong consistency важна
→ PostgreSQL или MySQL

// Real-time социальная сеть (Twitter, TikTok)
- Огромный volume write
- Denormalized read
- Eventually consistent OK
→ Cassandra или DynamoDB

// Logging/Monitoring system
- Extreme write volume
- Aggregated read
→ InfluxDB, Elasticsearch

Шаг 3: Мой decision tree

┌─ Структурированные данные? ──┬─ Нужна strong consistency?
│                              │
│                          Yes ─→ PostgreSQL (мой выбор по умолчанию)
│                          No  ─→ MongoDB
│
No─ Текстовый поиск?
   ├─ Yes → Elasticsearch
   ├─ Time-series? → TimescaleDB
   └─ Graph? → Neo4j

По умолчанию: PostgreSQL

Я всегда начинаю с PostgreSQL и меняю только если у меня есть хорошая причина.

Почему PostgreSQL?

✅ ACID транзакции — данные консистентны
✅ Мощный SQL — complex queries
✅ JSON support — JSONB для гибкости
✅ Full-text search — встроенный
✅ Масштабируемость до 100TB+
✅ Надёжная репликация
✅ Миллионы production deployment'ов
✅ Open source — можно читать исходный код
✅ VACUUM, ANALYZE — инструменты для оптимизации

❌ Недостатки
❌ Horizontal sharding сложный (не like MongoDB)
❌ Для extreme write volume (>100k RPS) нужна оптимизация

Архитектура с PostgreSQL:

┌─────────────────┐
│  Application    │
└────────┬────────┘
         │
      ┌──▼──┐  ┌────────┐
      │ ORM │──┤ PostgreSQL ├─────┬─────────┐
      └──┬──┘  └────────┘       │         │
         │                   Replica Standby
         │
    ┌────▼────┐
    │  Redis  │ (кэш, session)
    └─────────┘

Когда выбираю MongoDB

Часто слышу: "MongoDB за гибкость". Но я выбираю её по другим причинам:

✅ Выбираю MongoDB когда

1. Гибкая схема (каждый документ может быть разным)
   Пример: CMS, конфигурационное хранилище
   
2. Большой объём документов разных типов
   Пример: User Profile + Order + Review — разные структуры
   
3. Нужна горизонтальная шардинг из коробки
   MongoDB sharding проще, чем PostgreSQL
   
4. Денормализованные данные (data duplication OK)
   Пример: embedding comments в post document

❌ НЕ выбираю MongoDB для

1. «Потому что NoSQL крутой»
2. «Потому что все берут MongoDB»
3. Если нужны сложные транзакции
   (MongoDB транзакции есть, но сложнее)
4. Если данные имеют много связей
   (use PostgreSQL foreign keys вместо)

Типичный ошибки с MongoDB:

// ❌ Плохо: денормализация приводит к inconsistency
db.users.insertOne({
  _id: ObjectId(),
  name: 'John',
  address: { city: 'NYC' }
});

db.orders.insertOne({
  userId: ObjectId(...),
  userCity: 'NYC',  // Дублирование!
  // Если пользователь переедет — нужно обновить оба места
});

// ✅ Хорошо: используй references, как в SQL
db.orders.updateMany(
  { userId: user_id },
  { $set: { userCity: 'LA' } }
);
// Или используй PostgreSQL и избежи проблемы

Когда выбираю Elasticsearch

// Elasticsearch НЕ является главной БД
// Это индекс поверх других данных

// Архитектура
PostgreSQL (source of truth)
   ↓
   Elasticsearch (index for fast search)
   ↓
User search query

// Event-driven sync
db.onUpdate(user => {
  elasticsearch.index({
    id: user.id,
    name: user.name,
    email: user.email,
    // Все поля для поиска
  });
});

Когда нужен Elasticsearch:

• Full-text поиск (с fuzzy, typo tolerance)
• Поиск по множеству полей одновременно
• Аналитика по логам
• Автодополнение

Когда выбираю Redis

// Redis НИКОГДА не главная БД
// Это кэш и session store

const architecture = {
  primaryDB: 'PostgreSQL',  // source of truth
  cache: 'Redis',           // speed up reads
  session: 'Redis',         // fast session access
  queue: 'Redis',           // job processing
};

// Типичный паттерн: Cache-Aside
async function getUser(userId) {
  // Попытка из кэша
  let user = await redis.get(`user:${userId}`);
  if (user) return JSON.parse(user);
  
  // Если нет в кэше — fetch from DB
  user = await db.query('SELECT * FROM users WHERE id = ?', [userId]);
  
  // Положи в кэш
  await redis.setex(`user:${userId}`, 3600, JSON.stringify(user));
  
  return user;
}

Мой decision matrix (реальные проекты)

┌──────────────────────┬──────────────┬──────────────┬──────────────┐
│ Тип проекта          │ БД           │ Cache        │ Search       │
├──────────────────────┼──────────────┼──────────────┼──────────────┤
│ SaaS (Notion)        │ PostgreSQL   │ Redis        │ PostgreSQL   │
│ E-commerce           │ PostgreSQL   │ Redis        │ Elasticsearch│
│ Social network       │ PostgreSQL   │ Redis        │ Elasticsearch│
│ CMS                  │ MongoDB      │ Redis        │ Elasticsearch│
│ Real-time chat       │ PostgreSQL   │ Redis        │ -            │
│ Analytics/Dashboard  │ ClickHouse   │ Redis        │ -            │
│ IoT sensors          │ TimescaleDB  │ Redis        │ -            │
│ Mobile backend       │ MongoDB      │ Redis        │ MongoDB      │
└──────────────────────┴──────────────┴──────────────┴──────────────┘

Практический пример: Ecommerce platform

// Требования
1. Управление товарами (структурированные)
2. Поиск по товарам (полнотекстовый)
3. Высокая нагрузка на чтение (много покупателей)
4. Заказы с транзакциями
5. Сессии пользователей

// Выбор
const stack = {
  primary: 'PostgreSQL',    // products, orders, users
  search: 'Elasticsearch',  // full-text search по товарам
  cache: 'Redis',           // горячие товары, сессии
  analytics: 'TimescaleDB', // события (views, clicks)
};

// Синхронизация
db.onProductUpdate(product => {
  elasticsearch.index(product);
  redis.del(`product:${product.id}`);
});

Что я проверяю перед выбором

// Контрольный список
☑ Масштабируемость: может ли БД расти с нашим приложением?
☑ Надёжность: есть ли встроенная репликация?
☑ Бэкапы: как восстанавливаются при сбое?
☑ Мониторинг: какие метрики я буду отслеживать?
☑ Операционная сложность: сколько DevOps нужно?
☑ Лицензия: есть ли лицензионные ограничения?
☑ Community: активное сообщество для помощи?
☑ Migration path: как изменить в будущем, если нужно?

Вывод

Выбор БД — это trade-off между масштабируемостью, надёжностью и сложностью. Я:

1. Начинаю с PostgreSQL (подходит 90% случаев)
2. Добавляю Redis для кэша (всегда помогает)
3. Добавляю Elasticsearch для поиска (если нужен)
4. Выбираю MongoDB только если SQL не подходит по архитектуре
5. Документирую решение (ADR — Architecture Decision Record)

Главное — выбрать один раз, выбрать хорошо. Потом работать с выбранной БД отлично, а не менять каждые два года.