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

Продукт, над которым я работаю, собирает несколько тысяч чтений в день и сохраняет их в виде 64-битных двоичных файлов на разделе NTFS (Windows XP). Через год в производстве есть более 300000 файлов в одном каталоге, и число продолжает расти. Это сделало доступ к каталогам родителя/предка из обозревателя Windows очень трудоемким.

Я попытался отключить службу индексирования, но это не имело никакого значения. Я также рассматривал перемещение содержимого файла в файлы базы данных /zip/tarballs, но нам полезно получать доступ к файлам по отдельности; в основном, файлы по-прежнему необходимы для исследовательских целей, и исследователи не хотят иметь дело ни с чем другим.

Есть ли способ оптимизировать NTFS или Windows, чтобы он мог работать со всеми этими маленькими файлами?

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

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

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

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

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

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

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

Ответ 7

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

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

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

Ответ 8

Наличие сотен тысяч файлов в одном каталоге действительно приведет к повреждению 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 файлов в каждом каталоге.

Ответ 9

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

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

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

Ответ 10

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

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

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

Ответ 11

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

Ответ 12

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

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

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

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

Ответ 13

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

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

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

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

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

Ответ 14

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

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

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

12.jpg -> 12.jpg
123.jpg -> 12\123.jpg
123456.jpg -> 12\34\123456.jpg

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

И вот красивый однострочный PowerShell для вас!

$s = '123456'

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