Решение: SQL или NoSQL (какое семейство БД)?
Выбор правильного семейства БД определяется формой модели данных, приоритетами согласованности и масштаба, а также сложностью запросов. Обобщения вроде «NoSQL современнее» вводят в заблуждение; каждое семейство рассчитано на определённые паттерны доступа. Исходя из структуры данных, это дерево ведёт к правильному инструменту среди реляционных, документных, key-value и поисковых движков и при необходимости напоминает о полиглотном подходе.
Каков характер данных и преобладающий паттерн доступа?
Начните с самого определяющего вопроса: данные — это структурированные записи с сильными связями, документы с гибкой/изменчивой схемой, простой поиск по ключу (key-value) или особая задача вроде полнотекстового поиска? Структура данных и способ их запроса во многом определяют семейство СУБД.
- Реляционные структурированные записи и сложные запросы
- Вложенные документы с гибкой/изменчивой схемой
- Простой key-value, очень низкая задержка/кэширование
- Полнотекстовый / фасетный поиск, аналитика журналов
Приоритет — строгая согласованность (ACID) или горизонтальное масштабирование?
Данные выглядят реляционными; но каков ваш приоритет? Обязательны ли соединения нескольких таблиц, транзакционная целостность и строгая согласованность (ACID), или нужно горизонтально масштабировать огромный объём, не помещающийся на один узел? Реляционная модель — правильный выбор по умолчанию для большинства нагрузок; её пределы проявляются, только когда масштаб действительно превышает один узел.
- Главное — ACID, соединения и целостность сложных запросов
- Масштаб превыше всего, слабые связи/соединения
Рекомендация: реляционная база данных (RDBMS)
Правильный выбор по умолчанию для нагрузок со структурированными, сильно связанными данными, требующих транзакционной целостности. Гарантии ACID, зрелый движок SQL-запросов и соединения позволяют надёжно отвечать на сложные вопросы.
Рекомендация: документная база данных
Хранит гибкие вложенные данные с часто меняющейся схемой в естественном виде (JSON-подобные документы). Подходит для приложений, которые в основном читают/пишут через один документ, почти не нуждаются в соединениях и требуют горизонтального масштабирования.
Рекомендация: хранилище key-value / кэш
Рассчитано на нагрузки, которым нужны очень быстрые чтение/запись по ключу и не нужны сложные запросы. Обычно работает в памяти и обеспечивает задержку в микро-/миллисекунды; идеально для таких задач, как кэширование, сессии и счётчики.
Рекомендация: поисковый / аналитический движок
Движок на основе инвертированного индекса, специализированный на полнотекстовом поиске, ранжировании по релевантности, фасетной фильтрации и аналитике больших объёмов журналов/текста. Он даёт возможности поиска, недоступные реляционным запросам с LIKE.