Настройка шардинга базы данных 1С-Битрикс

Настройка шардинга базы данных 1С-Битрикс

Партиционирование разделяет таблицу внутри одного сервера. Шардинг — распределяет данные между несколькими серверами БД. Когда один MySQL-сервер не справляется с нагрузкой (CPU на 100%, диск не успевает), горизонтальное масштабирование через шардинг — один из вариантов. Для Битрикс это нетривиальная задача, потому что ядро рассчитано на работу с одной базой данных.

Встроенный механизм: модуль cluster

Битрикс поставляет модуль cluster (доступен в редакциях «Бизнес» и «Энтерпрайз»). Модуль поддерживает:

• Master-slave репликацию — запись в master, чтение с одного или нескольких slave. Не шардинг в чистом виде, но снимает нагрузку чтения.
• Перенос модулей на отдельную БД — конкретный модуль (например, search или statistic) может использовать свою базу данных на другом сервере.

Настройка master-slave через cluster:

1. Настраиваете репликацию MySQL/MariaDB штатными средствами (GTID или позиционная)
2. В админке Битрикс: Настройки → Веб-кластер → Базы данных → Добавить
3. Указываете параметры slave-сервера: хост, порт, логин, пароль
4. Битрикс автоматически направляет 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 (CIBlockElement::GetList) работают с одним подключением к БД.

Реализация возможна, но требует:

• Прокси-слой (ProxySQL, Vitess) — маршрутизирует запросы по правилам шардирования прозрачно для приложения
• Кастомный DB-класс — наследование от Bitrix\Main\DB\MysqliConnection с логикой маршрутизации
• Ограничения: JOIN между шардами невозможен, агрегатные запросы (COUNT, SUM) нужно собирать из нескольких шардов на уровне приложения

На практике полный горизонтальный шардинг для Битрикс применяется редко. Чаще комбинация: master-slave + вынос тяжёлых модулей + кеширование (Redis/Memcached).

Кеширование как альтернатива шардингу

Прежде чем шардить, убедитесь, что кеширование настроено:

• Memcached/Redis для хранения кеша Битрикс ('cache' => ['type' => 'redis'] в .settings.php)
• Тегированный кеш — инвалидация точечная, а не полная
• Композитный кеш — HTML-страницы для анонимных пользователей вообще не обращаются к БД

На 90% проектов правильно настроенное кеширование + master-slave снимают потребность в шардинге.

Что настраиваем

• Установка и настройка модуля cluster
• Конфигурация master-slave репликации MySQL/MariaDB
• Вынос тяжёлых модулей (statistic, search) на отдельный сервер БД
• Настройка мониторинга задержки репликации
• Настройка Redis/Memcached для кеширования
• Нагрузочное тестирование: распределение запросов между серверами