Каталог NTFS имеет 100 тыс. Записей.Насколько сильно повышается производительность, если распространяется на 100 подкаталогов?

Question

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

Мы собираемся распространить эти записи по подкаталогам - как это делает git, например. 100 подкаталогов с ~ 1000 записей в каждом.

Вопрос

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

Но "распространение в подкаталоги" ускорит прохождение всех записей, например, перечислять / читать все 100 000 записей? То есть Когда мы инициализируем / разогреваем кэш из хранилища FS, нам нужно, чтобы обход всех 100 000 записей (и удаление старых записей) мог занять более 10 минут.

Будет ли "распространение данных" уменьшать это "время прохождения". Кроме того, этот «обход» действительно может / действительно удаляет устаревшие записи (например, старше N дней). Улучшит ли «распространение данных» время удаления?

Дополнительный контекст -NTFS Семейство ОС Windows (Server 2003, 2008)

-Java-приложение J2ee.

Я / мы были бы признательны за любое обучение по вопросам масштабируемости файловой системы.

Заранее спасибо.

будет

p.s. Я должен прокомментировать, что у меня есть инструменты и способность проверить это самостоятельно, но я решил сначала выбрать улей для теории и опыта.

Answer 1

Я также полагал, что распространение файлов по подкаталогам ускорит операции.

Итак, я провел тесты: я сгенерировал файлы от AAAA до ZZZZ (26 ^ 4 файла, это около 450 КБ) и поместил их в один каталог NTFS.Я также поместил идентичные файлы в подкаталоги от AA до ZZ (то есть сгруппировал файлы по первым 2 буквам их имен).Затем я выполнил несколько тестов - перечисление и произвольный доступ.Я перезагрузил систему после создания и между тестами.

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

Обратите внимание, что полное перечисление (в обоих случаях) заняло около 3 минут для файлов размером 400 КБ.Это значительное время, но подкаталоги делают его еще хуже.

Вывод: в частности, в NTFS нет смысла группировать файлы в подкаталоги, если доступ к любому из этих файлов возможен.Если у вас есть кеш , я бы также протестировал группирование файлов по дате или по домену, предполагая, что к некоторым файлам обращаются чаще, чем к другим, и ОС не нужно хранить все каталоги в памяти.Тем не менее, для вашего количества файлов (до 100 КБ) это, вероятно, также не даст существенных преимуществ.Я думаю, вам нужно измерить такие конкретные сценарии самостоятельно.

Обновление: Я сократил свой тест для произвольного доступа, чтобы получить доступ только к половине файлов (от AA до OO).Предполагалось, что это будет включать один плоский каталог и только половину подкаталогов (что дает бонус к случаю подкаталога).Все-таки плоский каталог выполнен лучше.Поэтому я предполагаю, что если у вас нет миллионов файлов, хранить их в едином плоском каталоге в NTFS будет быстрее, чем группировать их в подкаталоги.

Answer 2

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

Многие платформы кэширования и механизмы хранения данных с большой файловой системой будут создавать подкаталоги на основе первого символа в именах файлов в таких сценариях, так что если вы сохраняете файл "abcdefgh.png" в своем кэше, он будетперейдите в «cache / a / b / cdefgh.png» вместо просто «cache / abcdefgh.png».Это предполагает, что распределения первых двух букв имен ваших файлов примерно одинаковы по всему символьному пространству.

Как вы упомянули, поскольку ваша основная задача, включающая в себя просмотр или просмотр каталогов, заключается в удалении устаревших файлов, ярекомендовал бы вам создавать каталоги на основе даты и / или времени, когда файл был кэширован, т.е. «cache / 2010/12/04/22 / abcdefgh.png», и, где бы вы ни индексировали кэш, обязательно индексируйте его по имени файлаИ дата (особенно если она есть в базе данных), так что вы можете быстро удалить элементы по дате из индекса и удалить соответствующий каталог.

Answer 3

Нужно посмотреть, как устроена ваша дисковая подсистема. В то время как диски быстро растут в размере, они не становятся намного быстрее (во времени доступа). Другой вариант расположения дисков (использование большего количества дисков) или использование дисков SSD - вариант. Например, SSD не имеет движущихся частей и может касаться файлов размером 100 КБ за 10 секунд. Делать разминку ненужным.

Answer 4

Как вы загружаете свой кеш?Если вы используете стандартное взаимодействие с файловой системой Java, это будет вашим первым узким местом - Java довольно плохо справляется с итерациями содержимого папки - и если вы выполняете проверки каждого файла во время итерации (получите дату изменения, убедитесь, что файл не установлен).Это не каталог, и т. д.) производительность может иметь большое значение (все это включает в себя поездки в родную страну).Переход к решению на основе встроенного FindFirstFile может обеспечить значительное (например, на порядки) улучшение.FindFirstFile возвращает всю информацию о файле с каждым шагом итерации.Java File.listFiles () возвращает список путей.Затем, когда вы запрашиваете атрибуты или другие мета - каждый вызов - это обратный путь в файловую систему.Ужасно, ужасно неэффективно.

ОК - это не по пути.Далее, сырая итерация огромного каталога в NTFS не особенно медленна, чем n-арный подход к дереву (папки и подпапки и т. Д.).С FAT32 это было очень важно, но NTFS хорошо справляется с подобными вещами.Тем не менее, разбиение на подпапки открывает некоторые естественные возможности распараллеливания, которые гораздо труднее достичь с помощью одной папки.Если вы можете порождать 10 или 15 потоков, каждый из которых работает с отдельными папками, то вы можете эффективно устранить задержку диска в качестве способствующего фактора.

Я бы, вероятно, предложил начать с профилирования (вы, конечно, уже знали)- и посмотрите, откуда исходит основная часть времени загрузки.Вы можете быть удивлены (например, в одном из наших приложений, которое выполняет большую часть обработки списка файлов, я был шокирован, обнаружив, сколько времени мы получали при проверке isDirectory () - такое простое изменение, как сравнение дат до определение директории / файла увеличило нашу скорость итерации на 30%).