Шардинг — способ масштабировать не только чтение (это делает репликация), но и запись, разнося данные по разным серверам БД. В 1С-Битрикс различают вертикальный и горизонтальный шардинг. Разберём оба и границы их применимости.
Зачем нужен шардинг
Репликация master-slave масштабирует чтения, но вся запись всё равно идёт на единственный мастер. Когда мастер упирается в предел по записи или база физически не помещается на один сервер, помогает шардинг — разделение данных между несколькими независимыми БД.
В Битрикс шардинг реализован в модуле cluster и делится на два типа: вертикальный (по модулям) и горизонтальный (по данным внутри модуля). Они решают разные задачи и часто применяются вместе.
Вертикальный шардинг
Вертикальный шардинг выносит отдельные модули Битрикс в отдельные базы данных. Например, тяжёлый модуль веб-аналитики (statistic) или поиска (search) можно перевести на свой сервер БД, разгрузив основную базу.
Настраивается в Настройки → Веб-кластер → Вертикальный шардинг: выбирается модуль и база, куда переносятся его таблицы. Ядро само направляет запросы модуля в назначенную базу.
- Хорошо подходит для модулей с интенсивной записью, изолированных от остального (статистика, логи, поиск).
- Каждый модуль-шард можно масштабировать и реплицировать независимо.
- Ограничение: нельзя разнести модули, которые связаны JOIN-ами на уровне SQL, — Битрикс это учитывает и не все модули разрешает выносить.
Горизонтальный шардинг
Горизонтальный шардинг распределяет записи одной сущности между несколькими серверами по ключу. Классический пример — модуль веб-аналитики: данные хитов разбиваются по нескольким базам, и каждая хранит свою часть.
В отличие от вертикального, здесь делится не «модуль целиком», а строки одной таблицы. Это позволяет масштабировать запись практически линейно, но усложняет выборки, охватывающие все шарды.
| Тип | Что делится | Масштабирует |
|---|---|---|
| Вертикальный | Модули по базам | Разгрузку основной БД |
| Горизонтальный | Строки по серверам | Запись одной сущности |
Настройка в модуле cluster
Оба типа шардинга подключаются через панель веб-кластера, но требуют предварительной подготовки баз. Общая последовательность:
- Развернуть дополнительный сервер БД и создать целевую базу.
- В панели указать соединение (аналогично подключению реплики).
- Выбрать модуль (вертикальный) или настроить правило распределения (горизонтальный).
- Выполнить перенос данных — Битрикс поможет перенести существующие таблицы модуля.
Соединения к дополнительным базам описываются в bitrix/.settings.php в секции connections, а модуль cluster маршрутизирует запросы по назначению.
'connections' => array('value' => array(
'default' => array(/* основная БД */),
'statistic' => array(/* шард статистики */),
)),Ограничения и подводные камни
Шардинг снимает потолок записи, но добавляет сложности, которые нужно учитывать заранее:
- Не все модули поддерживают вынос — Битрикс ограничивает список безопасными для шардинга.
- Бэкапы и восстановление усложняются: нужно согласованно резервировать все шарды.
- Транзакции между шардами не атомарны — учитывайте это в бизнес-логике.
- Собственные модули под шардинг нужно проектировать заранее, закладывая ключ распределения.
Когда применять шардинг
Практические триггеры для шардинга в порядке приоритета:
- Мастер БД упирается в предел по записи, и реплики не помогают (они масштабируют только чтение).
- Отдельный модуль (статистика, поиск, лог обменов) генерирует непропорциональную нагрузку и мешает остальным.
- База не помещается на один сервер по объёму диска или памяти.
Если ни один из пунктов не выполняется, шардинг только усложнит эксплуатацию без выигрыша. Для большинства проектов достаточно вертикального шардинга тяжёлых модулей — горизонтальный нужен реже.
Итог
Шардинг в 1С-Битрикс — инструмент масштабирования записи, которого не даёт репликация. Вертикальный шардинг выносит модули в отдельные базы и разгружает основную БД; горизонтальный распределяет строки одной сущности по серверам. Оба настраиваются в модуле cluster, но требуют подготовки инфраструктуры и учёта ограничений на кросс-шардовые связи.
Мы проектируем схемы шардинга под конкретную нагрузку: определяем, какие модули выносить, как распределять данные и как согласовать бэкапы. Для собственных модулей закладываем шардируемость на этапе архитектуры, чтобы масштабирование не потребовало переписывания.
Частые вопросы
Чем шардинг отличается от репликации?
Репликация копирует данные и масштабирует чтение, но вся запись идёт на один мастер. Шардинг делит данные между серверами и масштабирует именно запись.
Что такое вертикальный шардинг в Битрикс?
Это вынос отдельных модулей в отдельные базы данных. Например, статистику или поиск переводят на свой сервер БД, разгружая основную базу.
Что такое горизонтальный шардинг?
Распределение строк одной сущности между несколькими серверами по ключу. Позволяет масштабировать запись почти линейно, но усложняет выборки по всем шардам.
Любой модуль можно вынести на отдельный шард?
Нет. Битрикс ограничивает список модулей, безопасных для выноса, потому что связанные JOIN-ами данные нельзя разнести по разным серверам.
Можно ли делать JOIN между шардами?
На уровне SQL нет. Кросс-шардовые JOIN невозможны, поэтому логику, рассчитанную на такие связи, придётся переделывать при шардинге.
Нужно ли сразу вводить горизонтальный шардинг?
Обычно нет. Начинают с репликации и кеша, затем вертикального шардинга тяжёлых модулей. Горизонтальный нужен только при упоре в предел записи одной сущности.
Как шардинг влияет на бэкапы?
Усложняет их: нужно согласованно резервировать все шарды, иначе восстановление даст несогласованное состояние данных между серверами.
Поможем с настройкой и поддержкой Для разработчиков
Поможем с настройкой, доработкой и поддержкой Для разработчиков.