E-commerce и DBaaS: масштабируемые решения для ритейла

Российский онлайн-ритейл растет двузначными темпами, а инфраструктура баз данных за ним не успевает. Wildberries, Ozon и Яндекс Маркет в 2025 году совокупно продали на 8,59 трлн рублей, что на 32% больше предыдущего года. Все эти продажи — огромные нагрузки на базы данных, которые в дни распродаж, например, Черной пятницы, могут расти на порядки. В условиях жесткой конкуренции сбой в такие периоды критичен и грозит потерями миллионов рублей.

Управляемые базы данных (DBaaS) решают проблему масштабирования без найма DBA-команды и без круглосуточного дежурства в распродажи. В этой статье разберем, как именно это происходит, какие выгоды DBaaS несут бизнесу и как мигрировать в эти сервисы без потерь. Статья предназначена для CTO, технических директоров, архитекторов и DevOps-инженеров ритейла, которые проектируют или пересобирают слой данных под высокую нагрузку.

Что такое DBaaS и зачем он нужен ритейлу

DBaaS — модель потребления базы данных, при которой провайдер берет на себя развертывание кластера, бэкапы, обновление, мониторинг, восстановление после сбоев и масштабирование. Команда разработки получает endpoint и пароль, дальше работает с СУБД как с обычным PostgreSQL или MySQL, без отвлечения на инфраструктурные задачи.

Внутри управляемой платформы скрыта стандартная связка: виртуальные машины или контейнеры с СУБД, network-attached storage с репликацией, балансировщик соединений, агент мониторинга, оркестратор бэкапов. Провайдер гарантирует SLA по доступности, скорость восстановления (RTO/RPO) и согласованную версию ядра СУБД.

Классическая схема с собственными серверами требует провизионировать(выделять и готовить ресурсы) мощности заранее, обычно с запасом в 2–3 раза от среднего трафика, иначе пик распродажи положит магазин. В обычные дни эти мощности простаивают. Black Friday в России длится три дня, ради которых ритейлеры могут год держать избыточную инфраструктуру.

Ручное масштабирование добавляет проблем. Чтобы поднять реплику PostgreSQL под чтение, DBA нужно подготовить сервер, настроить streaming replication, прогреть кэш, перенастроить балансировщик. На зрелых командах это часы, на менее зрелых — дни. В пик распродажи такого окна нет. Штат DBA — отдельная статья расходов. Для круглосуточного дежурства нужны 4–5 инженеров уровня senior. DBaaS снимает эту нагрузку с команды и переносит ее на платформу.

5 задач ритейла, которые решает DBaaS

• Транзакционная нагрузка. Заказы, корзины, платежи требуют ACID-гарантий и предсказуемой latency (предсказуемой скорости обработки запросов). Управляемый PostgreSQL обеспечивает это из коробки.
• Каталог товаров. Десятки миллионов SKU с фасетным поиском, фильтрами и сезонными изменениями структуры. DBaaS берёт на себя партицирование таблиц и разворачивание read only реплики — администратор настраивает логику, провайдер обслуживает инфраструктуру.
• Real-time аналитика. Метрики продаж, конверсия по воронкам, A/B-тесты. Колоночные СУБД в формате managed-сервиса закрывают эту задачу без выделенного DWH-стека.
• Геораспределенная репликация. Локализация персональных данных, ускорение доступа из регионов, отказоустойчивость уровня дата-центра.
• PITR (Point-in-time recovery). Managed-сервис хранит WAL-логи и позволяет откатить базу на любой момент времени — без самописных скриптов и ручного управления бэкапами.
• Disaster recovery. Автоматические резервные копии, репликация между зонами доступности и задокументированные процедуры восстановления — провайдер предоставляет инструменты, команда проводит регулярные учения.

Архитектура данных для интернет-магазина

Данные нельзя просто сложить в одну базу — требуется распределенная архитектура, в которой разные продукты решают разные задачи.

Транзакционные базы данных (OLTP): PostgreSQL и MySQL

OLTP-контур — сердце e-commerce. В нем хранятся заказы, платежи, остатки, пользователи. Требования к нему: ACID, низкая латентность операций записи, корректная работа под конкурентной нагрузкой.

PostgreSQL в облаке — рекомендуемый выбор для нового e-commerce проекта. Он обеспечивает строгие ACID-гарантии, поддержка JSONB для гибких атрибутов товаров без миграций схемы, нативное декларативное партицирование, расширения PostGIS для геолокации курьеров, pg_stat_statements для профилирования запросов.

Типичная промышленная конфигурация PostgreSQL под e-commerce выглядит так: primary с синхронной репликой в соседней зоне доступности, 2–4 асинхронных read only реплики под отчетность и тяжелые SELECT, партицирование таблиц orders и order_items по месяцам.

При этом MySQL тоже никуда не исчезает и остается валидным выбором для легаси-проектов, особенно на стеке LAMP и при использовании Galera Cluster.

Кэш и сессии: Redis в облаке

Redis закрывает три класса задач интернет-магазина:

• сессии пользователей и корзины с TTL;
• кэш каталога: горячие карточки товаров, результаты фасетного поиска, агрегаты остатков;
• рейт-лимитинг публичного API и защита от парсеров конкурентов.

Managed Redis снимает две частые проблемы self-hosted установок: некорректную настройку persistence (RDB/AOF) и отсутствие failover-механики. Sentinel или Cluster-режим в управляемой версии работают по умолчанию, переключение на реплику укладывается в секунды.

Аналитика: ClickHouse и колоночные СУБД

Считать когортные метрики, строить воронки и обучать модели рекомендаций на OLTP-базе — не стоит. Тяжелые аналитические запросы блокируют транзакционную нагрузку, скорость оформления заказа уплывает в красную зону. Разделение OLTP и OLAP — обязательная практика для e-commerce от среднего размера и выше.

ClickHouse — стандарт в российском ритейле для real-time аналитики. Например, Авито построило хранилище данных на связке Vertica именно с ClickHouse с обработкой до 20 млн событий в минуту. Поток событий обычно идет через Kafka: клики, просмотры карточек, добавления в корзину, оформления заказов уходят в очередь, оттуда батчами в колоночную СУБД.

Колоночное хранение дает сжатие в 5–10 раз и линейное чтение по миллиардам строк. Типичный запрос «конверсия из просмотра в покупку по категориям за последние 30 дней» на ClickHouse выполняется секунды против минут или часов на PostgreSQL.

Сводная схема архитектуры данных в ритейле

Масштабирование под высокую нагрузку на практике

Магазин может работать отлично при 100 заказах в день и падать при 10 000. Дело не в том, что PostgreSQL не справляется с нагрузкой, а в том, что масштабирование базы данных требует архитектурных решений, а не просто более мощного железа. Разберем три уровня, на которых это решается: выбор стратегии масштабирования, управление соединениями и автоматическое масштабирование в облаке.

Вертикальное vs. горизонтальное масштабирование

Вертикальное масштабирование — наращивание ресурсов одной машины: больше vCPU, RAM, IOPS. Работает быстро, но упирается в потолок гипервизора и стоимость. Горизонтальное — добавление узлов в кластер: read only реплики под чтение, шарды под запись, отдельные ноды под аналитику.

Для PostgreSQL практический сценарий выглядит так:

1. Вертикальный апскейл primary до разумного потолка (обычно 32–64 vCPU и 256–512 ГБ RAM).
2. Горизонтальное масштабирование на чтение: 2, 4, 8 read only реплики с балансировкой через PgBouncer или приложение.
3. Запись остается на primary до тех пор, пока не упирается в IOPS диска или WAL, тогда подключается шардирование на уровне приложения или Citus.

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

Но стратегия масштабирования бесполезна, если база падает не от нагрузки запросами, а от количества соединений. Это отдельная проблема, которую решает connection pooler.

Connection pooling

Каждое соединение с PostgreSQL — это отдельный процесс с расходом около 10 МБ RAM и накладными расходами на форк. На 500 открытых коннектах база тратит около 5 ГБ оперативной памяти только на оверхед соединений, до выполнения первого запроса. На 2 000 коннектах сервер начинает свопить и деградирует независимо от нагрузки запросами.

Connection pooler — обязательный компонент промышленной установки. PgBouncer в transaction mode мультиплексирует тысячи клиентских соединений на десятки реальных коннектов к базе. Он обязательно ставится между приложением и любой production-базой PostgreSQL, даже если текущая нагрузка кажется небольшой, потому что когда она станет большой — будет поздно.

Auto-scaling в DBaaS VK Cloud

Управляемые базы данных VK Cloud поддерживают автоматическое масштабирование дисков баз данных. Когда объем свободного места на диске достигает порогового значения, его размер автоматически увеличивается на шаг расширения. Это увеличение ограничено заранее заданным максимальным размером, при достижении которого кластер переходит в режим только для чтения.

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

Кейс: подготовка к распродаже (Black Friday)

Сценарий подготовки к Black Friday 2025 года (28–30 ноября) на databases as a service выглядит так.

За неделю до пика. Проводится нагрузочное тестирование на копии production, обычно через k6. Целевая планка — пиковая нагрузка прошлого года × 1,5. Важно заранее посмотреть на статистику прошлого года и прикинуть, на какое количество реплик необходимо будет масштабироваться в пиковую нагрузку. Посмотреть этот процесс в деталях можно в документации VK Cloud.

Автомасштабирование в VK Cloud DBaaS доступно только для дисков. Масштабирование флейвора и количество реплик доступно в ручном режиме (то есть самостоятельно). Мы максимально упрощаем сам процесс масштабирования - можно просто за пару кликов это сделать в личном кабинете, что сильно экономит время.

За сутки до старта. Проверяются метрики PgBouncer: размер пула, доля занятых соединений, очередь ожидания. Если без пулера база выдерживала 2 000 коннектов, после включения транзакционного пулинга порог поднимается до 10 000+ при той же утилизации ресурсов. Включается расширенный мониторинг: pg_stat_statements, slow query log, метрики WAL и заполнения диска — чтобы видеть, как часто срабатывает авторасширение.

В день пика. Дежурство сводится к наблюдению за дашбордами: connection pooling держит под контролем число соединений, автоскейлинг диска не даёт упереться в лимит хранилища, а увеличение флейвора и реплик помогает справиться с нагрузкой. Нагрузка интернет‑магазина в Black Friday может держаться 72 часа подряд, и без пулинга плюс автоматического увеличения диска это превращается в череду инцидентов.

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

Когда выбирать DBaaS для ритейла

Вот сценарий, в котором DBaaS VK Cloud — рабочий выбор для интернет-магазина:

• Локализация данных в РФ. Аттестованные ЦОД на территории России закрывают требования 152-ФЗ по умолчанию, без отдельного аудита размещения.
• Низкая задержка для российской аудитории. Сетевая близость к крупным магистральным узлам дает десятки миллисекунд до пользователя в Москве, Петербурге, Екатеринбурге, а не сотни, как при работе через зарубежный регион.
• Поддержка 24/7. Инженеры разбирают инцидент быстро, чтобы бизнес не пострадал от технических проблем.
• Интеграция с экосистемой VK Cloud. Cloud Compute для приложения, VK Object Storage для медиа-каталога, CDN для статики, DBaaS для всех слоев хранения в одной панели управления, с единой биллинг-моделью и сетевой связностью.
• Покрытие всех трех слоев архитектуры. PostgreSQL под OLTP, Redis-совместимая БД под кэш, ClickHouse под аналитику.

Безопасность и соответствие требованиям

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

Шифрование данных в покое и при передаче

Стандарт для управляемой БД — это протоколы TLS 1.2 и выше. Разделение ответственности здесь принципиальное: провайдер отвечает за инфраструктуру шифрования, заказчик — за управление ключами, политику доступа и аудит запросов.

Соответствие 152-ФЗ для ритейла

С 1 июля 2025 года в России действует прямой запрет на хранение персональных данных граждан РФ в зарубежных базах данных без локальной копии в РФ. Это закрывает для российского e-commerce схемы вида «основной кластер в зарубежном облаке, бэкап у локального провайдера». С 1 сентября 2025 года для ритейла добавилось требование отдельного согласия на обработку ПДн: общая «галочка в форме» больше не закрывает обработку для маркетинга, рекомендательных систем и аналитики. Cookie-аналитика поведения покупателя на сайте (поведенческие профили, корзины, история просмотров) также попадает под режим согласия, если данные привязаны к идентифицируемому пользователю.

Для DBaaS-провайдера это означает, что ЦОД должен быть на территории РФ и аттестован под требования регулятора. У VK Cloud — аттестованные ЦОД в России, что закрывает требование локализации без дополнительных юридических конструкций.

Отказоустойчивость

DBaaS VK Cloud поддерживает несколько уровней защиты от отказов. Автоматический failover переключает нагрузку на резервный узел без ручного вмешательства. Мультизональный кластер (Multi-AZ) обеспечивает работу сервиса даже при полном отказе одного дата-центра: реплика в соседней зоне принимает трафик, пока основной ЦОД недоступен. Если диск заполнен критически, база переходит в режим read-only — запись блокируется, чтение продолжается, данные остаются целыми.

Резервное копирование и Disaster Recovery

В управляемой БД бэкапы работают как фоновый процесс провайдера: снимки кластера хранятся 14–30 дней, WAL-журналы PostgreSQL пишутся непрерывно, что позволяет выполнить Point-in-Time Recovery на любой момент в пределах окна хранения. RPO в такой схеме измеряется секундами, RTO на восстановление крупного кластера — десятками минут.

В self-hosted с ручными скриптами pg_basebackup и cron-задачами картина другая: RPO легко уезжает к часам, а RTO — к суткам, если резервная копия оказалась повреждена и приходится восстанавливаться из более старого снимка. Для интернет-магазина час простоя в Чёрную пятницу — это прямая потеря выручки.

Миграция с self-hosted на DBaaS: как перейти без потерь

Переход с собственной инсталляции PostgreSQL или MySQL на DBaaS — это серьезный проект на 4–8 недель для среднего магазина, с подготовкой, тестированием на staging и аккуратным переключением трафика. Он состоит из нескольких последовательных шагов.

Первым делом нужно провести инвентаризацию и учесть: список СУБД и их версий, объемы данных по каждой базе, схема репликации, расширения PostgreSQL (PostGIS, pgvector, pg_partman), внешние зависимости (FDW, логические подписки), требования к latency. На этом этапе становится понятно, какие нагрузки помещаются в стандартные конфигурации DBaaS, а где нужны read only реплики или отдельный кластер под аналитику.

Параллельно команда снимает baseline производительности: p50/p95/p99 по основным запросам, пиковый QPS, размер connection pool, частоту checkpoints. Этот baseline станет точкой отсчета для приемки после миграции. Для PostgreSQL схему удобно снимать через pg_dump --schema-only и \dt+, для MySQL — через mysqldump --no-data и information_schema.

Затем нужно провести дамп и восстановление: остановили запись на источнике, сняли pg_dump, восстановили на DBaaS, переключили приложение. Простой и предсказуемый, но требует окна простоя в часы, на больших базах неприемлемо для production e-commerce.

Чек-лист готовности к миграции

Минимальный набор проверок перед переключением production-трафика:

• Staging-тест с DBaaS. Полный прогон бизнес-сценариев (корзина, оформление заказа, личный кабинет, поиск) на копии production-данных в DBaaS. Сравнение p95/p99 со снятым baseline.
• Connection pooling. PgBouncer или встроенный пулер DBaaS настроен под профиль приложения: transaction-mode для коротких OLTP-транзакций, session-mode для долгих сессий с подготовленными выражениями.
• Индексы и slow queries. Журнал медленных запросов проанализирован за две недели работы staging, добавлены недостающие индексы, проверены планы выполнения для топ-10 запросов по времени.
• Мониторинг и алертинг. Метрики кластера (CPU, IOPS, replication lag, connections, dead tuples) выведены в систему мониторинга команды. Алерты на replication lag > 30 секунд, connections > 80% лимита, free disk < 20%.
• Rollback plan. Прописана процедура отката: источник в self-hosted остается в горячем режиме на 48–72 часа после переключения.

Заключение

DBaaS снимает с команды ритейлера операционную нагрузку (установку, бэкапы, патчинг, репликацию, отказоустойчивость) и переводит ее в зону ответственности провайдера. Освободившийся ресурс DBA и DevOps уходит на то, что приносит выручку: оптимизацию запросов, проектирование схемы под бизнес-кейсы, работу с аналитикой.

Для e-commerce критичны три вещи. Первое — локализация данных под 152-ФЗ: с 1 июля 2025 года хранение ПДн граждан РФ в зарубежных базах запрещено. Второе — автоматическое масштабирование дисков под пики Черной пятницы, сезонных и предновогодних распродаж, когда трафик взлетает в 5–10 раз за сутки. Третье — использование нескольких типов баз данных в одной системе : PostgreSQL под транзакции, Redis под кэш и сессии, ClickHouse под аналитику и рекомендации. Эти три компонента в управляемом виде закрывают типовую архитектуру современного интернет-магазина от каталога до BI-дашборда.