<rmcreative>

RSS

Когда уместен 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

  1. №10587
    RusAlex
    RusAlex 22.07.2016, 8:32:21

    Ну что тут скажешь =) каждый через это проходит. Сначала AR и возгласы "О как круто и легко" а потом наколбасят на этой AR и аналитику и ивенты воткнут там где надо и не надо. В конце концов модели станут бизнес и инфраструктурным слоем. Тоолстым таким слоем.

    Ну и соответственно, если не было тестов, изменение всего этого становится для многих очень страшным и медленным процессом.

  2. №10588
    Алексей Sc
    Алексей Sc 22.07.2016, 10:31:22

    RusAlex, и это вполне нормально :) на самом деле для определенной доли проектов стандартные crud\ar и вообще подход yii очень круто вписывается и вызывает "вау" эффект. А потом начинаешь сталкиваться с проблемами по мере роста проекта и начинает приходить опыт и понимание многих "глубоких" вещей. Каждый через это проходит.

  3. №10589
    Дмитрий
    Дмитрий 22.07.2016, 10:39:14

    Александр, я ждал эту статью! Спасибо огромное.

  4. №10590
    Дмитрий
    Дмитрий 22.07.2016, 10:48:50

    Я вот кстати дополню, век живи, век учись как говориться. Раньше городил свой велосипед, для batchInsert, потом понял, что что-то не то, посмотрел доку - оказывается, batchInsert есть в Yii. Но к сожалению, я так и не нашел batchInsert по кускам, например есть массив в 500 элементов, но нужно вставить 100, 200, 300 записей за раз. Пришлось снова велосипедить :)

    Вообще для себя взял за правило - избегать любых SELECTов с помощью AR, по возможности держусь поближе к PDO, одиночные Insert делаю через AR, одиночные апдейты делаю также через AR, все остальное через createCommand и batchInsert.

    Вообще AR на своей шкуре испытал, когда все не очень как-то и быстро оказалось.

  5. №10591
    Анатолий
    Анатолий 22.07.2016, 11:32:40

    Источник многих бед - преждевременная оптимизация. К тому же проекту на старте зачастую необходим быстрый рост функционала, и удобный AR этому способствует. Я считаю, что проблемы необходимо решать по мере их поступления (если ты нашел ошибку до её возникновения, это значит, что проблема возникла, и её нужно решить, но тебе повезло - ты отделался минимальными потерями). У меня, например, аналитика написана не просто на AR, а на миксе AR и CDbCriteria. Магия происходит когда две критерии объединяются. Имплементированные кастомные интерфейсы для подклассов AR позволяют получать модели со структурой для построения разных графиков. Один компонент класс собрал все методы для получения всех аналитических данных, но сама критерия собирается в подклассе каждой отдельной модели. Компонент выгядит аккуратным, работает автодополнение IDE для результатов, а результат можешь получить в любом месте приложения. Поддерживать такой код очень просто. Да, у меня нет в MySQL данных для больших выборок, они храняться в другой БД.

  6. №10592
    RusAlex
    RusAlex 22.07.2016, 12:56:13

    просто подписался =)

  7. №10593
    Дмитрий
    Дмитрий 22.07.2016, 13:12:19

    Анатолий, согласен. Сам все писал на AR, но когда проект стал большим, начал переписывать на чистом SQL.

  8. №10594
    RusAlex
    RusAlex 22.07.2016, 13:13:45

    но чистый SQL тоже станет однажды проблемой =)

  9. №10595
    Дмитрий
    Дмитрий 22.07.2016, 13:35:45

    Если использовать preparedStatement, знать, что будет точно MySQL, то вряд ли. Единственный минус для меня - не люблю писать SQL запросы, плюсы - большая гибкость и скорость.

  10. №10596
    Александр
    Александр 22.07.2016, 21:58:51

    Дмитрий, ну это тоже крайность. Как построить запрос, когда в зависимости от условия разный селект полей и есть группировка? Как разбить запрос с джоинами в зависимости от условий? Чистым sql сложно построить универсальный запрос.

  11. №10598
    Александр
    Александр 23.07.2016, 10:07:57

    AR - очень удобная штука, и стоит всегда помнить что преждевременная оптимизация - зло.

  12. №10599
    Дмитрий
    Дмитрий 23.07.2016, 10:50:19

    Александр, для таких целей я использую Query)

  13. №10602
    Etki
    Etki 28.07.2016, 16:24:59

    понастроят черт пойми чего, не разобравшись, что именно у них вообще работает под капотом, а потом жалуются

    года через четыре еще про nosql узнает

  14. №10605
    Константин
    Константин 01.08.2016, 10:50:23

    Фуф) я думал со мной что-то не так) За статью спасибо! Etki, так mongodb уже поддерживается ;)

  15. №10607
    iiifx
    iiifx 01.08.2016, 15:34:39

    Вообще для себя взял за правило - избегать любых SELECTов с помощью AR, по возможности держусь поближе к PDO

    Это уже какие-то крайности :) Кто-то обжегся на сырых запросах, и теперь всегда использует AR. Кто-то завалился на AR и теперь всегда использует только QueryBuilder. Еще кто-то споткнулся о MySQL и теперь агитирует только за NoSQL...

    В общем все как всегда :)

  16. №10608
    Денис
    Денис 02.08.2016, 7:14:20

    Правда в том, что единой методы нет и не будет. Всегда нужно исходить из специфики проекта и только так. Собственно, что и пишет в статье автор.

    О чем тут еще говорить, не понятно.

  17. №10774
    Alexsamdr
    Alexsamdr 28.11.2016, 14:42:16

    У нас статистика через AR выбирается в mysql порядко 70гб агрегированных данных быстро работает в рамках 1 дня быстро если недели 2 взять то долго это по 8М записей mysql группировать сложно ( ну это уже сам mysql тупит) Все это дело скрипт кушает оперативку под 101мб+/-. с рендером, если включен еще у колонок grid html то все 150мб будут точно + тормоза (рекомендую не включать у вывода колонок такой способ, если вы на 100% уверены что там все безопасно, это повысит рендер таблицы в 10+ и более раз)

    Сейчас переехали на clickhouse, я пока доволен работой и скоростью которую он делает на QBuilder/DAO Изменения причем минимальные потребовались для нативного Yii QueryBuilder допилить.

  1. Почта опубликована не будет.

  2. Можно использовать синтаксис Markdown или HTML.

  3. Введите ответ в поле. Щёлкните, чтобы получить другую задачу.