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

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

Кроме того, не могли бы вы переместить файлы старше, скажем, года, в другое (но все еще доступное) место?

Наконец, и снова, это требует, чтобы вы могли вычислять имена, вы обнаружите, что прямой доступ к файлу намного быстрее, чем попытка открыть его через проводник. Например, высказывание
notepad.exe "P: \ ath \ to \ your \ filen.ame"
из командной строки должно быть довольно быстро, если вы знаете путь к нужному файлу без необходимости получать список каталогов.

Рассмотрите возможность переноса их на другой сервер, который использует файловую систему, более удобную для большого количества небольших файлов (например, Solaris с ZFS)?

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

Один из распространенных приемов - просто создать несколько подкаталогов и разделить файлы.

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

Производительность NTFS резко падает после 10 000 файлов в каталоге. Что вы делаете, так это создаете дополнительный уровень в иерархии каталогов с каждым подкаталогом, содержащим 10 000 файлов.

Как бы то ни было, это подход, который разработчики SVN использовали в версия 1.5. В качестве порогового значения по умолчанию они использовали 1000 файлов.

Помимо размещения файлов в подкаталогах ..

Лично я бы разработал приложение, которое поддерживает интерфейс с этой папкой одинаковым, т.е. все файлы отображаются как отдельные файлы. Затем в фоновом режиме приложения фактически берет эти файлы и объединяет их в файлы большего размера (и поскольку размеры всегда составляют 64 КБ, получение необходимых данных должно быть относительно простым), чтобы избавиться от беспорядка, который у вас есть.

Таким образом, вы по-прежнему можете упростить им доступ к нужным им файлам, но при этом у вас будет больше контроля над тем, как все устроено.

Вы можете попробовать использовать что-то вроде Solid File System.

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

http://www.eldos.com/solfsdrv/

Если есть какие-либо значимые категориальные аспекты данных, вы можете вложить их в дерево каталогов. Я считаю, что замедление происходит из-за количества файлов в одном каталоге, а не из-за самого количества файлов.

Наиболее очевидная общая группировка - по дате и дает вам трехуровневую структуру вложенности (год, месяц, день) с относительно безопасным ограничением количества файлов в каждой конечной директории (1-3k).

Даже если вы можете улучшить производительность файловой системы / файлового браузера, похоже, что это проблема, с которой вы столкнетесь еще через 2 года или 3 года ... просто просмотр списка файлов размером 0,3-1 млн. стоимость, поэтому в долгосрочной перспективе может быть лучше найти способы просматривать только меньшие подмножества файлов.

Использование таких инструментов, как find (в cygwin или mingw), может сделать присутствие дерева подкаталогов не проблемой при просмотре файлов.

Проблема с производительностью вызвана огромным количеством файлов в одном каталоге: как только вы удалите это, все будет в порядке. Это не проблема, связанная с NTFS: на самом деле, она обычно встречается с домашними / почтовыми файлами пользователей в больших системах UNIX.

Один очевидный способ решить эту проблему - переместить файлы в папки с именем, основанным на имени файла. Предполагая, что все ваши файлы имеют имена одинаковой длины, например ABCDEFGHI.db, ABCEFGHIJ.db и т. д. Создайте такую ​​структуру каталогов:

ABC\
    DEF\
        ABCDEFGHI.db
    EFG\
        ABCEFGHIJ.db

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

Каждый день переименовывайте папку с отметкой времени.

Если приложение сохраняет файлы в c: \ Readings, настройте запланированную задачу, чтобы переименовать Reading в полночь и создать новую пустую папку.

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

Вы можете расширить метод до группировки по месяцам. Например, C: \ Reading станет c: \ Archive \ September \ 22.

Вы должны быть осторожны со своим временем, чтобы убедиться, что вы не пытаетесь переименовать папку во время сохранения продукта в нее.

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

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

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

1.xml
24.xml
12331.xml
2304252.xml

вы можете отсортировать их по каталогам следующим образом:

data/1.xml
data/24.xml
data/1/3/3/12331.xml
data/2/5/2/4/0/2304252.xml

Эта схема гарантирует, что у вас никогда не будет больше 100 файлов в каждом каталоге.

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

Вы можете перейти в ZFS или другую файловую систему, которая лучше обрабатывает небольшие файлы, но все же остановиться и спросить, НЕОБХОДИМО ли вам хранить небольшие файлы.

В нашем случае мы в конечном итоге перешли к системе, в которой все небольшие файлы на определенную дату были добавлены в стиле TAR с простыми разделителями для их анализа. Файлы на диске выросли с 1,2 миллиона до нескольких тысяч. На самом деле они загружались быстрее, потому что NTFS не очень хорошо справлялась с небольшими файлами, а диск в любом случае мог лучше кэшировать файл размером 1 МБ. В нашем случае время доступа и анализа для поиска нужной части файла было минимальным по сравнению с фактическим хранением и обслуживанием сохраненных файлов.

NTFS на самом деле отлично справится с более чем 10 000 файлов в каталоге, если вы укажете ему прекратить создание альтернативных имен файлов, совместимых с 16-битными платформами Windows. По умолчанию NTFS автоматически создает имя файла «8 точек 3» для каждого создаваемого файла. Это становится проблемой, когда в каталоге много файлов, потому что Windows просматривает файлы в каталоге, чтобы убедиться, что имя, которое они создают, еще не используется. Вы можете отключить именование «8 точек 3», установив для параметра реестра NtfsDisable8dot3NameCreation значение 1. Это значение находится в пути реестра HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ FileSystem. Это изменение безопасно, поскольку файлы имен «8 точек 3» требуются только для программ, написанных для очень старых версий Windows.

Чтобы этот параметр вступил в силу, требуется перезагрузка.

Чтобы создать структуру папок, которая масштабируется до большого неизвестного количества файлов, мне нравится следующая система:

Разделите имя файла на части фиксированной длины, а затем создайте вложенные папки для каждой части, кроме последней.

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

12.jpg -> 12.jpg
123.jpg -> 123.jpg
123456.jpg -> 123456.jpg

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

А вот однострочник красивая PowerShell, который поможет вам начать работу!

$s = '123456'

-join  (( $s -replace '(..)(?!$)', '\' -replace '[^\]*$','' ), $s )