Магазин рос спокойно, пока однажды на распродаже каталог не начал открываться по десять секунд, а сервер базы данных не упёрся в потолок. Знакомая картина: пока трафик небольшой, одна база тянет всё, но с ростом нагрузки именно она первой становится узким местом — тем бутылочным горлышком, в которое упирается вся производительность.
Эта статья — о том, как масштабировать базу данных под нагрузкой в проекте на 1С-Битрикс: чем репликация отличается от шардирования, как работает веб-кластер, как разделять чтение и запись, зачем нужны highload-блоки и почему начинать всегда стоит не с новых серверов, а с оптимизации. Тема опирается на нашу практику аудита и оптимизации 1С-Битрикс под высокие нагрузки.
Коротко
- База — типичное узкое место магазина: с ростом нагрузки она упирается в потолок первой.
- Репликация масштабирует чтение (master пишет, slave читают), шардирование делит данные и масштабирует запись.
- В 1С-Битрикс репликацию и разделение чтения/записи даёт штатный модуль «Веб-кластер».
- Начинать надо с оптимизации запросов, индексов, кэша и композита — часто этого достаточно без репликации.
Когда база становится узким местом
Веб-приложение можно условно разложить на слои: веб-сервер, PHP, кэш и база данных. Первые три масштабируются относительно легко — добавил серверов приложения, распределил нагрузку. База сложнее: это хранилище состояния, и просто «поставить ещё одну» нельзя без специальных механизмов. Поэтому именно она чаще всего первой упирается в предел.
Признаки, что база стала узким местом: растёт время ответа на страницах каталога, сервер БД перегружен по процессору или диску, появляются медленные и заблокированные запросы, на пиках трафика магазин деградирует. Важно диагностировать это по данным, а не по ощущениям: иногда «тормозит база» на деле означает «нет кэша» или «кривой запрос».
Вертикальное и горизонтальное масштабирование
Есть два принципиально разных пути наращивания мощности базы, и их важно различать.
| Подход | Суть | Плюсы и пределы |
|---|---|---|
| Вертикальное | Более мощный сервер БД | Просто, но упирается в потолок железа и цену |
| Репликация | Копии базы для чтения | Масштабирует чтение и отказоустойчивость |
| Шардирование | Данные делятся между серверами | Масштабирует запись и объём, но сложно |
Вертикальное масштабирование — первый и простейший шаг: мощнее процессор, больше памяти, быстрее диски. Оно доводит систему до определённого предела, за которым железо либо упирается в физический потолок, либо становится непропорционально дорогим. Дальше начинается горизонтальное масштабирование — распределение нагрузки между несколькими серверами через репликацию или шардирование.
Репликация: чтение против записи
Репликация — основной инструмент масштабирования базы магазина, и работает она на простом наблюдении: у интернет-магазина операций чтения многократно больше, чем записи. Пользователи листают каталог, открывают карточки, ищут — это всё чтение; заказы и изменения — редкая запись.
Схема master-slave использует этот дисбаланс:
- Master. Один сервер принимает все операции записи (заказы, изменения данных).
- Slave. Несколько серверов-копий обслуживают чтение (каталог, карточки, поиск).
- Распределение чтения. Запросы на чтение раскидываются по slave-серверам, снимая нагрузку с master.
- Отказоустойчивость. Копии данных повышают надёжность: при отказе одного узла есть другие.
Поскольку чтения подавляющее большинство, добавление slave-серверов линейно наращивает пропускную способность на самой массовой операции. Это покрывает потребности большинства растущих магазинов без перехода к более сложному шардированию.
Веб-кластер 1С-Битрикс
Хорошая новость для проектов на 1С-Битрикс: репликацию не нужно строить с нуля. В редакциях с модулем «Веб-кластер» платформа умеет работать с репликацией MySQL штатно.
Что даёт веб-кластер:
- Разделение запросов. Битрикс сам направляет запись на master, а чтение — на slave.
- Распределение чтения. Чтение балансируется между несколькими репликами.
- Учёт отставания. Механизм умеет учитывать задержку реплик и не читать устаревшее там, где это критично.
- Масштабирование кэша и сессий. Помимо базы, кластер распределяет кэш и хранение сессий между узлами.
То есть на Битрикс горизонтальное масштабирование — это в первую очередь правильная настройка веб-кластера, а не самописные надстройки. Всё это работает поверх подготовленной инфраструктуры, о развёртывании которой мы писали в статье про хостинг и инфраструктуру BitrixVM.
Отставание реплик и целостность данных
У репликации есть коварная особенность — отставание (lag). Slave-сервер применяет изменения с master не мгновенно, а с некоторой задержкой. В большинстве случаев она незаметна, но создаёт риск: чтение с отстающей реплики сразу после записи может вернуть старые данные.
Решается это направлением критичного чтения. Данные, которые нужны сразу после записи и должны быть точными (только что созданный заказ, актуальный остаток при оформлении), читают с master. А то, где небольшая задержка не важна — каталог, карточки, списки товаров, — спокойно отдают с реплик. Веб-кластер Битрикс поддерживает такую логику, но её нужно осознанно настроить под сценарии проекта.
Шардирование: когда оно нужно
Репликация масштабирует чтение, но не запись — master остаётся один. Когда упирается уже запись или объём данных превышает возможности одного сервера, применяют шардирование: данные делят на части (шарды) по какому-то признаку, и каждый сервер хранит и обслуживает только свою часть.
Шардирование мощно, но дорого в сложности:
- Выбор ключа шардирования. По какому признаку делить данные — критичное и трудно обратимое решение.
- Сложность запросов. Запросы через несколько шардов усложняются, часть привычных операций становится дорогой.
- Эксплуатация. Резервные копии, миграции, балансировка шардов требуют серьёзной инженерии.
- Разработка. Приложение должно знать, где лежат данные, — это усложняет код.
Поэтому шардирование — удел действительно больших систем: крупных маркетплейсов, порталов с огромными объёмами. Как проектируют такие масштабные платформы, мы касались в статье про разработку модуля маркетплейса на Битрикс. Обычному магазину шардинг почти никогда не нужен — ему хватает оптимизации и репликации.
Highload-блоки для больших объёмов
Отдельная тема — большие таблицы однотипных данных внутри самого Битрикс. Когда справочники, характеристики или связанные данные разрастаются до миллионов записей, держать их в обычных инфоблоках становится неэффективно. Для этого есть highload-блоки.
Highload-блок — это механизм хранения больших объёмов однотипных данных отдельно от инфоблоков, с оптимизированным доступом через D7. Он разгружает основную структуру и лучше масштабируется на больших объёмах. Типичные применения — крупные справочники, характеристики товаров, данные, которых очень много и которые часто читаются. Правильная работа с ними идёт через ORM — про это мы писали в статье про D7 и ORM в Битрикс.
Кэш и композит снимают нагрузку с базы
Прежде чем масштабировать базу, стоит уменьшить число обращений к ней. Лучший запрос к базе — тот, который не понадобился, потому что ответ взят из кэша. Кэширование и композит снимают с базы огромную долю нагрузки:
- Кэш компонентов. Результаты работы разделов, меню, списков не пересчитываются каждый раз.
- Композитный сайт. Статическая часть страниц отдаётся без обращения к базе вовсе.
- Кэш в памяти. Хранение кэша в оперативной памяти вместо файлов ускоряет доступ.
- Кэш запросов. Тяжёлые выборки кэшируются на уровне ORM.
Часто грамотная настройка кэша и композита снимает проблему нагрузки на базу полностью, и дорогая репликация просто не требуется. Это самый дешёвый и быстрый способ выиграть производительность, поэтому с него и начинают.
Оптимизация запросов и индексы
Вторая по важности вещь до масштабирования — качество самих запросов. Один плохой запрос без индекса под нагрузкой кладёт базу эффективнее, чем весь трафик магазина. Что проверяют:
- Медленные запросы. Находят самые тяжёлые обращения к базе по логам и профилированию.
- Индексы. Проверяют, что частые выборки опираются на индексы, а не на полный перебор.
- Лишние запросы. Убирают дублирующиеся и избыточные обращения, в том числе в циклах.
- Тяжёлые операции. Оптимизируют или выносят в фон долгие выборки и отчёты.
Оптимизация запросов часто даёт кратный прирост производительности без всякого нового железа. Масштабировать неоптимизированную базу — значит размножать её неэффективность на нескольких серверах и платить за это.
Порядок действий при росте нагрузки
Правильная последовательность масштабирования идёт от дешёвого и простого к дорогому и сложному:
- Измерьте. Найдите реальное узкое место по данным, а не по догадкам.
- Оптимизируйте запросы. Индексы, медленные запросы, лишние обращения.
- Настройте кэш и композит. Снимите с базы массовые чтения.
- Масштабируйте вертикально. Дайте базе более мощное железо, пока это оправдано.
- Введите репликацию. Разделите чтение и запись через веб-кластер.
- Рассмотрите шардинг. Только если упёрлись в запись и объём на действительно больших данных.
Каждый следующий шаг сложнее и дороже предыдущего, поэтому переходят к нему, только исчерпав предыдущий. Как безопасно выкатывать такие инфраструктурные изменения без простоя, мы разбирали в статье про CI/CD и деплой в Битрикс.
Частые ошибки масштабирования
- Масштабируют без измерения. Покупают серверы, не найдя реального узкого места.
- Репликация вместо оптимизации. Размножают неоптимизированную базу вместо починки запросов.
- Игнор отставания реплик. Критичное чтение уходит на slave, клиент видит устаревшие данные.
- Шардинг там, где не нужен. Огромная сложность ради нагрузки, которую сняли бы кэшем.
- Слабый кэш. База завалена запросами, которые должны были браться из кэша.
- Нет индексов. Один тяжёлый запрос кладёт всю базу под нагрузкой.
- Инфоблоки вместо highload. Миллионы однотипных записей тормозят в обычной структуре.
Чек-лист
- Узкое место найдено. Проблема подтверждена данными профилирования, а не догадками.
- Запросы оптимизированы. Медленные запросы, индексы и лишние обращения проработаны.
- Кэш и композит настроены. Массовое чтение снято с базы.
- Вертикаль исчерпана. Мощность сервера БД поднята до разумного предела.
- Веб-кластер настроен. Репликация с разделением чтения и записи работает.
- Отставание учтено. Критичное чтение идёт на master, некритичное — на реплики.
- Highload где нужно. Большие объёмы однотипных данных вынесены в highload-блоки.
- Шардинг обоснован. Вводится только при реальной потребности в масштабировании записи.
Вывод
База данных — типичное узкое место растущего магазина, потому что масштабировать хранилище состояния сложнее, чем серверы приложения. Но паниковать и сразу строить кластеры не нужно: путь масштабирования идёт от дешёвого к дорогому. Сначала измерение и оптимизация запросов, затем кэш и композит, потом более мощное железо — и очень часто на этом всё заканчивается.
Когда оптимизация исчерпана, а нагрузка растёт, в дело вступает репликация через штатный веб-кластер 1С-Битрикс: master пишет, реплики читают, критичное чтение направляется точно. Шардирование и highload-блоки — инструменты для действительно больших объёмов, и вводят их осознанно. Главное правило: не масштабируйте неоптимизированную базу — сначала уберите неэффективность, иначе вы просто оплатите её размножение на нескольких серверах.
