Dima TПочитай про elliptics Яндекс его использует для хранения картинок.

По одному файлу в папке перебор. Для миллиона достаточно двух уровней: несколько тысяч подпапок, в каждой несколько тысяч файлов.
Миллион файлов не пробовал, 5-10 тысяч нормально обрабатываются в одной папке.

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

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

от того что вы знаете что в папке1 в папке2 лежит файл3 не означает что система знает где его искать.

ей всеравно надо считать данные корневого каталога - не выж один умный програмист, а и тот кто писал ОС - стоит команда - если не существует папки1 выход иначе читаем адрес расположения данных папки1, читаем шдд с нового места - аналогично смотрим существует ли папка2, и если да то читаем где её данные, и только в её даных проверив что файл3 существует идём в нужное место на шдд и читаем.

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

итого - если у тебя в корне 30 папко в каждой по до 10, и в каждой до 100 файлов, и в одной из них 10000 файлов и у тебя быстро, вовсе не означает

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

ЗЫ
у меня хранение файлов идёт в подпапках 3 шестнадцетиричные цифры...тоесть 4096 подпапок. сейчас проверил... по ним раскидано 1.6+млн файлов.

если скажете что замерять по времени доступа - замерю. (хдд сам счас не интересуюсь, ибо хранилище распределённое, и сетевые задержки счас узкое место а не винчестер)

Dimitry Sibiryakovalex564657498765453ну вопервых, точное расположение файла не намного ускорит доступ к нему.

от того что вы знаете что в папке1 в папке2 лежит файл3 не означает что система знает где его искать.
Знает. Каталог у NTFS хранится в виде дерева. Получение информации о файле (стартовый кластер/запись в MFT) на основе точного имени получается за O(log N). Для неточного имени нужно полное сканирование каталога, это O(N). Почувствуй разницу.

не точное имя - это как?

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

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

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

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

я к чему виду...что экономия получиться на уменьшении числа прыжков по фс.

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

вместо лишнего прыжка из папки в подпапку.

а дерево нтфс - это её слабое место!

alex564657498765453,

всмысле нтфс самая медленая из распространёных ФС для работы с деревом папка в паке и разбросаны файлы под нагрузкой

а всё изза того, что О(Н) сздесь никселу ни к городу.

пример

find -type f | grep -c './'

в обоих случаях О(Н)

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

сегодня для 1.6 млн под такойже нагрузкой сервер и данная команда уже и за 6 минут не справилось устал ждать