Мне нужно обработать около 70 000 статических файлов (jpg) с помощью nginx. Должен ли я выгрузить их все в один каталог или есть лучший (эффективный) способ? Поскольку имена файлов числовые, я подумал о такой структуре каталогов:
ххх / хххх / ххх
ОС - CentOS 5.1.
это действительно зависит от файловой системы, которую вы используете для хранения файлов.
некоторые файловые системы (например, ext2 и, в меньшей степени, ext3) работают ужасно медленно, когда у вас есть тысячи файлов в одном каталоге, поэтому использование подкаталогов - очень хорошая идея.
другие файловые системы, такие как XFS или reiserfs (*), не замедляют работу с тысячами файлов в одном каталоге, поэтому не имеет значения, есть ли у вас один большой каталог или множество меньших подкаталогов.
(*) reiserfs имеет несколько хороших функций, но это экспериментальная игрушка, у которой есть история катастрофических сбоев. не используйте его ни для чего, даже отдаленно важного.
Как уже говорили другие, хеширование каталогов, вероятно, будет наиболее оптимальным.
Я бы посоветовал вам сделать ваши URI независимый любой схемы каталогов, которую вы используете, используя модуль перезаписи nginx, например map example.com/123456.jpg к /path/12/34/123456.jpg
Затем, если ваша структура каталогов должна измениться по соображениям производительности, вы можете изменить это, не меняя опубликованные URI.
Тест, тест, тест! Вы, вероятно, найдете нет существенной разницы между двумя вариантами, а это означает, что ваше время лучше потратить на другие проблемы. Если вы проведете тест и не обнаружите реальной разницы, выберите ту схему, которая проще - что легко кодировать, если только программы имеют доступ к файлам, или что легко для людей, если им нужно часто работать с файлами.
Что касается того, что быстрее, время поиска в каталоге, как я полагаю, пропорционально логарифму количества файлов в каталоге. Таким образом, каждый из трех поисков вложенной структуры будет быстрее, чем один большой поиск, но общее количество всех трех, вероятно, будет больше.
Но не верь мне, я понятия не имею, что делаю! Измерьте производительность когда это важно!
Как правило, неплохо было бы выполнить базовое хеширование каталогов. Даже если ваша файловая система хорошо справляется с файлами размером 70k; говоря, миллионы файлов в каталоге станут неуправляемыми. Также - как ваше программное обеспечение резервного копирования похоже на множество файлов в одном каталоге и т. Д.
При этом: для получения репликации (избыточности) и упрощения масштабируемости рассмотрите возможность хранения файлов в MogileFS, а не только в файловой системе. Если файлы небольшие, а некоторые из них намного популярнее других, рассмотрите возможность использования Varnish (varnish-cache.org), чтобы обслуживать их очень быстро.
Еще одна идея: используйте CDN - они на удивление дешевы. Мы используем тот, который стоит примерно столько же, сколько мы платим за «обычную пропускную способность»; даже при малой нагрузке (10-20Мбит / сек).
Вы можете разместить кеш squid перед своим сервером nginx. Squid может либо хранить популярные изображения в памяти, либо использовать собственный макет файла для быстрого поиска.
Для Squid по умолчанию используется 16 каталогов первого уровня и 256 каталогов второго уровня. Это разумные значения по умолчанию для моих файловых систем.
Если вы не используете такой продукт, как Squid, и создаете свою собственную файловую структуру, вам необходимо придумать разумный алгоритм хеширования для ваших файлов. Если имена файлов генерируются случайным образом, это легко, и вы можете использовать само имя файла для разделения на сегменты. Если все ваши файлы выглядят как IMG_xxxx, вам нужно либо использовать наименее значащие цифры, либо хешировать имя файла и делить его на основе этого номера хеша.
Как уже упоминали другие, вам необходимо протестировать, чтобы увидеть, какой макет лучше всего подходит для вашей настройки и шаблона использования.
Однако вы также можете посмотреть на open_file_cache параметр внутри nginx. Видеть http://wiki.nginx.org/NginxHttpCoreModule#open_file_cache
Обязательно выполните сравнительный анализ и используйте эту информацию, чтобы помочь вам принять решение, но если бы это была моя система, я бы также уделил некоторое внимание долгосрочному обслуживанию. В зависимости от того, что вам нужно сделать, может быть проще управлять вещами, если вместо всего в одном каталоге есть структура каталогов.
Разбить их на каталоги - неплохая идея. В основном (как вы, возможно, знаете) причина такого подхода заключается в том, что наличие слишком большого количества файлов в одном каталоге делает индекс каталога огромным и заставляет ОС долго искать в нем; и наоборот, наличие слишком большого количества уровней (в) направления (извините, плохой каламбур) означает выполнение большого количества запросов на диск для каждого файла.
Я бы посоветовал разделить файлы на один или два уровня каталогов - запустите несколько проб, чтобы увидеть, что работает лучше всего. Если среди 70000 изображений есть несколько изображений, которые значительно популярнее других, попробуйте поместить все их в один каталог, чтобы ОС могла использовать для них кешированный индекс каталога. Или, на самом деле, вы даже можете поместить популярные изображения в корневой каталог, например:
images/
021398012.jpg
379284790.jpg
...
000/
000/
000000000.jpg
000000001.jpg
...
001/
...
002/
...
... надеюсь, вы видите закономерность. В Linux вы можете использовать жесткие ссылки для популярных изображений (но не символические ссылки, что снижает эффективность AFAIK).
Также подумайте о том, как люди будут загружать изображения. Собирается ли какой-либо отдельный клиент запрашивать только несколько изображений или весь набор? Потому что в последнем случае имеет смысл создать архивный файл TAR или ZIP (или, возможно, несколько архивных файлов) с изображениями в них, поскольку передача нескольких больших файлов более эффективна, чем передача множества более мелких.
P.S. Я как бы увлекся теорией, но Квинн прав, вам действительно нужно провести несколько экспериментов, чтобы увидеть, что лучше всего подходит для вас, и вполне возможно, что разница будет незначительной.
Я думаю, что это хорошая идея - разбить файлы по иерархии, ни по какой другой причине, если вам когда-нибудь понадобится выпасть и выполнить команду ls в каталоге, это займет меньше времени.
Я не знаю насчет текста4, но стандартный ext2 не может обрабатывать такое количество файлов в одном каталоге, reiserfs (reiser3) был разработан, чтобы справиться с этим хорошо (ls все равно будет уродливым).
Организация файлов больше связана с производительностью и стабильностью файловой системы, чем с производительностью доставки. Я бы отказался от ext2 / ext3 и выбрал xfs или reiser.
Вы действительно захотите изучить кеширование. Будь то встроенное кеширование веб-сервера или сторонний кеш, такой как лак.
Как упоминал kquinn, сравнительный анализ будет реальным индикатором роста / снижения производительности.
Стоит ли вам выгружать эти файлы в amazon S3 ведро и обслуживать их оттуда?
Пусть заботятся об оптимизации.