В мире разработки баз данных часто возникает вечный спор: SQL или NoSQL? Теоретические статьи и маркетинговые блоги пестрят громкими обещаниями, но реальных цифр мало. В этой статье я делюсь реальным экспериментом, который мы провели в продакшене, чтобы проверить, как разные подходы справляются с нагрузкой 1 миллион запросов в минуту.

Цель эксперимента

Мы хотели ответить на три вопроса:

1. Какая база данных лучше выдерживает экстремальную нагрузку при реальных запросах?

2. Где появляются узкие места — на уровне хранилища, сети или кода?

3. Какой подход проще масштабировать без потери данных и скорости?

Для теста мы выбрали:

Важно: все базы были настроены с одинаковым количеством vCPU и RAM, чтобы нагрузка была сравнима.

Настройка теста

• Генератор нагрузки — собственный скрипт на Python с асинхронными запросами (asyncio + aiohttp).

• Тестовые данные — 10 млн записей в каждой БД.

• Типы запросов:

  • Чтение одной записи по ключу (read-heavy)

  • Чтение по фильтру (read-mixed)

  • Запись/обновление одной записи (write-heavy)

Мы прогоняли каждый сценарий по 5 раз, чтобы сгладить случайные флуктуации.

Результаты

1. Чтение по ключу (read-heavy)

Вывод: Redis — абсолютный лидер по скорости для чтения по ключу. SQL и MongoDB работают медленнее, но MongoDB выигрывает у PostgreSQL в простых read-heavy сценариях.

2. Чтение с фильтром (read-mixed)

Вывод: Здесь SQL снова показывает стабильную работу. MongoDB немного проигрывает при сложных фильтрах. Redis быстрее, но требует грамотного кэширования, иначе теряет данные при restart.

3. Запись/обновление (write-heavy)

Вывод: Redis остаётся быстрым, но в реальных сценариях нужны механизмы persistence, иначе данные могут потеряться. MongoDB выигрывает у PostgreSQL в write-heavy сценариях благодаря горизонтальному масштабированию.

Основные наблюдения

1. SQL остаётся сильным там, где нужны сложные транзакции — ACID, joins, constraints.

2. NoSQL выигрывает в скорости и горизонтальном масштабировании, но требует продуманной схемы данных и бэкапов.

3. Redis идеально подходит для кэширования, real-time analytics и очередей, но не заменяет долговременное хранилище.

4. Пропускная способность сильно зависит от индексов, репликации и оптимизации запросов, а не только от типа БД.

Рекомендации для практики

• Если нужен тяжёлый read-heavy workload — используйте Redis + кэш, PostgreSQL или Mongo с proper indexing.

• Если важны транзакции и сложные связи — SQL всё ещё лучший выбор.

• Если проект требует горизонтального масштабирования на миллионы запросов — NoSQL с репликацией будет проще.

• Всегда тестируйте нагрузку на своих данных, а не на «теоретических примерах».

Итог

Эксперимент показал, что правильная архитектура важнее выбора типа БД. Нет идеальной «SQL vs NoSQL», есть правильный инструмент для конкретной задачи.

• Redis — скорость и кэширование

• PostgreSQL — надежность и транзакции

• MongoDB — гибкость и горизонтальное масштабирование

Помните: миллионы запросов в минуту — это не только про БД, но и про сеть, приложение, индексы и мониторинг.

Если хотите быть в курсе новостей технологий и ИИ, подписывайтесь на мой Telegram-канал: https://t.me/rvaitech — там реальные кейсы, лайфхаки и обсуждения без воды.