| Цитатник веб-разработчиков.
Антон Долганин:
Новичкам надо поклясться на мануале, что они забудут про прямые запросы, вообще про БД забудут. Когда появится немного опыта и будет казаться что вы зверь в Битриксе - тогда можно почитать о том как происходит общение с БД, но все равно не трогать, подождать еще год-два активной работы с системой. И вот только потом уже можно подружиться с БД полностью, но помнить, что в первую очередь надо всеми правдами и неправдами сделать стандартными методами Битрикс. К БД прибегать только в случае:
- Невозможно сделать стандартно без большой нагрузки на PHP;
- Невозможно сделать стандартно без большой нагрузки на MySQL.
Разработчик должен точно понимать БД. Понимать что изменится, а что нет при ближайшем обновлении.
|
Одним из первых впечатлений, возникающих у начинающего осваивать Bitrix Framework программиста, бывает непонимание запросов к базе данных. Код Bitrix Framework порождает очень большие и не сразу понятные запросы. Несколько экранов не очень понятного SQL традиционно пугают людей, которые редко пишут запросы сложнее select * from ... where id=... и увереных, что объединение таблиц по условиям делается через where так же производительно, как и через on.
Но всё не так просто. Тема работы с БД включает в себя вопросы:
- узкотехнологические, вроде производительности конкретных выборок;
- вопросы удобного применения технологий работы с БД в больших развиваемых проектах на растущей CMS;
- вопросы стоимости владения и поддержки.
Почему в Bitrix Framework запрос получается неудобочитаемым?
В системе есть инфоблоки, где быстро и комфортно создается структура данных. Есть стандартные компоненты, реализующие наиболее распространенные вещи. Есть API, позволяющее отправлять достаточно произвольные запросы. Вы работаете со всем этим, в итоге ваша достаточно высокоуровневая логика выборки превращается в запрос. Генератор запроса, несмотря на свою сложность, выполняет довольно однообразную работу по переводу логики, изложенной на высоком уровне, в обращения к конкретным полям конкретных таблиц по условиям.
В мощных СУБД есть умные и очень эффективные оптимизаторы запросов, а совсем плохие запросы такие СУБД даже не дают исполнять. Подавляющее большинство установок продуктов на Bitrix Framework работают на MySQL, чей оптимизатор достаточно слаб. В итоге мы имеем большие запросы, ограниченные средства их изменения с сохранением логики, и механизмы кеширования поверх всего этого.
Минус такого положения дел
Сложные запросы очень велики и вы почти не можете влиять на их структуру. Даже если есть желание заняться их профилировкой и отладкой, вы фактически ограничены теми не слишком богатыми средствами изменения запроса, которые предлагает Bitrix Framework. Вы не можете:
- изменять порядок объединений;
- задавать специфические условия на выборки;
- создавать локальные кеширующие временные таблицы.
Плюсы такого положения дел
Плюсы оказываются важнее, чем минусы:
- Запросы не надо писать руками. Создание проекта на Bitrix Framework обычно предусматривает визуальную настройку готовых компонентов, создании структуры сайта и интеграцию дизайна. Не в каждом проекте приходится кастомизировать компоненты, но даже эта работа не заставляет писать запросы.
- Безопасность. Обертки над запросами решают задачу защиты от атак или глупостей разработчика.
Квалификация разработчика
Как и в любом другом деле, всё решает профессионализм работы с Bitrix Framework. И мастерство работы с БД не играет существенной роли. Объективно в большинстве проектов нагрузка на sql (время исполнения) несущественна по сравнению с нагрузкой на процессор и затратами на интерпретацию скриптов. Тормозит не MySQL, а PHP.
В связи с этим огромную роль играет правильность проектирования структуры данных, выбор связей и их реализация средствами системы инфоблоков или таблиц. Устранить "тормоза" на проекте гораздо правильнее и эффективнее грамотным проектированием, чем оптимизацией запроса, который Bitrix Framework генерирует по вашим указаниям.
Использование кеширования позволяет сэкономить на времени исполнения запросов. Грамотное распределение логики по компонентам позволяет вообще их не вызывать. Есть правило: главная страница сайта (обычно не самая простая) не должна отправлять запросы к БД при включенном кеше.
Разработчик должен учитывать специфику проекта и правильно выбирать тип таблиц: InnoDB или MyISAM .
Разработчик должен уметь оценивать уровень задач. Для действительно серьезных проектов есть кластеризация My SQL.
Что есть в Bitrix Framework для облегчения жизни простого программиста?
Перед началом работ по оптимизации проектов воспользуйтесь Монитором производительности для поиска узких мест на сайте.
В составе административной части системы есть инструменты проверки БД и её оптимизации. Эти действия автоматизированы и вмешательство разработчика в них исключено.
Используйте инфоблоки 2.0. Это включаемый галочкой в административном разделе режим работы инфоблока, когда его поля переносятся в отдельную таблицу. Но у них есть свои особенности, которые надо знать и учитывать.
Используйте настраиваемую из административной части кластеризацию БД на стандартных механизмах MySQL.
Используйте специфические для вашего проекта индексы. Большой запрос не всегда синоним долгого исполнения. Возьмите тяжелый запрос из системы и сделайте explain в консоли. Вы удивитесь как хорошо он покрыт индексами и как мало там будет циклических переборов записей.
| Цитатник веб-разработчиков.
Денис Шаромов: Есть миф, что длинный запрос долго исполняется. В действительности, всё зависит от того, какой объем данных приходится обработать базе для исполнения запроса. Разбор собственно запроса занимает ничтожно малую часть времени. Основное время занимает фильтрация и сортировка. Время фильтрации зависит от параметров фильтра и индексов, а сортировка - от числа записей в выборке. |
Работа с БД
Перед тем как начать работать с БД усвойте, что:
Внимание! Прямое обращение к базе данных в рамках Bitrix Framework не приветствуется. Более того, если речь идет о системных таблицах самого Bitrix Framework, это не просто не приветствуется, это не поддерживается. Необходимо с ними работать через API системы, так как физическая структура БД может измениться, а работа даже самого древнего API гарантирована.
В силу этого предупреждения названия таблиц не афишируются. Если, все же, вы возьмёте на себя ответственность прямой работы с базой данных, то учтите, что все таблицы от Bitrix Framework начинаются с b_. Соответственно ваши префиксы должны быть другими: необходимо чтобы имена ваших таблиц не пересеклись с битриксовыми. Вполне возможна ситуация, когда в новых обновлениях появится таблица с таким же именем, как и созданная вами (если вы используете префикс b_). В лучшем случае обновление не установится.
Для работы с собственными таблицами используйте методы глобальной переменной $DB (класс CDatabase).
Детально об оптимизации БД читайте в главе Оптимизация базы данных Курса для хостеров.
Список ссылок по теме:
