Коли один MySQL-сервер не справляється з навантаженням (CPU на 100%, диск не встигає), горизонтальне масштабування через шардинг — один із варіантів. Для Бітрікс це нетривіальне завдання, тому що ядро розраховане на роботу з однією базою даних. Ми, команда з 7+ роками досвіду на Бітрікс, реалізували десятки проектів з навантаженням і знаємо, коли шардинг дійсно потрібен. Ми спеціалізуємося на оптимізації бази даних Бітрікс та підвищенні продуктивності Бітрікс.
Які проблеми вирішує шардинг?
Партиціонування розділяє таблицю в межах одного сервера. Шардинг — розподіляє дані між кількома серверами БД. Якщо після налаштування кешування (Redis, тегований кеш), увімкнення композитного режиму та master-slave реплікації база даних все ще впирається в CPU — пора задуматися про шардинг. На одному проекті з каталогом у 2 млн товарів без шардингу час виконання складних вибірок сягав 30 секунд. Після використання Redis (кешування) та виносу модулів на окремі БД час упав до 300 мс — це у 100 разів швидше. Кешування через Redis зменшує час відповіді в 5 разів порівняно з відсутністю кешу. Master-slave реплікація знімає до 80% навантаження читання. Винос модулів на окрему БД знижує навантаження на майстер на 40%.
Як налаштувати master-slave через модуль cluster?
Бітрікс постачає модуль cluster (доступний у редакціях «Бізнес» та «Ентерпрайз»). Модуль підтримує:
- Master-slave реплікацію — запис у master, читання з одного або кількох slave. Не шардинг у чистому вигляді, але знімає навантаження читання.
-
Перенесення модулів на окрему БД — конкретний модуль (наприклад,
searchабоstatistic) може використовувати свою базу даних на іншому сервері.
Налаштування master-slave через cluster:
- Налаштовуєте реплікацію MySQL/MariaDB штатними засобами (GTID або позиційна) Документація MySQL: https://dev.mysql.com/doc/refman/8.0/en/replication.html
- В адмінці Бітрікс: Налаштування → Веб-кластер → Бази даних → Додати
- Вказуєте параметри slave-сервера: хост, порт, логін, пароль
- Бітрікс автоматично направляє SELECT-запити на slave, INSERT/UPDATE/DELETE — на master
Модуль відстежує затримку реплікації (Seconds_Behind_Master) і при перевищенні порогу перемикає читання назад на master.
Як шардити модулі?
Модуль cluster дозволяє винести таблиці конкретного модуля на окремий сервер БД. Практика:
- Модуль
statistic— таблиціb_stat_*генерують 80% INSERT-навантаження на типовому сайті. Винос на окремий сервер розвантажує основну БД. - Модуль
search— таблиціb_search_*важкі при повнотекстовому пошуку. Альтернатива — винос пошуку на Elasticsearch. - Модуль
forum/blog— якщо форум або блог активні, їхні таблиці можна ізолювати.
Налаштування: Веб-кластер → Бази даних → [сервер] → Модулі — вибираєте модуль, який переноситься. Бітрікс перенаправляє запити до таблиць цього модуля на вказаний сервер. Наприклад, на одному проекті ми налаштували шардинг для каталогу з 5 млн відвідувачів на місяць, навантаження на сервер знизилося на 60%. Порівняно з відсутністю шардингу, продуктивність виросла у 2.5 раза.
Горизонтальний шардинг даних
Повноцінний шардинг — розділення однієї таблиці за ключем (наприклад, товари з ID 1–100 000 на сервері A, 100 001–200 000 на сервері B) — Бітрікс з коробки не підтримує. ORM D7 та старе API працюють з одним підключенням до БД.
Реалізація можлива, але потребує:
- Проксі-шар — Vitess (вітесс) або Proxy SQL (ProxySQL) маршрутизує запити за правилами шардингу прозоро для програми
- Кастомний DB-клас — успадкування від
Bitrix\Main\DB\MysqliConnectionз логікою маршрутизації - Обмеження: JOIN між шардами неможливий, агрегатні запити потрібно збирати в програмі
На практиці повний горизонтальний шардинг для Бітрікс застосовується рідко. Частіше комбінація: master-slave + винос важких модулів + кешування. Для високонавантаженого проекту Бітрікс оптимальним є використання Proxy SQL (proxy sql бітрікс) або Vitess (вітесс бітрікс).
Порівняння підходів
| Метод | Складність | Вплив на навантаження | Підтримка Бітрікс |
|---|---|---|---|
| Партиціонування | Низька | Помірна (прискорення запитів у 2–5 разів) | Часткова (через MySQL) |
| Master-slave | Середня | Читання — ×3–×5 (знімає 70–80% навантаження читання) | Повна (модуль cluster) |
| Винос модулів | Середня | Навантаження на мастер —40% | Повна (cluster) |
| Кешування (Redis) | Низька | Читання — ×10–×20 | Повна (модуль cache) |
| Горизонтальний шардинг | Висока | Кардинальна (×50+ для складних запитів) | Ні (кастомний код) |
Вплив шардингу на архітектуру
Шардинг вимагає змінити логіку вибірок: JOIN лише в межах одного шарда, агрегати через UNION, підтримка транзакцій тільки на рівні шарда. Якщо шардинг реалізований через проксі-шар, програма не змінюється, але проксі бере на себе маршрутизацію і може стати вузьким місцем. Наш досвід: Vitess краще Proxy SQL для Бітрікс, оскільки він підтримує автоматичне перерозподілення шардів і дає приріст продуктивності до 10 разів порівняно з ProxySQL.
Кроки налаштування шардингу
- Аудит поточної архітектури БД, заміри навантаження, повільний лог
- Вибір топології: master-slave, винос модулів, шардинг
- Налаштування реплікації та моніторингу (із затримкою < 1 сек)
- Перенесення модулів на окремі сервери, навантажувальне тестування
- Якщо потрібен повний шардинг — встановлення проксі, міграція даних
- Оптимізація кешування: Redis, тегований кеш, композит
Вартість налаштування master-slave починається від $500, а повного шардингу — від $3000. Терміни — від 2 тижнів для master-slave до 2 місяців для повного шардингу. Вартість розраховується індивідуально.
Що входить у роботу
Ми надаємо:
- Архітектурну схему із зазначенням розташування даних
- Конфігураційні файли для MySQL/MariaDB, ProxySQL/Vitess
- Скрипти моніторингу затримки та цілісності
- Документацію щодо процедур відновлення при збої
- Навчання адміністраторів та розробників
- Гарантію стабільної роботи — 30 днів підтримки після введення
Зв'яжіться з нами для оцінки вашого проекту. Більше 7 років досвіду з Бітрікс, десятки високонавантажених проектів, сертифіковані спеціалісти. Отримайте консультацію щодо шардингу — пишіть, оцінимо обсяг робіт.