Правильный вопрос не «какая БД лучше», а «какие запросы мы будем делать и с какой нагрузкой». Хранилище выбирают под паттерн доступа.
Реляционные БД (PostgreSQL, MySQL)
Таблицы, схема, SQL, JOIN, транзакции ACID, вторичные индексы. Выбор по умолчанию для бизнес-данных: заказы, пользователи, платежи. Один хорошо настроенный PostgreSQL держит тысячи и десятки тысяч простых запросов в секунду и терабайты данных. Масштабирование чтения репликами, записи шардированием (вручную или Citus).
Key-value (Redis, etcd)
Доступ только по ключу, очень быстро. Redis держит данные в памяти: сотни тысяч операций в секунду на узел. Подходит для кеша, сессий, счётчиков, rate limiting, очередей задач попроще. Объём ограничен памятью.
Документные (MongoDB)
JSON-подобные документы с гибкой схемой. Удобно, когда сущность читается целиком и вложенность естественна (карточка товара с разными атрибутами). JOIN и транзакции между документами есть, но это не сильная сторона.
Широкостолбцовые (Cassandra, ScyllaDB, HBase)
Огромный поток записи, горизонтальное масштабирование без лидера (в Cassandra), запросы только по заранее спроектированному ключу партиции. Таблицу проектируют под запрос. Подходит для логов событий, истории сообщений, IoT-метрик.
Колоночные аналитические (ClickHouse)
Хранят данные по колонкам и отлично сжимают. Агрегаты по миллиардам строк за секунды. Плохо подходят для точечных обновлений и частых мелких вставок: пишут пачками. ClickHouse создан в Яндексе и широко используется в РФ для аналитики и логов.
Поисковые (Elasticsearch, OpenSearch)
Обратный индекс для полнотекстового поиска, фасетов, нечёткого поиска. Не источник истины: данные приходят из основной БД через очередь или CDC и могут отставать.
Объектные хранилища (S3 и совместимые)
Файлы любого размера: картинки, видео, бэкапы. Дёшево, практически без лимита объёма, высокая надёжность. Метаданные о файлах хранят в обычной БД, сам файл в S3. Клиент загружает напрямую по presigned URL, минуя ваш сервер.
Графовые (Neo4j)
Запросы по связям с переменной глубиной: «друзья друзей», рекомендации. Нужны редко, часто хватает реляционной БД с рекурсивным CTE.
Time-series (Prometheus, VictoriaMetrics, TimescaleDB)
Метрики с меткой времени, сжатие, downsampling, запросы по окнам.
Как рассуждать на собесе
- Какие сущности и связи? Нужны ли транзакции между ними?
- Соотношение чтения и записи, RPS.
- Объём через 3-5 лет.
- Запросы: по ключу, по диапазону, полнотекст, агрегаты?
- Требования к консистентности.
Пример: мессенджер. Пользователи и чаты в PostgreSQL. История сообщений: миллиарды строк, запись постоянно, чтение «последние N сообщений чата» → Cassandra или шардированный PostgreSQL с ключом chat_id. Медиа в S3. Поиск по сообщениям в Elasticsearch.
Polyglot persistence
В реальных системах используют несколько хранилищ, каждое под свою задачу. Цена: синхронизация данных между ними и сложность эксплуатации. Не стоит добавлять хранилище без причины.
Частые ошибки
- Брать NoSQL «потому что масштабируется», не понимая паттерн запросов.
- Хранить файлы в БД в виде blob.
- Считать поисковый индекс источником истины.
- Делать в ClickHouse построчные вставки по одной записи.
Что спросят на собесе
- Когда SQL, а когда NoSQL.
- Где хранить картинки и видео.
- Почему ClickHouse не подходит как основная БД интернет-магазина.
- Как хранить историю сообщений мессенджера.
- Что такое ключ партиции в Cassandra.