Настройка шардинга базы данных 1С-Битрикс
Партиционирование разделяет таблицу внутри одного сервера. Шардинг — распределяет данные между несколькими серверами БД. Когда один MySQL-сервер не справляется с нагрузкой (CPU на 100%, диск не успевает), горизонтальное масштабирование через шардинг — один из вариантов. Для Битрикс это нетривиальная задача, потому что ядро рассчитано на работу с одной базой данных. Мы, команда с 7+ годами опыта на Битрикс, реализовали десятки проектов с нагрузкой и знаем, когда шардинг действительно нужен.
Когда нужен шардинг базы данных
Если после настройки кэширования (Redis, тегированный кэш), включения композитного режима и master-slave репликации база данных всё ещё упирается в CPU — пора задуматься о шардинге. На одном проекте с каталогом в 2 млн товаров без шардинга время выполнения сложных выборок достигало 30 секунд. После выгрузки модуля статистики и поиска на отдельные сервера время упало до 300 мс.
Встроенный механизм: модуль cluster
Битрикс поставляет модуль cluster (доступен в редакциях «Бизнес» и «Энтерпрайз»). Модуль поддерживает:
- Master-slave репликацию — запись в master, чтение с одного или нескольких slave. Не шардинг в чистом виде, но снимает нагрузку чтения.
-
Перенос модулей на отдельную БД — конкретный модуль (например,
searchилиstatistic) может использовать свою базу данных на другом сервере.
Настройка master-slave через cluster:
- Настраиваете репликацию MySQL/MariaDB штатными средствами (GTID или позиционная)
- В админке Битрикс: Настройки → Веб-кластер → Базы данных → Добавить
- Указываете параметры slave-сервера: хост, порт, логин, пароль
- Битрикс автоматически направляет SELECT-запросы на slave, INSERT/UPDATE/DELETE — на master
Модуль отслеживает задержку репликации (Seconds_Behind_Master) и при превышении порога переключает чтение обратно на master.
Шардинг по модулям
Модуль cluster позволяет вынести таблицы конкретного модуля на отдельный сервер БД. Практика:
- Модуль
statistic— таблицыb_stat_*генерируют 80% INSERT-нагрузки на типичном сайте. Вынос на отдельный сервер разгружает основную БД. - Модуль
search— таблицыb_search_*тяжёлые при полнотекстовом поиске. Альтернатива — вынос поиска на Elasticsearch. - Модуль
forum/blog— если форум или блог активны, их таблицы можно изолировать.
Настройка: Веб-кластер → Базы данных → [сервер] → Модули — выбираете модуль, который переносится. Битрикс перенаправляет запросы к таблицам этого модуля на указанный сервер.
Горизонтальный шардинг данных
Полноценный шардинг — разделение одной таблицы по ключу (например, товары с ID 1–100 000 на сервере A, 100 001–200 000 на сервере B) — Битрикс из коробки не поддерживает. ORM D7 и старое API работают с одним подключением к БД.
Реализация возможна, но требует:
- Прокси-слой — Vitess или ProxySQL маршрутизирует запросы по правилам шардирования прозрачно для приложения
- Кастомный DB-класс — наследование от
Bitrix\Main\DB\MysqliConnectionс логикой маршрутизации - Ограничения: JOIN между шардами невозможен, агрегатные запросы нужно собирать в приложении
На практике полный горизонтальный шардинг для Битрикс применяется редко. Чаще комбинация: master-slave + вынос тяжёлых модулей + кэширование.
Сравнение подходов
| Метод | Сложность | Влияние на нагрузку | Поддержка Битрикс |
|---|---|---|---|
| Партиционирование | Низкая | Умеренная (ускорение запросов) | Частичная (через MySQL) |
| Master-slave | Средняя | Чтение — ×3–×5 | Полная (модуль cluster) |
| Вынос модулей | Средняя | Нагрузка на мастер —40% | Полная (cluster) |
| Горизонтальный шардинг | Высокая | Кардинальная | Нет (кастомный код) |
Влияние шардинга на архитектуру
Шардинг требует изменить логику выборок: JOIN только внутри одного шарда, агрегаты через UNION, поддержка транзакций только на уровне шарда. Если шардинг реализован через прокси-слой, приложение не меняется, но прокси берёт на себя маршрутизацию и может стать узким местом. Наш опыт: Vitess лучше ProxySQL для Битрикс, так как он поддерживает автоматическое перераспределение шардов.
Процесс настройки
- Аудит текущей архитектуры БД, замеры нагрузки, медленный лог
- Выбор топологии: master-slave, вынос модулей, шардинг
- Настройка репликации и мониторинга (с задержкой < 1 сек)
- Перенос модулей на отдельные сервера, нагрузочное тестирование
- Если нужен полный шардинг — установка прокси, миграция данных
- Оптимизация кэширования: Redis, тегированный кэш, композит
Сроки — от 2 недель для master-slave до 2 месяцев для полного шардинга. Стоимость рассчитывается индивидуально.
Что входит в работу
Мы предоставляем:
- Архитектурную схему с указанием расположения данных
- Конфигурационные файлы для MySQL/MariaDB, ProxySQL/Vitess
- Скрипты мониторинга задержки и целостности
- Документацию по процедурам восстановления при сбое
- Обучение администраторов и разработчиков
- Гарантию стабильной работы — 30 дней поддержки после ввода
Свяжитесь с нами для оценки вашего проекта. Более 7 лет опыта с Битрикс, десятки высоконагруженных проектов, сертифицированные специалисты. Получите консультацию по шардингу — пишите, оценим объём работ.