Здравствуйте. Работаю над проектом, в котором на некоторых интерактивных страницах идет по 80 - 90 запросов к БД. Кеширование использовать в полную меру нет возможности. СУБД mysql.
На сколько это критично? Или проект нормально будет жить при большом количестве посещений? Или стоит задуматься над рефакторингом и сменой СУБД?
Много запросов к БД через activeRecord
Re: Много запросов к БД через activeRecord
Жадную загрузку связей сделайте.
Re: Много запросов к БД через activeRecord
и добавить индексы
Re: Много запросов к БД через activeRecord
Для показа сложных сущностей из БД, кмк, проще и эффективней переходить от модели 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секунд (динамические дозапросы "хто тут афттар").
Что называется ощутите разницу.
Как-то так.
Как пример, мое применение в СУБД "туристов": есть "заявка (на тур)", к ней идут "туристы(персоны)", к каждому "билеты" (даты, а/п вылета, назначения и т.д.) и "документы (паспорта, визы)" .. все это обрамлено типовыми "автор записи(менеджер)", "модератор(часто онже, но не всегда)", дата создания, правки, "живость и пр. состояния" записи...
Надо показать список заявок менеджера, которые скажем вылетают завтра компанией S7 в "Таиланд" (там несколько а/п), ну и соответственно "хто последний тут нагадил, пардон правил все это?" .. как видим, нам нужен сложный результирующий Rowset, а вовсе не "массив записей".
В итого 1 сложный запрос со всеми условиями и кучей джойнов .. решает проблему на 146%, причем самым шустрым способом, ибо выборка, отфильтровка и выдача полезного - все сосредоточено на Скуле.
И далее, типовым методом (один раз сделать) выдираем все иденты "авторов, модераторов, туристов" ибо это все "персоны" (хоть и пользователи, менеджеры - сами летают тоже) и вторым запросом получаем список желаемого для всех сразу и один.
На лицо: экономия кода, времени исполнения, нагрузки на сеть если это разные сервера (СУБД и фронт/бэк), расширяемость и коррекция кода - все решается ровно в одном месте, экономия памяти (и как следствие времени исполнения дополнительно).
На связке Сервер СУБД - 24-х проц + 96 гектар ОЗУ (основной) и фронт (виртуалка там же), запрос к 40 тысячам заявок, в среднем по 3.7 персоны, летавших в среднем в 1.8 мест, с документами, билетами и т.д. Отбор по условиям выше исполняется за около 200мсек, и вся страница отдается клиенту (менеджеру) не дольше 0.5мсек с пересылкой по VPN через 2 шлюза т.к. "не весит ничего" (прямой вид HTML без ангуляров, виджетов и пр.).. Предыдущий вариант, через ActiveRecord на в 10 раз меньшей базе и том же железе отдавал контент примерно за 2сек (в среднем 150 запросов к БД на страницу), и ангуляр разворачивал его на клиенте ещё 3-8секунд (динамические дозапросы "хто тут афттар").
Что называется ощутите разницу.
Как-то так.
Все чаще Историки находят следы древней и очень высокоразвитой Цивилизации, со странными буквами .. СССР
Re: Много запросов к БД через activeRecord
Это немного.
Обычная история когда запросы генерит ORM, любой, без всякого тюнинга - и пара сотен
В зависимости от соотношения запросов на чтение/запись, а также от уникальности самих запросов
Настройте встроенный или внешний query_cache
Из MySQL 8 его выпилили, в MariaDB остался
Решает проблемы в большинстве случаев типичных веб проектов.
Никто не скажет кроме вас, насколько ваших пользователей, заказчика не удовлетворяет скорость работы сайта.
Типичные сайты на WP запросто генерят и за 1к запросов, и - никому не критично: ни их пользователям, ни разработчикам этих сайтов.
Критично настолько, насколько это критично вашему проекту.
Большом - это сколько цифрами?
Какой хостинг?
и т.п.
Для приближения к точному ответу требуется провести нагрузочное тестирование.
Вписывать цифры нагрузки для домена "mail.ru" - неразумно.
Работу в режиме key-value хранилища не любит ни одна реляционная БД.
Хоть Oracle купите
Если не моможет query_cache(ProxySQL), жадная загрузка, кеширование, то да, можно задумываться о рефакторинге
Пример привел Arhat109
Суть:
Поручите работу той части системы, которая для этого предназначена.
Для обработки данных предназначен - сервер БД
"Расскажите ему" поподробнее что-вы хотите получить в итоге, а не шлите короткие простые запросы, постоянно "не договаривая" что же вы хотите. Никакой Postgress не сможет по таким мелким запросам использовать очень серьезные алгоритмы по оптимизации их выполения.
а НЕ используйте его в качестве key-value хранилища.
ORMы, и даже методы проектирования типа DDD используют сервер БД именно так, в самом невыгодном, "тупом" для него режиме.
Возможно вам придется перепроектировать работу с данными вообще, и пойти не от моделей, а от схемы БД, спроектировать ее вручную под будущие запросы.
то есть двигаться в сторону Anemic model. Нередкая история с ростом нагрузки.
Реализация паттерна ActiveRecord в Yii этому не препятствует.
С Doctrine такое перепроектирование куда дороже.
Ну и конечно, для такого рефакторинга надо хорошо знать как SQL так и тонкости работы БД
Не желайте странного, и не будет у вас головной боли чтобы достичь этого странного.
Тем более что окажется что оно вам и не нужно было, странное это.
Тем более что окажется что оно вам и не нужно было, странное это.