Выбор типа базы данных определяет, насколько удобно будет хранить данные, масштабировать систему и выполнять запросы. Ниже — основные виды и критерии выбора.

Реляционные базы данных

Данные в таблицах; строки — записи, столбцы — атрибуты. Таблицы связаны отношениями через ключи (например, user_id). Строгая типизация, поддержка связей «один ко многим» и «многие ко многим», транзакции, язык SQL.

Пример: заказы в сервисе такси — таблица orders с полями order_id, user_id, driver_id, status; связь с users через user_id.

Когда использовать: транзакционность и сложные связи (финансы, заказы). Покрывают 80–90% задач.

Документо-ориентированные

Основной элемент — документ (JSON/BSON). Гибкая схема: у разных документов могут быть разные поля. Нет SQL, связи и джойны неудобны и дороги.

Пример: профиль пользователя с полями user_id, name, interests (массив), career (вложенный объект). Удобно при часто меняющейся структуре.

Поисковые движки (Elasticsearch, Sphinx) — специализация для полнотекстового поиска (лемматизация, синонимы). Рекомендуется хранить основные данные в другой БД (например, PostgreSQL), а поисковик использовать для поиска.

Графовые базы данных

Хранение графов: вершины (сущности) и рёбра (связи). Оптимизированы для обхода связей и поиска путей (Neo4j).

Пример: соцсеть — «дружит с», «живёт в»; маршрутизация — вершины перекрёстки, рёбра дороги.

Когда использовать: много связей (соцсети, рекомендации, маршруты). Реляционные БД могут эмулировать графы, но графовые быстрее для таких задач.

Key-Value

Простейшая модель: ключ — значение. Аналог хеш-таблицы. Часто используются как кэш (Redis, Memcached) или для конфигураций и метаданных (etcd — сервис-дискавери, конфиги кластера).

Пример: ключ video_id:123, значение views:1500; ключ driver_id:456, значение status:available.

В Redis для удаления ключей по префиксу используют SCAN (не KEYS), затем DEL — SCAN не блокирует сервер на больших наборах.

Колоночные базы данных

Данные хранятся по колонкам, а не по строкам (ClickHouse). Сильное сжатие, чтение только нужных колонок, идеальны для аналитики; не ориентированы на частые транзакции.

Пример: аналитика поездок — колонки user_id, ride_cost, ride_date; запрос «средняя стоимость за месяц» читает только эти колонки.

Когда использовать: отчёты, статистика, большие объёмы чтения/записи.

Time-Series

Специализация на временных рядах (метрики, сенсоры). Примеры: Prometheus, Graphite, VictoriaMetrics.

Пример: метрики ride_requests_per_second с временными метками.

Когда использовать: мониторинг, датчики, аналитика по времени.

Object / Blob Storage

Хранение «сырых» данных — файлы, изображения, бэкапы (S3, MinIO). Записал — хранишь — читаешь или удаляешь; не для частых изменений.

Пример: фото профилей водителей, копии документов.

Критерии выбора

Критерий	Что учитывать
Транзакции	Нужны атомарность и согласованность → реляционные (PostgreSQL, MySQL).
Формат данных	Key-value — пары; time-series — метрики; граф — связи; аналитика — колоночные.
Навыки команды	Выбирать проверенные технологии, с которыми есть опыт.
Характер обращений	Аналитика — колоночные; точечные операции — реляционные.
Изменение схемы	Частые изменения структуры — документные (MongoDB) могут быть удобнее строгих реляционных.

Комбинирование: в одной системе могут быть реляционная БД для заказов, колоночная для аналитики, Elasticsearch для поиска, Redis для кэша. Для небольших проектов часто достаточно одной БД (например, PostgreSQL), чтобы не усложнять инфраструктуру.