Отдача большого файла клиенту

Чёт "внезапно" встала задача отдать файл с данными клиенту.
Как бы проблем нет, сходил в базу, забрал данные, засунул в csv или там pdf, выставил хидер и выгнал юзеру в браузер. Довольный пациент жмет скачать - профит.
А если данных дохулиард петабайт?
Данные лежат в монге.
Технически задачу можно разделить на две части, сползать в монгу с командой db.collection.stats(), стащить параметр storageSize, если значение меньше какого то порога - выгнать юзеру в браузер сразу.
Если размер больше порога, то тут уже хочется сделать чего то кошерное.
В голове пока крутится только одна идея как это сделать, а именно:
Юзеру сообщаем что файл дохуячотабольшой, но заявка принята, ожидайте.
Далее пихаем его заявку в очередь, откуда его выгребет таск, к примеру Celery, и начнёт писать файл по-блочно выбирая данные с базы (тут хотелось бы тратить ресурсы сервера по-минимуму).
По окончанию работы (хз, может еще имеет смысл зипануть этот файл (а там только текстовые данные) с low priority) юзеру пишется сообщение о том, что его файл готов и предлагается линк на файл.
Соответственно юзер будет его уже тянуть с FTP. Вот пока такая идея.

Может кто то решал эту задачу иначе и более интересно?

Да, основная идея то в том, что бы минимизировать ресурсо-затраты со стороны сервера.

@adw0rd, пока не могу сказать, реально, предпологается, что может доходить до нескольких гигов.
Но это всё теоретизирование, что будет на практике, я хз пока. Исхожу сразу из предположения что будет много, ибо лучше перебдеть.
С другой стороны может ну его к Аллаху FTP и отдавать напрямую в браузер, только хотелось бы пожать на выходе.
Да и избежать загрузки всего объема данных с базы в память.

@phpdude, мне тут главное ресурсы свои поменьше нагрузить в этом процессе. Удобство пользователя конечно важно, но пока ресурсы важнее.

Особенно если большие файлы затребует одновременно 100 и более человек, пусть хотя бы и теоретически.

А вот еще почему в сторону FTP:

"But beware, creating zip archives on each request is bad idea and this may kill your server (not counting timeouts if the archives are large).
Performance-wise approach is to cache generated output somewhere in filesystem and regenerate it only if source files have changed.
Even better idea is to prepare archives in advance (eg. by cron job) and have your web server serving them as usual statics."

@phpdude, как то так:

нахуй тебе zip тут?

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

нахуй тебе тут ftp? достаточно банального nginx secure link + x-accelerate (гугли)

Вот это клёва, почитаю, спасибо. (Но файл будет лежать в системе, я правильно понимаю?)

нахуй это гавно вообще хранить в монге? серебряная пуля?

Текущее архитектурное решение, фигли...

нахуй юзеров

аминь.

Подняли статистику за несколько лет, если усреднённо, то объем файла на выдачу будет порядка 5-20 метров.
Но несколько клиентов в процессе работы имели данные от гига до двух. Так что я сразу ориентируюсь на общее "несколько гигов".

@phpdude, да, обжатие простым и будет, gzip'ом.

хз, исторически не храню файлы в базе, дурной тон я щитаю. Хотя да, это проще всего, но бекапать заебешься

Не, не, не Дэвид Блейн, я не файлы в монге храню, не :)))
В монге просто дохуя данных, а вот если юзер хочет это получить в виде файла PDF, к примеру, то я это буду выгонять в файл и класть-ложить на диск.

Ну вот как пример - логи, по одному процессу, в логе тьма текстовой информации, величина подобного лога может дойти в рамках одной сессии до гига, а то и перевалить.
Лог в монге, юзер хочет его себе на диск для более тщательного анализа в виде обычного .txt
Как мне еще отдать ему лог с минимальными затратами для меня в первую очередь и во вторую для клиента?

Решение через файл и секьюрный линк с лёгкой обжимкой - пока единственное у меня.