Заказчик редко видит базу данных, но именно она решает, откроется ли каталог из 50 000 товаров за полсекунды или за шесть, переживёт ли сайт сбой сервера и сможет ли магазин через два года подключить новые сценарии без переделки. Мы не будем учить вас писать SQL-запросы. Задача этой статьи — дать владельцу сайта достаточно понимания, чтобы задавать подрядчику правильные вопросы и не платить за ошибки, которые проще предотвратить на старте.
Что хранится в базе данных сайта
Почти любой современный сайт, кроме чисто статических, состоит из двух частей: кода, который определяет логику и внешний вид, и данных, с которыми этот код работает. Данные хранятся в базе. Для корпоративного сайта это тексты страниц, новости, заявки из форм, учётные записи администраторов. Для интернет-магазина список гораздо длиннее: товары и их свойства, цены по типам покупателей, остатки по складам, заказы, клиенты, корзины, отзывы, промокоды, история изменения статусов.
Объём быстро растёт. Каталог на 10 000 товаров с 30 свойствами у каждого — это уже 300 000 записей только о характеристиках. Добавьте несколько лет заказов, журналы обменов с 1С, сохранённые корзины, и база магазина среднего размера легко достигает десятков гигабайт. При этом сайт должен за доли секунды находить в этом массиве нужные товары по десятку фильтров одновременно.
Отсюда главный тезис: база данных — не пассивное хранилище, а активный компонент, от настройки которого напрямую зависит скорость и надёжность всего проекта. Ошибки в её проектировании обходятся дороже ошибок в дизайне, потому что исправлять их приходится на живых данных.
Какие бывают базы данных
Для веб-проектов используется несколько типов СУБД — систем управления базами данных. Выбор обычно определяется платформой: большинство CMS работают с конкретной базой, и менять её нет смысла. Но для заказных проектов на фреймворках выбор есть, и он имеет значение.
MySQL и MariaDB
Стандарт для WordPress, 1С-Битрикс, OpenCart и большинства хостингов. Хорошо изучены, просты в администрировании, отлично справляются с типовыми сайтами и магазинами.
PostgreSQL
Мощная реляционная СУБД с богатыми возможностями: сложные запросы, полнотекстовый поиск, работа с JSON и геоданными. Наш частый выбор для заказных проектов на Laravel.
Redis и поисковые движки
Вспомогательные хранилища: Redis держит кеш и сессии в памяти, а Elasticsearch или аналоги обеспечивают быстрый поиск с морфологией и подсказками.
Важно понимать, что крупный сайт почти никогда не живёт на одной базе. Основные данные хранятся в реляционной СУБД, кеш и очереди задач — в Redis, поисковый индекс — в отдельном движке. Каждый инструмент делает то, что умеет лучше всего. Попытка заставить MySQL выполнять полнотекстовый поиск по 100 000 товаров с учётом опечаток работает, но медленно и посредственно по качеству.
Реляционные и документные базы
Иногда разработчики предлагают документные базы вроде MongoDB, аргументируя гибкостью: товары с разными наборами характеристик удобно хранить как документы. Для отдельных задач это действительно удобно, но для типового магазина с заказами, оплатами и остатками реляционная база надёжнее: она гарантирует целостность данных и согласованность транзакций. Списание остатка и создание заказа должны произойти вместе или не произойти вовсе. Современные PostgreSQL и MySQL при этом умеют хранить гибкие наборы свойств в JSON-полях, сочетая плюсы обоих подходов.
От чего зависит скорость базы
Когда сайт тормозит, в большинстве случаев, которые мы разбираем при аудитах, причина именно в базе: медленные запросы, отсутствие индексов, неудачная структура таблиц. Мощность сервера здесь вторична — неоптимальный запрос, перебирающий миллион строк, будет медленным и на дорогом железе.
Индексы
Индекс — это аналог алфавитного указателя в книге. Без него база, чтобы найти все товары бренда «Альфа» дешевле 5 000 ₽, просматривает каждую строку таблицы. С индексом — сразу переходит к нужным записям. На таблице в 200 000 строк разница составляет порядка сотен раз: 800 мс против 3 мс. Типичная ситуация: при разработке на тестовой базе из сотни товаров всё летало, а после загрузки реального каталога фильтр стал открываться по четыре секунды. Добавление трёх составных индексов решило проблему за полчаса.
Структура данных
Классическая проблема 1С-Битрикс и WooCommerce — хранение свойств товаров в универсальной таблице «сущность — атрибут — значение». Это гибко, но каждый фильтр превращается в множество объединений таблиц. Поэтому в Битриксе для больших каталогов включают отдельное хранение свойств в собственных таблицах инфоблока и фасетный индекс, а в WooCommerce используют специализированные таблицы для поиска товаров. Эти настройки нужно делать до наполнения каталога: перестраивать структуру на 50 000 товаров дольше и рискованнее.
Количество запросов на страницу
Ещё одна частая беда — так называемая проблема N+1. Страница списка из 24 товаров делает один запрос за списком и ещё по одному на каждый товар за картинкой, ценой и наличием — итого 73 запроса вместо трёх. Каждый по отдельности быстрый, но вместе они дают сотни миллисекунд. Хороший разработчик видит это в профилировщике и группирует запросы. Результаты повторяющихся тяжёлых вычислений дополнительно кладутся в кеш, о чём мы подробно писали в статье про кеширование и CDN.
| Симптом | Вероятная причина в базе | Что делаем |
|---|---|---|
| Фильтр каталога открывается дольше 2 секунд | Нет индексов по свойствам, универсальная таблица атрибутов | Индексы, фасетный поиск, отдельное хранение свойств |
| Сайт тормозит во время обмена с 1С | Блокировки таблиц при массовом обновлении | Обновление порциями, обмен в часы низкой нагрузки |
| Админка заказов открывается минуту | Огромные журналы и неочищенные служебные таблицы | Архивация старых данных, очистка логов |
| Периодические провалы скорости | Не хватает памяти, база читает с диска | Настройка буферов, объёма памяти под базу |
| Поиск находит не то или медленно | Поиск через LIKE по всей таблице | Отдельный поисковый движок с морфологией |
Рост данных и масштабирование
Сайт, спроектированный на 1 000 товаров и 20 заказов в день, может спокойно работать годами. Но если бизнес растёт, наступает момент, когда база перестаёт справляться. Хорошая новость: для подавляющего большинства проектов малого и среднего бизнеса до настоящих пределов СУБД очень далеко. Один правильно настроенный сервер MySQL или PostgreSQL обслуживает магазины с сотнями тысяч товаров и тысячами заказов в день.
Проблемы роста обычно лежат в другом. Таблицы журналов, которые никто не чистит, разрастаются до десятков гигабайт и замедляют резервное копирование. Сохранённые корзины анонимных посетителей копятся миллионами. Таблица просмотренных товаров, задуманная для рекомендаций, оказывается больше самого каталога. Мы закладываем на старте политику хранения: что и сколько живёт, что архивируется, что удаляется по расписанию.
Когда нагрузка действительно растёт, первый шаг масштабирования — вынос базы на отдельный сервер, второй — реплики для чтения: копии базы, с которых сайт читает каталог, разгружая основную, принимающую заказы. До шардирования, то есть разделения данных на несколько независимых серверов, проекты нашего масштаба практически никогда не доходят, и если подрядчик предлагает его для магазина на 5 000 товаров, это повод насторожиться.
Надёжность: резервные копии и восстановление
Код сайта можно восстановить из репозитория, дизайн — из макетов. А заказы за последнюю неделю, база клиентов и накопленные отзывы существуют только в базе данных. Её потеря — самый тяжёлый сценарий для бизнеса, и защищаться от него нужно заранее.
Минимальный стандарт, который мы настраиваем на всех проектах на поддержке: ежедневная полная копия базы, хранение копий не менее 14–30 дней, хранение в другом дата-центре, а не на том же сервере, и регулярная проверка восстановления. Последний пункт важнее, чем кажется: мы не раз встречали ситуации, когда бэкапы годами создавались, но оказывались повреждёнными или неполными, и узнавали об этом в день аварии. Для магазинов с активными продажами добавляем непрерывное резервирование журнала транзакций, которое позволяет восстановить базу на любую минуту, а не только на момент ночной копии. Подробнее — в статье о резервном копировании.
Безопасность и персональные данные
База данных магазина содержит персональные данные покупателей: имена, телефоны, адреса, история покупок. По 152-ФЗ «О персональных данных» их обработка накладывает на компанию обязательства, в том числе по хранению данных российских граждан на серверах в России и по защите от несанкционированного доступа. Утечка базы клиентов — это и штрафы, и удар по репутации.
Базовые меры защиты не требуют больших затрат. База не должна быть доступна из интернета напрямую — только с сервера сайта. У приложения свой пользователь с минимально необходимыми правами, а не общий администратор. Пароли покупателей хранятся только в виде стойких хешей. Все запросы к базе формируются через параметризацию, что исключает SQL-инъекции — до сих пор одну из самых распространённых уязвимостей. Копии базы для тестирования и разработки обезличиваются. Доступ к рабочей базе есть у ограниченного круга людей, и каждый такой доступ фиксируется.
Вопросы, которые стоит задать подрядчику
Чтобы оценить, насколько ответственно подрядчик относится к работе с данными, не нужно быть техническим специалистом. Достаточно задать несколько вопросов и послушать, насколько конкретны ответы.
Какая СУБД будет использоваться и почему именно она?
Хороший ответ связывает выбор с платформой и задачами проекта. «Потому что мы всегда так делаем» без объяснений — слабый ответ.
Как будет проверяться скорость на реальном объёме данных?
Правильно — тестировать на копии рабочего каталога или на сгенерированных данных сопоставимого объёма, а не на десятке демонстрационных товаров.
Как устроено резервное копирование и когда последний раз проверялось восстановление?
Ждём конкретики: частота, срок хранения, место хранения, регулярность тестового восстановления.
Кто имеет доступ к базе с данными наших клиентов?
Ответ должен включать перечень ролей и способ контроля доступа, а копии для разработки — быть обезличены.
Сможем ли мы при необходимости забрать данные?
Да, в виде полного дампа базы. Данные принадлежат вам, и любой подрядчик обязан их передать.
Если вы планируете крупную интеграцию с учётной системой или CRM, вопросы о базе тем более важны: обмен создаёт основную нагрузку на данные. Такие проекты мы ведём в рамках услуги интеграции с 1С и CRM, где проектирование хранения данных — отдельный этап.
Что запомнить
База данных определяет скорость, надёжность и возможности роста сайта сильнее, чем кажется со стороны. Большинство проблем со скоростью решается не покупкой более мощного сервера, а индексами, правильной структурой хранения и сокращением лишних запросов. Для поиска и кеша стоит использовать специализированные инструменты, а не нагружать основную базу.
Данные — самый ценный и самый невосстановимый актив сайта. Ежедневные проверенные резервные копии в другом дата-центре, закрытый доступ, обезличенные тестовые копии и соблюдение 152-ФЗ — обязательный минимум. Задайте подрядчику вопросы из этой статьи: конкретные и спокойные ответы — лучший признак того, что вашими данными занимаются профессионалы.
Нужен сайт или интернет-магазин?
Обсудим задачу, подскажем подходящую платформу и оценим сроки и бюджет — бесплатно и без обязательств.
Обсудить проект
