Когда документная база данных выгоднее реляционной: пять сценариев Yandex StoreDoc

Почему бизнес выбирает документные базы данных

Базу данных подбирают под характер задачи, а не наоборот. Транзакционные системы вроде PostgreSQL и MySQL^® хороши там, где нужны строгая схема и ACID-транзакции. Аналитические — например, ClickHouse^® — отвечает за тяжёлые агрегации и работу с большими объёмами. Документные базы данных занимают свою нишу: они выигрывают там, где важны гибкость структуры, скорость изменений и горизонтальное масштабирование.

Yandex StoreDoc — это управляемый MongoDB^®-совместимый сервис. Он берёт на себя инфраструктуру: развёртывание кластера, резервное копирование, репликацию и мониторинг, а команда сосредотачивается на продукте.

Как выбрать базу данных

Для этого важно рассмотреть три аспекта задачи:

• Тип нагрузки: транзакционная, аналитическая или смешанная.
• Структура данных: задана ли заранее жёсткая схема. У PostgreSQL и ClickHouse схема строгая. У MongoDB и Valkey^™ её нет — структуру можно менять на ходу.
• Требования к масштабированию: нужно ли легко расти горизонтально. NoSQL-базы данных — Yandex StoreDoc, Valkey^™ — поддерживают это сразу через механизмы шардирования, без донастройки.

Универсальной базы данных не существует. Если впереди большая аналитика — логично взять ClickHouse. Если схема строгая и важны транзакции — PostgreSQL. А вот для гибких, меняющихся данных стоит рассмотреть документную базу. В ней данные хранятся в виде документов, чаще всего в формате JSON. У такой модели гибкая схема: заранее заданной структуры нет, а сами документы можно вкладывать друг в друга. Обращение обычно идёт по идентификатору, поэтому данные легко распределить по шардам: системе не важно, в каком из них лежит запись, если известна вся топология. Yandex StoreDoc работает именно с JSON.

Базы с документной моделью — это отдельный класс баз данных, не лучше и не хуже других. Сила Yandex StoreDoc в том, что он не требует жёсткой схемы и легко растёт горизонтально.

Сценарий 1. Каталоги товаров и электронная коммерция

Проблема: в интернет-магазине товары разных категорий описывают по-разному. У одежды — размер, цвет и материал. У электроники — технические характеристики и срок гарантии. У книг — автор и издательство. На большом маркетплейсе рядом могут лежать автомобиль и телефон с совершенно разным набором атрибутов.

Как это решают в реляционной базе данных: заводят множество таблиц и связывают их с помощью команды JOIN. Схема выходит сложной, и любое изменение даётся тяжело: чтобы добавить атрибуты, приходится перестраивать структуру таблиц.

Как помогает Yandex StoreDoc: каждый товар — это JSON-документ со своей структурой. Можно положить рядом записи с разным набором полей и не проектировать заранее сложную схему:

{
  "_id": "product_12345",
  "category": "electronics",
  "name": "Смартфон XYZ",
  "price": 29990,
  "attributes": {
    "screen": "6.5 inch",
    "ram": "8GB",
    "storage": "256GB"
  },
  "inventory": {
    "warehouse_moscow": 45,
    "warehouse_spb": 23
  }
}

Что это даёт бизнесу:

• запуск новой категории товаров занимает несколько часов, а не недели;
• атрибуты добавляются без изменения схемы базы данных;
• в пиковые периоды встроенное шардирование распределяет нагрузку.

Сценарий 2. Пользовательские профили и персонализация

Проблема: разные типы пользователей хранят разные данные. Клиенты B2B и B2C, бесплатные и премиум-подписчики, пользователи из разных регионов — у каждого свой набор полей. А со временем появляются новые типы подписок и признаки для персонализации.

Как это решают в реляционной базе данных: создают несколько таблиц пользователей под разные схемы и собирают полный профиль сложными JOIN-запросами. Новый тип подписки или поле требуют миграции всех таблиц, а часть колонок у пользователей остаётся незаполненной.

Как помогает Yandex StoreDoc: профиль любого типа описывается одним документом с вложенной структурой — в одном хранилище:

{
  "_id": "user_789",
  "type": "premium_b2b",
  "name": "ООО «Компания»",
  "subscription": {
    "plan": "enterprise",
    "features": ["api_access", "priority_support"],
    "expires": "2026-12-31"
  },
  "preferences": {
    "notifications": {"email": true, "sms": false},
    "language": "ru"
  }
}

Что это даёт бизнесу:

• единое хранилище для всех типов пользователей;
• новые функции персонализации внедряются быстрее;
• гибкая сегментация для маркетинговых кампаний.

Сценарий 3. Событийные данные и аналитика поведения

Проблема: логи, клики, действия пользователей приходят в разном формате из разных источников. Структура событий со временем меняется, а объём растёт лавинообразно.

Как это решают в реляционной базе данных: жёсткая схема таблицы не даёт добавить новый тип события без команды ALTER TABLE. Под разные события заводят отдельные таблицы, а анализ поведения требует их объединения. Высокая нагрузка на запись приводит к блокировкам, а горизонтально масштабироваться сложно.

Как помогает Yandex StoreDoc: события из любых источников попадают в одну коллекцию без приведения к единой структуре, и по ним можно делать агрегированные запросы сразу по нескольким системам:

{
  "_id": "event_abc123",
  "timestamp": "2026-05-18T14:30:00Z",
  "user_id": "user_789",
  "event_type": "product_view",
  "source": "mobile_app",
  "data": {
    "product_id": "product_12345",
    "device": {"os": "iOS", "version": "17.4"}
  }
}

Что это даёт бизнесу:

• приём событий из любых источников без приведения к единому формату;
• масштабирование под высокую нагрузку — миллионы событий в день;
• быстрая аналитика поведения для улучшения продукта.

Сценарий 4. Контент-проекты и CMS

Проблема: статьи, страницы и посты состоят из вложенных блоков: текста, изображений, видео, виджетов. Структура контента часто меняется, появляются новые типы блоков — например, опрос или калькулятор.

Как это решают в реляционной базе данных: под статьи, блоки, медиа и теги заводят отдельные таблицы, а страницу целиком собирают из множества JOIN-запросов. Каждый новый тип блока заставляет менять схему, версионность приходится вести вручную, а иерархия разделов добавляет сложностей.

Как помогает Yandex StoreDoc: описывает страницу одним документом с массивом блоков. Генератор на стороне приложения проходит по блокам и отрисовывает их в нужном порядке — страницы выглядят разнообразно.

{
  "_id": "article_567",
  "title": "Как выбрать базу данных",
  "published": true,
  "blocks": [
    {"type": "heading", "level": 1, "text": "Введение"},
    {"type": "paragraph", "text": "Выбор базы данных..."},
    {"type": "image", "url": "/img/db.png"}
  ],
  "metadata": {"tags": ["database"], "views": 15420}
}

Что это даёт бизнесу:

• гибкая структура контента без жёсткой схемы;
• быстрый запуск новых типов страниц и блоков;
• разнообразное представление контента на разных страницах.

Сценарий 5. Бэкенд-сервисы и обмен данными

Проблема: современным приложениям нужно хранить сессии, кеш, очереди задач и конфигурации. У этих данных разная структура, они требуют высокой скорости чтения и записи. Отдельная история — обмен данными между сервисами, которые представляют их по-разному.

Как это решают в реляционной базе данных: сессии и кеш держат в Valkey, очереди — в Apache Kafka^®, конфигурации — в отдельном хранилище. Каждая система требует своей инфраструктуры, мониторинга и поддержки, а согласованность данных между ними приходится обеспечивать отдельно.

Как помогает Yandex StoreDoc: одна база данных закрывает несколько бэкенд-задач: сессии с TTL, кеш результатов тяжёлых запросов, статусы задач, переключатели функций и конфигурации для разных окружений.

Что это даёт бизнесу:

• единая база данных под разные бэкенд-задачи;
• горизонтальное масштабирование под нагрузку;
• меньше инфраструктуры — не нужно отдельное решение под кеш и очереди;
• проще архитектура и ниже операционные расходы.

Почему именно в облаке

Yandex StoreDoc как управляемый сервис снимает с команды рутину сопровождения базы данных, и вот что это значит на практике.

Скорость выхода на рынок

Кластер разворачивают за несколько минут прямо в консоли. Не нужно закупать оборудование, нанимать отдельного администратора базы данных и настраивать инфраструктуру — фокус остаётся на продукте. Это особенно ценно на этапе MVP, когда конечная схема данных ещё неизвестна: документная модель позволяет менять её без болезненных миграций. Правда, часть логики придётся учесть на стороне приложения.

Экономическая эффективность

Оплата идёт по факту использования, без капитальных затрат на оборудование. Гибкое масштабирование снижает риск переплаты за простаивающие ресурсы.

Надёжность и безопасность

Сервис создаёт резервные копии автоматически, восстановить данные можно на конкретный момент времени вплоть до секунды — прямо из интерфейса. Репликация и автоматическое переключение на резервный узел обеспечивают высокую доступность: кластер с двумя и более хостами переживает выход из строя целого дата-центра. Данные защищены сетевой изоляцией, ролевым доступом и шифрованием.

Производительность без лишних усилий

Сервис автоматически устанавливает обновления и патчи. Встроенный мониторинг и алертинг работают не только для вас: если с кластером возникнет проблема, наши дежурные инженеры увидят это и подключатся. Для работы с большими объёмами доступно шардирование, а ускорять запросы помогают разные типы индексов, включая TTL.

Миграция без боли

Yandex StoreDoc полностью совместим с MongoDB начиная с версии 7.0. Существующие драйверы и инструменты работают без изменений, а перенос данных проходит так же, как между обычными кластерами MongoDB. Кроме того, документная модель хорошо сочетается с Java^™ — формат структурирования данных в нём аналогичен.

Когда Yandex StoreDoc не лучший выбор

Есть задачи, где другие базы данных подойдут лучше:

• Сложные транзакции с участием множества сущностей. Здесь сильнее PostgreSQL или MySQL.
• Строгая фиксированная схема. Если структура данных известна заранее и жёстко задана, реляционная база эффективнее.
• OLAP-аналитика и тяжёлые агрегации. Их быстрее и дешевле по ресурсам считать в ClickHouse.

Формально всё это можно сделать и в документной базе — но код приложения окажется сложнее, а скорость — ниже. Yandex StoreDoc стоит выбирать в тех случаях, когда на первом месте гибкость, масштабирование и скорость разработки, а не сложные транзакции по заранее известной строгой схеме.