где-то за 3 месяца). Потом там про суммировать одно поле.
Так вот, я попробовал через LazyCollection, через query chunk разбивал по 1к записей, запрос выполнялся где-то 2-3 часа и в итоге упало с ошибкой коллекции, говорит мол памяти не хватает. Как быть?)
а зачем тащить все 3,5кк записей? sum(column) не подойдёт ?
so easy
там группировку сложную сначала надо сделать, потом считать сумму
есть несколько вариантов: 1) один или несколько view из нужных тебе таблиц на чистом SQL, где отобразишь только нужные тебе данные для группировки, затем запрос к этому view и считай. Это явно быстро. 2) построчно - долго и геморройно и все равно придется за памятью следить
а без Collection, через $query->cursor() — никак?
Память не от этого течëт скорее всего. А от того, что результат в памяти держится.
+ Можно ещё через map reduce обсчитывать данные на чанках. Но это все про «костыли обработки olap данных на oltp таблицах»
курсор не спасет от перегруза базы и объедания памяти не на стороне php, а драйвера который заберет данные из базы (приэтом сожрав память сервера), а потом дозировано будет отдавать в php
эмм... это какой драйвер так делает? о.О хочу узнать, чтобы выпилить везде, куда руки доходят =)
cursor в любом случае заберет все данные что база отдала, сохранит их на уровне драйвера, который взаимодействует между php и базой (например mysqlnd или pdo_mysql), а потом начнет построчно отдавать в php и создавать модели, потому и очень нужно аккуратно, в документации даже сноска есть по этой части.
эх, так и не нашёл, в PDO для какой СУБД происходит подобное кэширование. если в каком-нибудь Informix или Firebird — пускай, не жалко =) порылся в общем коде — https://github.com/php/php-src/tree/master/ext/pdo — тоже ничего подобного не нарыл. наверное плохо смотрел.
Обсуждают сегодня