Предположим у нас есть CLI приложение, которое анализирует большой объем данных. Ну относительно большой, например парсит сайт и считает кол-во div тегов, далее записывает это в качестве отчета в файл.
Для того, чтобы обойти весь сайт нужно достаточно кол-во времени, предположим не большой сайт сможем обойти за 30 секунд, собрать все данные в массив и уже после всего из этого массива собрать файл с отчетом. Так кстате работают многие приложения, например сборщики frontend, они вначале что-то грузят в оперативку и только потом в файловую систему. Я сталкивался с такой ситуацией, что если мало оперативки, тот же composer или gulp не могут загрузить большие пакеты (например на сервере не смог загрузить gulp-image, где было менее 400 мб оперативки).
Вернемся к анализатору сайта, что если нам не хватит оперативки или возникнет другая ошибка ? Перед нами момент, либо мы получаем результат целиком и полностью либо не получаем ничего. Вопрос почему так делают, почему работают с оперативной память чаще, чем скажем записывают данные в файл или базу, чтобы в случае сбоя хоть какой-то но результат был ?
пишем результаты в очередь, обработчик очереди записывает репорт в файл или добавляет еще задачи в очередь и т.д. и т.д. Если использовать какие-нибудь менеджеры очередей у них обычно есть возможность персистить очереди на файловую систему для надежности.
слишком простое приложение, даже без базы данных, что бы такие штуки цеплять. Вот например composer или gulp, если оперативки не хватает, сразу падают.
nepster09: ну потому что они ничего критичного не делают. Но в целом нет смысла хранить эту инфу в памяти. Можно конечно пачкой записывать это все, так будет лучше, но ждать пока все скачается тоже не ок.
Сергей Протько: да, но у меня был случай когда я на сервер не мог поставить npm пакет, так как не хватало памяти оперативной. Если бы они по файлам скачивали сразу в файловую систему, такой проблемы бы не было. От сюда и вопрос, почему они работают с оперативкой ?
