Когда уместен Active Record в Yii 2
22 июля 2016
В комментариях к посту про модули Дмитрий задал вопросы про AR.
Объем записей в таблицах от 500к, почти каждый запрос это 2-3 JOINa. Раньше делал через геттеры AR, выборка за раз порядка 100 записей. Но заметил такую штуку, что если использовать createCommand, то память заметно меньше расходуется и скорость быстрее. К сожалению, сейчас не могу показать реальные тесты, так как тестировали это месяц назад, но в итоге, большую часть моделей мы переписали на DAO, отказавшись от AR.
Память уходит на хранение данных в объектах. Скорость теряется из за необходимости эти объекты инстанциировать.
Так, так ли плох AR или его использование подходит для небольших проектов? У нас также постоянно идет вставка, порядка 5000 записей в час. Пока для этого используем AR.
Когда использование AR уместно, а когда нет?
AR отлично подходит для удаления, обновления или добавления небольшого количества записей по одной за раз. Чрезвычайно удобно. К тому же, поддержка dirty attributes, то есть сохранения только того, что изменилось, позволяет хорошо разгрузить базу данных и скрыть до лучших времён многие моменты при параллельном редактировании. Если у вас в приложении нет сильно сложной логики и не требуется дополнительных абстракций для сущности, то AR для этого подходит идеально.
Для простых выборок с целью отображения до сотни записей на страницу, в принципе, AR тоже подходит. Да, с массивами через query builder или с asArray() получается быстрее и меньше кушает памяти, но работать с ними не столь удобно.
Для сложных выборок AR не рекомендуется. Сложные выборки у нас обычно возвращают какие-либо агрегаты или преобразованные данные, которые ну никак не вписываются в изначальную модель AR. В этом случае лучше делать выборки через query builder.
Для импорта-экспорта также лучше использовать query builder.
Комментарии RSS по email OK
Ну что тут скажешь =) каждый через это проходит. Сначала AR и возгласы "О как круто и легко" а потом наколбасят на этой AR и аналитику и ивенты воткнут там где надо и не надо. В конце концов модели станут бизнес и инфраструктурным слоем. Тоолстым таким слоем.
Ну и соответственно, если не было тестов, изменение всего этого становится для многих очень страшным и медленным процессом.
RusAlex, и это вполне нормально :) на самом деле для определенной доли проектов стандартные crud\ar и вообще подход yii очень круто вписывается и вызывает "вау" эффект. А потом начинаешь сталкиваться с проблемами по мере роста проекта и начинает приходить опыт и понимание многих "глубоких" вещей. Каждый через это проходит.
Александр, я ждал эту статью! Спасибо огромное.
Я вот кстати дополню, век живи, век учись как говориться. Раньше городил свой велосипед, для batchInsert, потом понял, что что-то не то, посмотрел доку - оказывается, batchInsert есть в Yii. Но к сожалению, я так и не нашел batchInsert по кускам, например есть массив в 500 элементов, но нужно вставить 100, 200, 300 записей за раз. Пришлось снова велосипедить :)
Вообще для себя взял за правило - избегать любых SELECTов с помощью AR, по возможности держусь поближе к PDO, одиночные Insert делаю через AR, одиночные апдейты делаю также через AR, все остальное через createCommand и batchInsert.
Вообще AR на своей шкуре испытал, когда все не очень как-то и быстро оказалось.
Источник многих бед - преждевременная оптимизация. К тому же проекту на старте зачастую необходим быстрый рост функционала, и удобный AR этому способствует. Я считаю, что проблемы необходимо решать по мере их поступления (если ты нашел ошибку до её возникновения, это значит, что проблема возникла, и её нужно решить, но тебе повезло - ты отделался минимальными потерями). У меня, например, аналитика написана не просто на AR, а на миксе AR и CDbCriteria. Магия происходит когда две критерии объединяются. Имплементированные кастомные интерфейсы для подклассов AR позволяют получать модели со структурой для построения разных графиков. Один компонент класс собрал все методы для получения всех аналитических данных, но сама критерия собирается в подклассе каждой отдельной модели. Компонент выгядит аккуратным, работает автодополнение IDE для результатов, а результат можешь получить в любом месте приложения. Поддерживать такой код очень просто. Да, у меня нет в MySQL данных для больших выборок, они храняться в другой БД.
просто подписался =)
Анатолий, согласен. Сам все писал на AR, но когда проект стал большим, начал переписывать на чистом SQL.
но чистый SQL тоже станет однажды проблемой =)
Если использовать preparedStatement, знать, что будет точно MySQL, то вряд ли. Единственный минус для меня - не люблю писать SQL запросы, плюсы - большая гибкость и скорость.
Дмитрий, ну это тоже крайность. Как построить запрос, когда в зависимости от условия разный селект полей и есть группировка? Как разбить запрос с джоинами в зависимости от условий? Чистым sql сложно построить универсальный запрос.
AR - очень удобная штука, и стоит всегда помнить что преждевременная оптимизация - зло.
Александр, для таких целей я использую Query)
понастроят черт пойми чего, не разобравшись, что именно у них вообще работает под капотом, а потом жалуются
года через четыре еще про nosql узнает
Фуф) я думал со мной что-то не так) За статью спасибо! Etki, так mongodb уже поддерживается ;)
Это уже какие-то крайности :) Кто-то обжегся на сырых запросах, и теперь всегда использует AR. Кто-то завалился на AR и теперь всегда использует только QueryBuilder. Еще кто-то споткнулся о MySQL и теперь агитирует только за NoSQL...
В общем все как всегда :)
Правда в том, что единой методы нет и не будет. Всегда нужно исходить из специфики проекта и только так. Собственно, что и пишет в статье автор.
О чем тут еще говорить, не понятно.
У нас статистика через AR выбирается в mysql порядко 70гб агрегированных данных быстро работает в рамках 1 дня быстро если недели 2 взять то долго это по 8М записей mysql группировать сложно ( ну это уже сам mysql тупит) Все это дело скрипт кушает оперативку под 101мб+/-. с рендером, если включен еще у колонок grid html то все 150мб будут точно + тормоза (рекомендую не включать у вывода колонок такой способ, если вы на 100% уверены что там все безопасно, это повысит рендер таблицы в 10+ и более раз)
Сейчас переехали на clickhouse, я пока доволен работой и скоростью которую он делает на QBuilder/DAO Изменения причем минимальные потребовались для нативного Yii QueryBuilder допилить.