Много запросов к БД через activeRecord

Общие вопросы по использованию второй версии фреймворка. Если не знаете как что-то сделать и это про Yii 2, вам сюда.
Ответить
Vadim7423
Сообщения: 59
Зарегистрирован: 2016.07.07, 20:21

Много запросов к БД через activeRecord

Сообщение Vadim7423 »

Здравствуйте. Работаю над проектом, в котором на некоторых интерактивных страницах идет по 80 - 90 запросов к БД. Кеширование использовать в полную меру нет возможности. СУБД mysql.
На сколько это критично? Или проект нормально будет жить при большом количестве посещений? Или стоит задуматься над рефакторингом и сменой СУБД?
Аватара пользователя
ElisDN
Сообщения: 5845
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Много запросов к БД через activeRecord

Сообщение ElisDN »

Жадную загрузку связей сделайте.
kukuruku
Сообщения: 1318
Зарегистрирован: 2011.02.14, 11:36

Re: Много запросов к БД через activeRecord

Сообщение kukuruku »

и добавить индексы
Arhat109
Сообщения: 61
Зарегистрирован: 2016.11.23, 09:06
Откуда: из СССР

Re: Много запросов к БД через activeRecord

Сообщение Arhat109 »

Для показа сложных сущностей из БД, кмк, проще и эффективней переходить от модели ActiveRecord к Rowset с выборкой и "расфасовкой на лету" по объектам. Тогда количество запросов к БД можно существенно уменьшить.

Как пример, мое применение в СУБД "туристов": есть "заявка (на тур)", к ней идут "туристы(персоны)", к каждому "билеты" (даты, а/п вылета, назначения и т.д.) и "документы (паспорта, визы)" .. все это обрамлено типовыми "автор записи(менеджер)", "модератор(часто онже, но не всегда)", дата создания, правки, "живость и пр. состояния" записи...

Надо показать список заявок менеджера, которые скажем вылетают завтра компанией S7 в "Таиланд" (там несколько а/п), ну и соответственно "хто последний тут нагадил, пардон правил все это?" .. как видим, нам нужен сложный результирующий Rowset, а вовсе не "массив записей".

В итого 1 сложный запрос со всеми условиями и кучей джойнов .. решает проблему на 146%, причем самым шустрым способом, ибо выборка, отфильтровка и выдача полезного - все сосредоточено на Скуле.
И далее, типовым методом (один раз сделать) выдираем все иденты "авторов, модераторов, туристов" ибо это все "персоны" (хоть и пользователи, менеджеры - сами летают тоже) и вторым запросом получаем список желаемого для всех сразу и один.

На лицо: экономия кода, времени исполнения, нагрузки на сеть если это разные сервера (СУБД и фронт/бэк), расширяемость и коррекция кода - все решается ровно в одном месте, экономия памяти (и как следствие времени исполнения дополнительно).

На связке Сервер СУБД - 24-х проц + 96 гектар ОЗУ (основной) и фронт (виртуалка там же), запрос к 40 тысячам заявок, в среднем по 3.7 персоны, летавших в среднем в 1.8 мест, с документами, билетами и т.д. Отбор по условиям выше исполняется за около 200мсек, и вся страница отдается клиенту (менеджеру) не дольше 0.5мсек с пересылкой по VPN через 2 шлюза т.к. "не весит ничего" (прямой вид HTML без ангуляров, виджетов и пр.).. Предыдущий вариант, через ActiveRecord на в 10 раз меньшей базе и том же железе отдавал контент примерно за 2сек (в среднем 150 запросов к БД на страницу), и ангуляр разворачивал его на клиенте ещё 3-8секунд (динамические дозапросы "хто тут афттар").
Что называется ощутите разницу.

Как-то так.
Все чаще Историки находят следы древней и очень высокоразвитой Цивилизации, со странными буквами .. СССР
skynin
Сообщения: 400
Зарегистрирован: 2017.12.12, 10:09

Re: Много запросов к БД через activeRecord

Сообщение skynin »

Vadim7423 писал(а): 2020.09.24, 20:27 Здравствуйте. Работаю над проектом, в котором на некоторых интерактивных страницах идет по 80 - 90 запросов к БД.
Это немного.
Обычная история когда запросы генерит ORM, любой, без всякого тюнинга - и пара сотен :)
Vadim7423 писал(а): 2020.09.24, 20:27 Кеширование использовать в полную меру нет возможности. СУБД mysql.
В зависимости от соотношения запросов на чтение/запись, а также от уникальности самих запросов
Настройте встроенный или внешний query_cache
Из MySQL 8 его выпилили, в MariaDB остался

Решает проблемы в большинстве случаев типичных веб проектов.
Vadim7423 писал(а): 2020.09.24, 20:27 На сколько это критично?
Никто не скажет кроме вас, насколько ваших пользователей, заказчика не удовлетворяет скорость работы сайта.

Типичные сайты на WP запросто генерят и за 1к запросов, и - никому не критично: ни их пользователям, ни разработчикам этих сайтов.

Критично настолько, насколько это критично вашему проекту.
Vadim7423 писал(а): 2020.09.24, 20:27 Или проект нормально будет жить при большом количестве посещений?
Большом - это сколько цифрами?
Какой хостинг?
и т.п.

Для приближения к точному ответу требуется провести нагрузочное тестирование.

Вписывать цифры нагрузки для домена "mail.ru" - неразумно.
Vadim7423 писал(а): 2020.09.24, 20:27 Или стоит задуматься над рефакторингом и сменой СУБД?
Работу в режиме key-value хранилища не любит ни одна реляционная БД.
Хоть Oracle купите

Если не моможет query_cache(ProxySQL), жадная загрузка, кеширование, то да, можно задумываться о рефакторинге
Пример привел Arhat109

Суть:
Поручите работу той части системы, которая для этого предназначена.
Для обработки данных предназначен - сервер БД

"Расскажите ему" поподробнее что-вы хотите получить в итоге, а не шлите короткие простые запросы, постоянно "не договаривая" что же вы хотите. Никакой Postgress не сможет по таким мелким запросам использовать очень серьезные алгоритмы по оптимизации их выполения.

а НЕ используйте его в качестве key-value хранилища.
ORMы, и даже методы проектирования типа DDD используют сервер БД именно так, в самом невыгодном, "тупом" для него режиме.

Возможно вам придется перепроектировать работу с данными вообще, и пойти не от моделей, а от схемы БД, спроектировать ее вручную под будущие запросы.
то есть двигаться в сторону Anemic model. Нередкая история с ростом нагрузки.

Реализация паттерна ActiveRecord в Yii этому не препятствует.
С Doctrine такое перепроектирование куда дороже.

Ну и конечно, для такого рефакторинга надо хорошо знать как SQL так и тонкости работы БД
Не желайте странного, и не будет у вас головной боли чтобы достичь этого странного.
Тем более что окажется что оно вам и не нужно было, странное это.
Ответить