Оптимальный способ обслуживания 70 000 статических файлов (jpg)?

Оптимальный способ обслуживания 70 000 статических файлов (jpg)?

Мне нужно обслуживать около 70 000 статических файлов (jpg) с помощью nginx. Мне следует сбросить их все в один каталог или есть лучший (эффективный) способ? Поскольку имена файлов числовые, я рассматривал возможность создания такой структуры каталогов:

ххх/хххх/ххх

Операционная система — CentOS 5.1.

решение1

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

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

Но не верьте мне, я понятия не имею, что делаю!Измерить производительностькогда это важно!

решение2

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

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

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

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

решение3

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

Но я бы посоветовал вам сделать ваши URIнезависимыйнезависимо от используемой схемы каталогов, используя модуль перезаписи nginx, например, сопоставьте example.com/123456.jpg с /path/12/34/123456.jpg

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

решение4

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

Для Squid по умолчанию установлено 16 каталогов первого уровня и 256 каталогов второго уровня. Это разумные значения по умолчанию для моих файловых систем.

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

Связанный контент