Файловая система ищет производительность с большим количеством крошечных файлов - PullRequest
3 голосов
/ 11 января 2009

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

Будет ли время поиска по UFS BSD ухудшаться со временем для запросов на отдельные файлы? Я понимаю, что ограничение inode в файловой системе зависит от размера раздела / фрагмента, но жесткий диск должен пройти по таблице inode для каждого запроса файла, прежде чем он сможет обнаружить местоположение данных. Какая файловая система обеспечивает лучшую производительность для времени поиска?

Альтернативой является установка файлов размером 4–4 ГБ «blob» и наличие отдельной системы поиска файла, содержащегося в них, из программного обеспечения. «Таблица inode» программного обеспечения может быть оптимизирована для доставки на основе данных текущего пользователя, вошедшего в систему, и т. Д. Эти «таблицы inode», вероятно, будут кэшироваться в ОЗУ и будут относиться только к тем пользователям, которые в данный момент вошли в систему, чтобы было меньше потраченных ресурсов .

Где эти два решения оцениваются с точки зрения масштабируемости и обслуживания? Какой прирост производительности, если таковой имеется, можно ожидать с помощью второго решения?

Ответы [ 5 ]

5 голосов
/ 12 января 2009

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

3 голосов
/ 23 января 2009

Для последних версий FreeBSD с dirhash и программными обновлениями я не встречал проблем с несколькими десятками тысяч файлов на каталог. Вы, вероятно, не хотите идти к северу от 500.000 файлов или около того. Например. удаление каталога с 2.500.000 файлов заняло у меня три дня.

1 голос
/ 11 января 2009

Я не уверен, что правильно понимаю ваш вопрос, но если вы хотите искать по большому количеству файлов, почему бы не использовать разделенную таблицу mysql, расположенную в файловой системе RAID0 или VFS?

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

0 голосов
/ 12 января 2009

Другой вариант, если ваши объекты должны или могут быть доступны через HTTP, это использовать кэш лак перед небольшим веб-сервером. Первоначально объекты будут храниться на диске, но лак будет хранить и обслуживать объекты из памяти после первого доступа к данному объекту.

0 голосов
/ 11 января 2009

Было бы полезно получить более подробную информацию о вашей ситуации, существуют ли файлы или они будут созданы вашим приложением? Если вам нужен способ хранения произвольных данных без структуры реляционной базы данных, вы обратились к объектным базам данных

...