Налаштування шардингу бази даних 1С-Бітрікс

Налаштування шардингу бази даних 1С-Bitrix

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

Вбудований механізм: модуль cluster

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

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

Налаштування master-slave через cluster:

1. Налаштовуєте репліцювання MySQL/MariaDB штатними засобами (GTID або позиційне)
2. В адмінці Bitrix: Налаштування → Веб-кластер → Бази даних → Додати
3. Указуєте параметри slave-сервера: хост, порт, логін, пароль
4. Bitrix автоматично спрямовує SELECT на slave, INSERT/UPDATE/DELETE — на master

Модуль відстежує затримку репліцювання (Seconds_Behind_Master) та при перевищенні порога переключає читання назад на master.

Шардинг за модулями

Модуль cluster дозволяє винести таблиці конкретного модуля на окремий сервер БД. Практика:

• Модуль statistic — таблиці b_stat_* генерують 80% INSERT-навантаження на типовому сайті. Вивід на окремий сервер розвантажує основну БД.
• Модуль search — таблиці b_search_* важкі при повнотекстовому пошуку. Альтернатива — вивід пошуку на Elasticsearch.
• Модулі forum / blog — якщо активні, можна ізолювати.

Налаштування: Веб-кластер → Бази даних → [сервер] → Модулі — вибираєте модуль для перенесення. Bitrix спрямовує запити до таблиць цього модуля на указаний сервер.

Горизонтальний шардинг даних

Повноцінний шардинг — розділення однієї таблиці за ключем (наприклад, товари з ID 1–100 000 на сервері A, 100 001–200 000 на сервері B) — Bitrix з коробки не підтримує. ORM D7 та старе API (CIBlockElement::GetList) працюють з одним підключенням до БД.

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

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

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

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

Перед шардингом переконайтеся, що кеширування налаштовано:

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

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

Що налаштовуємо

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