100к файлов в одной папке

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

Для облегчения этого случая есть:

https://wiki.archlinux.org/index.php/Ext3#Using_Directory_Indexing

но индексы ему всё равно каждый раз перестраивать и поэтому, чтобы не

...используйте другой способ хранения

большого количества файлов - разбивайте их на подкаталоги.

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

Например:

a123.jpg

a222.jpg

b234.jpg

cqwe.jpg

bfd.jpg

Разбиваются на подкаталоги

a/

a123.jpg

a222.jpg

b/

b234.jpg

c/cqwe.jpg

b/bfd.jpg

Разбивка на два (и более) уровней будет выглядеть так

a/1/a123.jpg

a/2/a222.jpg

b/2/b234.jpg

и так далее

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

Ссылка в предыдущем ответе, пропустили? Каталог - это обычный список имён файлов (и их разновидности: каталоги, симлинки и прочия). Когда памяти для кеширования хватает, то жрёт system, обычно, у CPU. В процентах жрёт мало, но увеличивает латентность дисковых операций и чем больше у вас дисковых pps, тем сильнее это заметно. Если шуршите диском мало, то можете даже и не заметить этих стотысячьпитьсот файлов.

Дык там, вроде, идёт речь о построении индексов для директорий :) Типа как в БД.

Как раз чтобы быстрее работало при большом количестве файлов.

Но индексы всё равно не отменяют правила "чем больше данных, тем медленней работает". Только изменяется масштаб )

А без индексов идёт прямой перебор, пока не наткнёмся на нужный файл. Чего же ей делать без индексов то? Список то не сортированный, алгоритмы быстрого поиска неприменимы...

---------- Добавлено 28.02.2012 в 00:12 ----------

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

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

Мужики, с архитектурой я сам понимаю, что "пролетел". Данные есть только в таком виде как есть. Пока мне не понятно про кеширование, мучаю поисковики.

С точки зрения рядового пользователя, понимаю так:

чтение диска: 25кб * 10 картинок * 100 посетителей * 1 секунда = 25000 килобайт или 24,4 мегабайт в секунду. Если файловая система сможет работать в таком режиме на чтение, то проблем не должно возникнуть.

+ Это очень грубый подсчет, т.к навряд ли будет запрос 1000 картинок в секунду, и ответ от сервера не обязан быть за 1 секунду.

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

upd: kpv, про индексы изучаю, спасибо.

Гуглим htree

в ext3 уже работает с dir_index=enabled

в ext4 включена по-умолчанию

Если свой сервер, то на крайний случай всегда есть brute force в виде создания ram диска и монтирования его куда положено. При Ваших текущих 100к файлах по 25кб будет достаточно 3гб. Будет летать.

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

Третий вариант, это все же решить на уровне хотя бы .htaccess и раскладывания файлов по каталогам. Никто не мешает a*.jpg редиректнуть на /home/img/a/, а b*.jpg редиректнуть на /home/images/b. Минимум вмешательства в архитектуру (по сути и не вмешательство вообще), но в результате разнесение файлов физически по разным местам.

Четвертый вариант, он вообще контекстно-зависим, но в принципе никто не мешает допилить хак, который урлы картинок отдаваемых пользователю с http://site.ru/images/a*.jpg будет переписывать на http://a.site.ru/images/a*.jpg например (по сути вариант 3, только на более высоком уровне), тогда Вы эти картинки можете вообще по разным независимым серверам раскидать.

При чем в 3 и 4 варианте можно практически полностью сохранить внутреннею архитектуру, если перед редиректом/сменой урла проверять наличие картинки на новом месте, а картинки в новое место перекладывать неспешно, по крону например. Для облегчения нагрузки результаты проверки наличия картинки в новом месте можно куда-то запоминать (подойдет крошечный мемори кэш вида "адрес картинки" - "реальное хранилово").

p.s.: пятый вариант: врячить ссд:)

edogs советы с редиректами, хаками и прочими перенаправлениями - это очень плохие советы. Оверхед выйдет нереальный. Сами подумайте, что быстрее: отыскать файл в таблице и это на уровне ядра или распарсить регулярку, сопоставить и потом опять отыскать файл?

ТС: выше писал как сделать на ext3 либо переходите на ext4 - там проблема решена уже из коробки

клади по 65к файлов в директорию и будет счастье. и SSD