Что мне нужно учитывать при масштабировании приложения, которое хранит файлы в файловой системе?

Возможно, вы захотите разбить каталоги по пользователям, приложениям и т. п., чтобы в любом случае ими было легко управлять — например, если пользователь перестанет использовать службу, вы можете просто удалить его каталог. Также я предполагаю, что вы будете застегивать их. Если вы держите его хорошо отделенным, вы сможете изменить свое мнение позже.

Мне было бы интересно посмотреть, как сработает для вас использование чего-то вроде SQLite, поскольку у вас может быть sqlite db для каждого разделенного каталога.

Я предполагаю, что файлы HTML больше, чем файл, который они загрузили, так зачем хранить большой файл HTML.

О таких вещах, как Mongodb и т. Д., Не может быть и речи? поскольку ваше приложение масштабируется с несколькими серверами, у вас возникает проблема с доступом к другим файлам на другом сервере, если только вы не выберете правильный сервер с помощью какой-либо техники. Тогда, возможно, у вас есть серверы, которые простаивают, поскольку никому не нужны документы.

Почему ограничение только на хранение файлов в каталоге, это POC?

ИЗМЕНИТЬ

Мне полезно читать такие вещи, как http://blog.fogcreek.com/the-trello-tech-stack/, и я бы посоветовал вам найти сайт, который уже делает то же, что и вы, и прочитать об их технологиях. куча.

Как кто-то уже прокомментировал, почему бы не использовать Amazon S3 или аналогичный.

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

Несколько лет назад я работал над системой, в которой страховые сертификаты хранились в файловой системе, которую мы используем, чтобы исчерпать inodes.!

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

ИЗМЕНИТЬ

Я считаю, что HAProxy предназначены для решения всех проблем балансировки нагрузки.

Как я себе представляю, как пользователь, я хочу http://docs.yourdomain.com/myname/document.doc, хотя я полагаю, что это настолько очевидное имя, что есть опасения по поводу безопасности.

Это сильно зависит от вашей файловой системы. Возможно, вы захотите посмотреть, с какими проблемами столкнулись ребята из git (также с использованием единственной базы данных на основе файловой системы).

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

uploaddir/
    00/
         files whose name sha1 starts with 00
    01/
         files whose name sha1 starts with 01

и так далее. Это снимает некоторую нагрузку с файловой системы, разбивая на разделы, возможно, большие каталоги. Если вы хотите быть уверены, что ни один пользователь не сможет выполнить атаку типа «отказ в обслуживании», специально загрузив файлы, имена которых имеют хэш с одними и теми же начальными символами, вы также можете по-другому заполнить хэш, посолить его или что-то в этом роде.

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