QuerySets Django достаточно ленивы, чтобы справиться с большими наборами данных?

Question

Мне кажется, я где-то читал, что ORM в Django лениво загружает объекты. Допустим, я хочу обновить большой набор объектов (скажем, 500 000) в операции пакетного обновления. Можно ли будет просто перебирать очень большой QuerySet, загружая, обновляя и сохраняя объекты на ходу?

Точно так же, если бы я хотел разрешить разбивку на страницы всех этих тысяч объектов, мог бы я использовать встроенную функцию разбивки на страницы или мне пришлось бы вручную запустить окно для набора данных с запрашивать каждый раз из-за размера QuerySet всех объектов?

Answer 1

Если вы оцениваете набор запросов с 500000, который является большим, он будет кэшироваться в памяти. Вместо этого вы можете использовать метод iterator() в вашем наборе запросов, который будет возвращать результаты в соответствии с запросом, без значительного потребления памяти.

Также используйте объекты update() и F() для выполнения простых пакетных обновлений в одном запросе.

Answer 2

Если пакетное обновление возможно с использованием SQL-запроса, то я думаю, что использование sql-запросов или django-orm не будет иметь большого значения. Но если обновление фактически требует загрузки каждого объекта, обработки данных и последующего их обновления, вы можете использовать orm или написать свой собственный запрос sql и выполнить запросы на обновление для каждого из обработанных данных, накладные расходы полностью зависят от логики кода.

Встроенная функция разбивки на страницы выполняет запрос на смещение с ограничением (если вы делаете это правильно), поэтому я не думаю, что в разбивке на страницы тоже есть большие издержки ..

Answer 3

Поскольку я сравнил это с моим текущим проектом с набором данных 2.5M записей в одной таблице.

Я читал информацию и считал записи, например, мне нужно было найти идентификаторы записей, какое поле «имя» обновлялось более одного раза за определенный период времени. Тест Django использовал ORM для извлечения всех записей, а затем для их перебора. Данные были сохранены в списке для дальнейшей обработки. Никаких отладочных выходов, кроме результата печати в конце.

С другой стороны, я использовал MySQLdb, который выполнял те же запросы (полученные из Django) и строил ту же структуру, используя классы для хранения данных и сохранения экземпляров в списке для дальнейшей обработки. Нет отладочной информации, кроме результата печати в конце.

Я обнаружил, что:

                      without Django  with Django
 execution time             x             10x
 memory consumption         y             25y

И я только читал и считал, не выполняя запросы на обновление / вставку.

Попытайтесь исследовать этот вопрос самостоятельно, тест и тестирование не составляет труда.