powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Программирование [игнор отключен] [закрыт для гостей] / алгоритм для хранилища файлов
60 сообщений из 60, показаны все 3 страниц
алгоритм для хранилища файлов
    #38796757
tramadol
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
нужно решить проблему хранения нескольких миллионов файлов на диске.
файлы нужно будет добавлять, читать, и удалять.
первое что пришло в голову это реализовать иерархию папок в виде бинарного дерева, в каждой папке хранить один файл, и еще 2 папки на соседние ноды соответственно, и так далее.
вот только не совсем понятно как потом удалять файлы, так как будут оставаться пустые папки.
подскажите какие еще есть варианты решения данной задачи?
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38796762
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Бинарное дерево - решение более чем ужасное. Про него можешь даже не думать.

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

И я бы предложил именно с этой стороны очень внимательно посмотреть на Novell Netware (не OES/SLES, а именно NW версий 5.1 или 6.5).
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38796766
tramadol
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Akina, это не коммерческий проект а просто задачка в целях обучения.
использую обычную Win 7 на NTFS
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38796770
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tramadolAkina, это не коммерческий проект а просто задачка в целях обучения.
использую обычную Win 7 на NTFS

раз так - посмотри например на https://code.google.com/p/weed-fs/
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38796775
Фотография AndreTM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Может просто хранить "файлы" в БД? Содержимое - в бинарное поле, а "иерархию" имя + любые ваши хотелки - в отдельную таблицу.
Проблема только одна - если будет большАя частота "правки" содержимого файлов. Впрочем, фрагментация и на любой обычной файловой системе - бич тот ещё...
Хотя, нечего придумывать собственный аналог журналируемых ФС
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38796777
tramadol
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изопропил, спс, гляну.
по идее мне нужно реализовать иерархию подобную той где вк хранит картинки?
https://pp.vk.me/c619226/v619226289/1e206/EcVH8rg6ITg.jpg

может кто подскажет как это реализовано у них?
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38796780
tramadol
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AndreTM, БД не катит, задача поставлена именно хранение файлов непосредственно на диске
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38796784
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tramadol,

посмотри как squid файлы хранит
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38796904
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Почитай про elliptics Яндекс его использует для хранения картинок.

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

Затестить несложно: нагенери файлов и замеряй тормоза.
По-хорошему лучше БД использовать, содержимое файлов туда не обязательно грузить, а вот список файлов с точным расположением даст ускорение поиска места хранения файла.
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797065
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tramadolнужно решить проблему хранения нескольких миллионов файлов на диске.
файлы нужно будет добавлять, читать, и удалять.
первое что пришло в голову это реализовать иерархию папок в виде бинарного дерева, в каждой папке хранить один файл, и еще 2 папки на соседние ноды соответственно, и так далее.
вот только не совсем понятно как потом удалять файлы, так как будут оставаться пустые папки.
подскажите какие еще есть варианты решения данной задачи?
Современные файловые системы приблизились уже к БД. У них есть журналы транзакций.
Снапшоты. Восстановление после сбоя и различные варианты Software Raid и LVM в коробке.

Посмотри к примеру Sun/ZFS

https://ru.wikipedia.org/wiki/ZFS

Количество файлов в директории ограничено 2^56.

Никаких бинарных деревьев не нужно придумывать. Логическая структура должна отражать
только бизнес-задачу в ракурсе "запросов". А если дополнительно создавать структуры
symlinks то можно делать даже нечто вроде "индекса".

Но если ты действительно прогрузишь в 1 директорию несколько млн. файлов то
заходить в нее файловым браузером не стоит. Он подвиснет. Возможно. Но это
не проблема твоей задачи или файловой системы. Это только проблема конкретного
файлового браузера.

Пожалуй это единственный недостаток большого количества файлов в папке.
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797066
alex564657498765453
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TПочитай про elliptics Яндекс его использует для хранения картинок.

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

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

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

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

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

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

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

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

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

если скажете что замерять по времени доступа - замерю. (хдд сам счас не интересуюсь, ибо хранилище распределённое, и сетевые задержки счас узкое место а не винчестер)
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797124
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tramadolAkina, это не коммерческий проект а просто задачка в целях обучения.
C этого надо было начинать.

tramadolпервое что пришло в голову
Первое, что ДОЛЖНО БЫЛО прийти в голову - это тщательно изучить, как обстоят дела с хранением большого количества файлов в существующих ФС, хотя бы самых распространённых. Изучить техническую документацию, понять, как именно выполняются хранение и поиск, даже как будут болтаться головы по диску и как на эту болтанку влияет кэширование контроллера диска и ОС.

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

PS. Извините за некоторую резкость суждения.
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797226
Фотография S.G.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton https://ru.wikipedia.org/wiki/ZFS

Количество файлов в директории ограничено 2^56.

Никаких бинарных деревьев не нужно придумывать. Логическая структура должна отражать
только бизнес-задачу в ракурсе "запросов". А если дополнительно создавать структуры
symlinks то можно делать даже нечто вроде "индекса".

Но если ты действительно прогрузишь в 1 директорию несколько млн. файлов то
заходить в нее файловым браузером не стоит. Он подвиснет. Возможно. Но это
не проблема твоей задачи или файловой системы. Это только проблема конкретного
файлового браузера.

+1

Медленное чтение будет, если действительно загрузить в одну директорию миллион файлов.
Но если в одной директории хранить около 1000 файлов, в 1000 директорий получится миллион, без особой задержки, для любой ФС/файлового браузера.
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797364
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alex564657498765453ну вопервых, точное расположение файла не намного ускорит доступ к нему.

от того что вы знаете что в папке1 в папке2 лежит файл3 не означает что система знает где его искать.
Знает. Каталог у NTFS хранится в виде дерева. Получение информации о файле (стартовый кластер/запись в MFT) на основе точного имени получается за O(log N). Для неточного имени нужно полное сканирование каталога, это O(N). Почувствуй разницу.
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797375
alex564657498765453
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakovalex564657498765453ну вопервых, точное расположение файла не намного ускорит доступ к нему.

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

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

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

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

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

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

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

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

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

а дерево нтфс - это её слабое место!
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797378
alex564657498765453
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alex564657498765453,

всмысле нтфс самая медленая из распространёных ФС для работы с деревом папка в паке и разбросаны файлы под нагрузкой
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797382
alex564657498765453
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а всё изза того, что О(Н) сздесь никселу ни к городу.

пример

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

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

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

сегодня для 1.6 млн под такойже нагрузкой сервер и данная команда уже и за 6 минут не справилось устал ждать
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797430
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alex564657498765453не точное имя - это как?FindFirst/FindNext. Ну или readdir в юниксах.
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797452
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Многие из присутсвующих мыслят категориями FAT16/32/DOS. В современных фс
поиск блоков файла по маршруту связан с несколькимими поисками строки
в B+Tree (NTFS) или HTree (ext2/ext3).
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797467
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Двоичное дерево не отменяет необходимость полного чтения каталога для целого ряда сценариев.

P.S. Прежде чем поминать DOS всуе - полезно почитать msdn
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797472
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovДвоичное дерево не отменяет необходимость полного чтения каталога для целого ряда сценариев.

P.S. Прежде чем поминать DOS всуе - полезно почитать msdn
Извини я не понял при чём тут msdn.
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797496
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovДвоичное дерево не отменяет необходимость полного чтения каталога для целого ряда сценариев...
что значит "сценария" и "необходимость полного чтения каталога" ?

понятно, что зайти в такой директорий FAR'ом или эксплорером может быть достаточно долго, когда пойдет создание говно-GUI для ляма файлов. Но к файловой системе это никакого отношения не имеет. Сами же операции с файлами (открыть файл и так далее) от кол-ва файлов в директории сильно зависеть не должны, в отличие от FAT

Автор свои требования назвал "добавлять, читать, и удалять". Подозреваю, что NTFS для данных сценариев замечательно миллион файлов переварит. Директории по > 50 тысяч файлов на компьютере Pentium 166 с 16 Mb RAM на NT 2000 жили замечательно
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797508
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
При том, что FindFirst/FindNext как были частью файлового API DOS, OS/2, Windows - так и остались в его составе.
Кроме того, рассуждая об алгоритмической эффективности двоичного поиска не стОит забывать, что создание файла требует проверки существования имени, что, в свою очередь, требует сериализации в многопоточной среде, что, в свою очередь, существенно влияет на скорость создания новых файлов в "длинных" каталогах.
А так - да, O(log(n)) - весьма быстро.
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797514
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid KudryavtsevАвтор свои требования назвал "добавлять, читать, и удалять". Подозреваю, что NTFS для данных сценариев замечательно миллион файлов переварит. Директории по > 50 тысяч файлов на компьютере Pentium 166 с 16 Mb RAM на NT 2000 жили замечательноЭто всё потому, что при таких ресурсах существенно многопоточный доступ был весьма проблематичен.
Со своей стороны могу сказать, что в реальной системе от хранения файлов в одном каталоге отказались практически сразу. Хотя за пятьдесят тысяч файлов это "хранилище" перевалить успело.
В дальнейшем не выёживались и сделали иерархическую структуру. Хотя и с корявым ключом.
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797523
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovПри том, что FindFirst/FindNext как были частью файлового API DOS, OS/2, Windows - так и остались в его составе....
Если требуется по бизнесу создать список всех миллиона файлов, что FindFirst/FindNext в 1 директории в лям файлов, что тысяча циклов FindFirst/FindNext в каждом из тысячи директориев по тысячи файлов - подозреваю время будет одинаковое )))
Basil A. SidorovКроме того, рассуждая об алгоритмической эффективности двоичного поиска не стОит забывать, что создание файла требует проверки существования имени, что, в свою очередь, требует сериализации в многопоточной среде, что, в свою очередь, существенно влияет на скорость создания новых файлов в "длинных" каталогах.

Что то уж очень умное )))

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

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

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

IMHO & AFAIK
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797528
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid KudryavtsevЕсли требуется по бизнесу создать список всех миллиона файлов, что FindFirst/FindNext в 1 директории в лям файлов, что тысяча циклов FindFirst/FindNext в каждом из тысячи директориев по тысячи файлов - подозреваю время будет одинаковое )))В тысяче (отдельных) каталогов можно организовать многопоточное построение листинаг. На SSD или приличной СХД - будет выигрыш.НО может быть и наоборот , когда одна директория хоть пусть и в миллион файлов будет удобнее.Не могу придумать ни одного разумного сценария.
Из неразумных - только один: "Да мы вообще не заморачивались".
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797535
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid KudryavtsevВ целом мысль уловил.... но это уже от нагрузки зависит. Если происходит сотни/тысячи созданий файлов в секунду, возможно разница будет принципиальнаяПроблема может возникнуть не из-за того, что большая нагрузка, а из-за того, что (никак) несогласованные операции могут (и, вероятно, будут) создавать большие пики при незначительном (в среднем) числе операций.
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797540
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorov...Из неразумных - только один: "Да мы вообще не заморачивались".
При ограниченных сроках и бюджете, имплиментация более менее адекватной реализация фичи "хранить в тысячи директориев" может быть более неразумна ))), чем "просто не заморачиваться". И потратить усилия на что нибудь более бизнес ценное.

Но я уже говорил, что лично мы, в результате, вообще все положили в БД Oracle и перестали "заморачиваться" с файло-помойкой )))
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797547
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorov...
Мысль уловил. Согласен, что в ряде случаев тут может возникнуть бутылочное горлышко

Но из-за чего и как это можно решать, это нужно смотреть на конкретном примере и/или тесте. Чисто "теоретические" рассуждения тут IMHO не катят.

Лично я не знаю. Не сталкивался.
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797550
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tramadolнужно решить проблему хранения нескольких миллионов файлов на диске.
файлы нужно будет добавлять, читать, и удалять.
первое что пришло в голову это реализовать иерархию папок в виде бинарного дерева, в каждой папке хранить один файл, и еще 2 папки на соседние ноды соответственно, и так далее.
вот только не совсем понятно как потом удалять файлы, так как будут оставаться пустые папки.
подскажите какие еще есть варианты решения данной задачи?
я был за хранение в бд. Но на деле хранили так

авторcd ./temp/
cd ./bavarian
mkdir fs
cd ./bavarian/fs
mkdir fs/usrpics
cd ./bavarian/fs/usrpics
mkdir fs/usrpics/c8
cd ./bavarian/fs/usrpics/c8
mkdir fs/usrpics/c8/20
cd ./bavarian/fs/usrpics/c8/20
fs/usrpics/c8/20/c8209bcfee104a239e682aa3eb4dbc74.jpg
fs/usrpics/c8/20/c8209b2416a047a193959773fb707641.jpg
fs/usrpics/c8/20/c8205b265cee4aff8c3837cbd025e263.jpg
mkdir fs/usrpics/c8/1f
cd ./bavarian/fs/usrpics/c8/1f
fs/usrpics/c8/1f/c81ff4df41ac483b83f46bbaa8f3fcc6.jpg
fs/usrpics/c8/1f/c81ff262406649e0a1958e0ba6b61dba.jpg
fs/usrpics/c8/1f/c81fc3f36c33440f94a9b88deb4305a0.jpg
fs/usrpics/c8/1f/c81fbda31f90477cb5b91172be21bc58.jpg
fs/usrpics/c8/1f/c81f97259a154359a0c1ceac784e96d6.jpg
fs/usrpics/c8/1f/c81f08ca8bfc492f964c3c0e9a432b8e.jpg
mkdir fs/usrpics/c8/1d
cd ./bavarian/fs/usrpics/c8/1d
fs/usrpics/c8/1d/c81df1cbe19a451591ad62700681a295.jpg
каталог из 256 каталогов, в каждом из которых 256 каталогов, а там файлы.
Может
256 * 256 = 65536 листьев = маловато для миллионов файлов, но
но 256* 256 * 256 = 16777216 и хватит

реальные имена хранились в бд
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797552
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ааа если 65536 каталогов-листьев,
то при 256 файлах в каталоге получается 16 миллионов файлов

файловая система ntfs - сервера на win2000
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797658
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Обсуждение max-files-per-directory on NTFS

http://superuser.com/questions/446282/max-files-per-directory-on-ntfs-vol-vs-fat32

Автор приводит пруфы. Не читал.

По нашему сабжу.

Цена спора идёт о чём?

Создавать ли

Код: sql
1.
c:/dir1/dir2/dir3/file1.txt



Или класть

Код: sql
1.
c:/concat(dir1,dir2,dir3,file1.txt)



Или возможные варианты с суб-строками, в различных пропорциях. Думаю что файловой системе на базе NTFS
будет пофигу какой вариант. Лишь бы количество файлов в 1 каталоге (или корне) не превышало 4,294,967,295.

Варианты с dir1/dir2... могут быть более юзабельны. В них есть "контетекст" от которого Application может получить
различные оптимизации. Например работая с физ-лицом мы можем получить HANDLE (io.File) объект директории
или "текущий узел" в ФС работать соотвествтенно без ненужных оверхедов глобального поиска.

Генерировать из файлового имени хеш или ключ с линейной гистограммой считаю ненужным занятием.
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797754
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Файл должен получать номер по порядку создания и этот номер, преобразованный в строку и дополненный слева нулями до фиксированной длины, должен использоваться в качестве имени файла внутри хранилища.
Сами файлы должны храниться в двухуровневой иерархии: первый уровень - до тысячи каталогов относительно "базы" хранилища, второй - до тысячи вложенных каталогов второго уровня, в каждом из которых уже и размещается до тысячи файлов.
Трансформацией путей и имён хранилища в имена, которые будут использоваться вне хранилища должна заниматься база.
Иначе легко попасть на грабли с (не)чувствительностью к регистру и с локальными кодировками.

P.S. То, что сову можно натянуть на глобус, ещё не значит, что надо закладывать хранение (хотя бы) десятков тысяч имён в одном каталоге.
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797764
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вы описываете конкретное решение, какой-то конкретной задачи с конкретными требованиями.

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

не все так однозначно ( C ) дочь офицера

IMHO & AFAIK
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797765
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorov....P.S. То, что сову можно натянуть на глобус...
что, насколько я знаю, называется фистинг. Вполне себе используемая около сексуальная практика )))
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797776
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid KudryavtsevВы описываете конкретное решение, какой-то конкретной задачи с конкретными требованиямиПри хранении миллиона файлов особых вариантов нет. На самом деле. Это вам любой кэширующий прокси скажет :)
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797875
tramadol
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
всем спасибо за комментарии.
на самом деле мне вчера тоже в голову пришла идея которая уже упоминалась здесь.
идея заключается в том чтобы брать md5 хеш у имени файла и на его основе генерировать иерархию папок.
вот только еще не понял что для NTFS будет более производительней работать, большая высота дерева папок и в конечной папке по 1 файлу, или минимальная высота дерева и в каждой папке по несколько десятков тысяч файлов?
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797883
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Несколько сотен файлов в каталоге и высота "какая получится".
Тысяча файлов и два уровня каталогов позволяют сохранить до миллиарда файлов.
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797913
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tramadol, что тебе даёт md5 в данном конкретном случае?
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797935
tramadol
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton,

при записи, равномерное распределение файлов по каталогам.
при чтении и удалении, доступ к файлу за O(1)
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797941
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tramadolпри записи, равномерное распределение файлов по каталогам.
при чтении и удалении, доступ к файлу за O(1)1. "But how?" (ц) английский анекдот;
2. Не зависит от имени файла.
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797944
tramadol
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorov,

не совсем понял что вы хотите услышать.
или может канешно я чего то не понимаю еще
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797946
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Каким образом MD5, превращённый в строку "подскажет" в каком каталоге должна находиться "эта строка"?
С какого перепугу время поиска файла зависит от его имени?
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797972
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovКаким образом MD5, превращённый в строку "подскажет" в каком каталоге должна находиться "эта строка"?
например, отделяем от полученного имени 2-3 группы по 2-3 цифры,
группы и дадут путь (md5 запишем в виде строки с основанием скажем 16 или 36)
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797975
tramadol
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorov,

например:
сохраняем файл file1.txt, берем мд5 хеш от его имени 826e8142e6baabe8af779f5f490cf5f5, генерируем путь по которому он файл будет храниться rootFolder\826\e814\2e6baabe8af779f5f490cf5f5.txt
читаем или удаляем файл, получаем имя удаляемого файла file1.txt, берем мд5 хеш от его имени 826e8142e6baabe8af779f5f490cf5f5,
удаляем или читаем файл по адресу rootFolder\826\e814\2e6baabe8af779f5f490cf5f5.txt
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797982
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изопропилнапример, отделяем от полученного имени 2-3 группы по 2-3 цифры,
группы и дадут путь (md5 запишем в виде строки с основанием скажем 16 или 36)Это всё, конечно, зашибись, но если нумеровать файлы последовательно, то (потенциальный) миллиард даёт девять десятичных цифр и компактное дерево глубиной два уровня.
Использование MD5 потребует организовывать дерево для (потенциальных) 2**128 файлов.
Это сильно разреженное дерево совсем другой глубины. Оно надо? А главное - зачем?
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38797998
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tramadolсохраняем файл file1.txt, берем мд5 хеш от его имениВ какой кодировке берём?
Что делаем, если сегодня отдали имя file1.txt, а завтра запрашивают имя FILE1.TXT?
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38798005
tramadol
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorov,

вы имеете в виду кодировку символов?
а какое это имеет значение?
если сохранили file1.txt а хотят удалить FILE1.TXT говорим что нету такого файла
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38798006
tramadol
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ну или переводим имя файла в нижний кейс и удаляем файл
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38798010
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tramadolвы имеете в виду кодировку символов?
а какое это имеет значение?Принципиальное.
file1.txt в US-ASCII, UTF16 и UTF-32 - три разные последовательности байт.если сохранили file1.txt а хотят удалить FILE1.TXT говорим что нету такого файлаТ.е. у всех виндовых пользователей должен произойти разрыв мозгов и шаблонов?
А что будем делать, если два пользователя пытаются сохранить два разных файла под одинаковым именем?
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38798022
tramadol
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovТ.е. у всех виндовых пользователей должен произойти разрыв мозгов и шаблонов?
нуда, это я протупил, тогда изначально берем md5 из имени в нижнем регистре

Basil A. SidorovА что будем делать, если два пользователя пытаются сохранить два разных файла под одинаковым именем?
как вариант, сравнивать размеры?
тут нужно подумать, но это уже нюансы дизайна программы.
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38798029
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Дизайн может быть один: на самом начальном этапе естественный ключ (имя) превращается в суррогатный (монотонно растущий номер).
Хранилище работает только с суррогатным ключом, а связка двух ключей (естественного и суррогатного) хранится и обрабатывается отдельно.
После этого не имеет ни малейшего значения "отщипываем" мы группы символов от упорядоченного номера или от псевдослучайного хэша.
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38798315
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я так и не услышал никакого обоснования по поводу функции MD5 применительно
к файловой системе.
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38798367
alex564657498765453
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid KudryavtsevBasil A. SidorovДвоичное дерево не отменяет необходимость полного чтения каталога для целого ряда сценариев...
что значит "сценария" и "необходимость полного чтения каталога" ?

понятно, что зайти в такой директорий FAR'ом или эксплорером может быть достаточно долго, когда пойдет создание говно-GUI для ляма файлов. Но к файловой системе это никакого отношения не имеет. Сами же операции с файлами (открыть файл и так далее) от кол-ва файлов в директории сильно зависеть не должны, в отличие от FAT

Автор свои требования назвал "добавлять, читать, и удалять". Подозреваю, что NTFS для данных сценариев замечательно миллион файлов переварит. Директории по > 50 тысяч файлов на компьютере Pentium 166 с 16 Mb RAM на NT 2000 жили замечательно

вы в своём коде как открываете файл? с проверкой существования или без?
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38798376
alex564657498765453
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid KudryavtsevBasil A. Sidorov...Из неразумных - только один: "Да мы вообще не заморачивались".
При ограниченных сроках и бюджете, имплиментация более менее адекватной реализация фичи "хранить в тысячи директориев" может быть более неразумна ))), чем "просто не заморачиваться". И потратить усилия на что нибудь более бизнес ценное.

Но я уже говорил, что лично мы, в результате, вообще все положили в БД Oracle и перестали "заморачиваться" с файло-помойкой )))

это ерунда... при любом лимите времени, а особено если нету времени дублировать код то будет чтото типа

будет функция сохранения файла по имени используемого в работе с файлом., которая будет вызывать функцию - которая определит путь сохранения...
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38799029
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alex564657498765453вы в своём коде как открываете файл? с проверкой существования или без?Где-то появилось файловое API не возвращающее ошибок?
Или выросло поколение самонадеянных программистов, никогда не совершающих ошибки?
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38799448
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tramadolAkina, это не коммерческий проект а просто задачка в целях обучения.
использую обычную Win 7 на NTFS

а зачем учиться на идиотских задачах?
кому нужны миллионы файлов?
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38799483
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivкому нужны миллионы файлов?Не сказать, чтобы каждому встречному, но - нужны.
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38799710
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivкому нужны миллионы файлов?
Например, HTTP кэш.
В проекте, где я участвую, типичный кэш содержит десятки миллионов файлов.
Можно конечно хранить кэш в СУБД, но в готовых СУБД есть не нужные для этой задачи оверхеды, а в самописной - сложность реализации, с учетом всех нюансов работы (защита от падений, работа с дисковым кэшем и пр).
Файлы - нормальный компромис.
...
Рейтинг: 0 / 0
алгоритм для хранилища файлов
    #38800120
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly MoskovskyВ проекте, где я участвую, типичный кэш содержит десятки миллионов файлов.


Какой-то большой кэш... не кажется ?
...
Рейтинг: 0 / 0
60 сообщений из 60, показаны все 3 страниц
Форумы / Программирование [игнор отключен] [закрыт для гостей] / алгоритм для хранилища файлов
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]