akrush3. При 50тыс. заявителях - это либо дополнительно 50тыс. папок по номерам заявлений и внутри папки по номерам подачи разных заявлений, либо вообще все в одной папке.
А это, даже при 5 обращениях+3 документа, 50000*5*3=750 000 файлов/папок.
Не думаю что операционка себя будет комфортно чувствовать.Насколько мне изменяет склероз, операционка (Windows Server 2003) совершенно нормально чувствует себя при ~11 миллионах файлов в иерархии каталогов.
Это по опыту позапрошлой работы, где проблемой было объём дисков (до полутерабайта), но никак не количество файлов.

Даже если оставить в покое сервера, то "вот это" - Windows 7 x64 SP1+ (один из "развесистых" каталогов): На 32-разрядной семёрке с парой гигабайт ОЗУ будет ничуть не хуже.

И, по опыту всё той же позапрошлой работы, могу сказать, что первый вариантом был как раз "блобы в базе".
Сдохло, ибо:
1. Требуется больше места, чем на диске;
2. Сильно дороже по ресурсам.

Вторым вариантом был "свалим все файлы в одном каталоге".
Сдохло ибо сканирование ~65000 файлов в одном каталоге - (сравнительно) очень медленно.

Третьим вариантом было хранение в иерархии каталогов.
Вполне нормально, хотя реализация была далеко не идеальной.

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

• Кроме того, мой опыт включал:Копирование нескольких десятков гигабайт на локальные диски второго сервера, чтобы хоть как-то дожить до подключения хранилища. В этом случае использование архива просто исключалось, поскольку тупо не было места.
  
• Кроме того, не было никакого желания связываться и с потоковыми вариантами: ни на чтении, ни на записи ничего не экономится, а гигабитная сеть, как ни странно - достаточно быстра;
  
• Копирование (уже) примерно четверти терабайта на это самое хранилище. Дополнительное место было, но смысла возиться с предварительной архивацией - по прежнему не было.
  

Другой пример - (мой) домашний компьютер.
Чтобы перенести ~600Гб "разновсякого бутора" со старого диска на новый я, таки, воспользовался потоковым вариантом (утилита, использующая Backup API), но вот архиву и в этой схеме места не нашлось.
По результату могу сказать, что скорость копирования примерно соответствовала скорости линейного чтения/записи дисков. Не на сто процентов, конечно, но без каких-либо катострофических проседаний.
Полумиллиона совсем мелких файлов у меня, конечно, не было, но те же полляма с разбросом размеров от единиц-десятков килобайт до единиц-десятков мегабайт - были. Естественно, не в одном каталоге, а во вполне развесистой иерархии.

В общем, если у вас или очень медленная среда передачи (100МБит и менее) или очень быстрые диски (200МБайт/с и более), то использование потокового сжатия позволит сэкономить время на передачу.
Отдельно подчеркну, что в нормальном сценарии, время чтения/записи сэкономлено быть не может.
Вариант "делаем архив на том/раздел архивируемых данных" из нормальных сценариев бэкапа - исключаем.
Ну вот в реальной жизни такое быть может, но нормальным положением вещей считаться не может.

Ну и файловые системы, у которых нет индекса для записей каталога это какой-то оксюморрон.

fraksНабралось со временем :)И это время ничему не учит ...

Ну не нужно никому "realname" файла в служебном каталоге.
Взяли монотонно растущий идентификатор из базы, преобразовали в строку, дополнили ведущими нулями до девяти цифр, взяли две первые группы по три цифры и получили чёткую балансировку по каталогам и предельно однозначную идентификацию местонахождения файла.

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