|
|
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
нужно решить проблему хранения нескольких миллионов файлов на диске. файлы нужно будет добавлять, читать, и удалять. первое что пришло в голову это реализовать иерархию папок в виде бинарного дерева, в каждой папке хранить один файл, и еще 2 папки на соседние ноды соответственно, и так далее. вот только не совсем понятно как потом удалять файлы, так как будут оставаться пустые папки. подскажите какие еще есть варианты решения данной задачи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2014, 21:43 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Бинарное дерево - решение более чем ужасное. Про него можешь даже не думать. Для начала неплохо бы озвучить файловую систему, на которой это происходит. А ещё лучше - начать именно с подбора файловой системы, предназначенной именно для работы с каталогами, содержащими миллионы файлов. Или даже платформы. И я бы предложил именно с этой стороны очень внимательно посмотреть на Novell Netware (не OES/SLES, а именно NW версий 5.1 или 6.5). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2014, 21:56 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Akina, это не коммерческий проект а просто задачка в целях обучения. использую обычную Win 7 на NTFS ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2014, 22:09 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
tramadolAkina, это не коммерческий проект а просто задачка в целях обучения. использую обычную Win 7 на NTFS раз так - посмотри например на https://code.google.com/p/weed-fs/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2014, 22:16 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Может просто хранить "файлы" в БД? Содержимое - в бинарное поле, а "иерархию" имя + любые ваши хотелки - в отдельную таблицу. Проблема только одна - если будет большАя частота "правки" содержимого файлов. Впрочем, фрагментация и на любой обычной файловой системе - бич тот ещё... Хотя, нечего придумывать собственный аналог журналируемых ФС ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2014, 22:28 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Изопропил, спс, гляну. по идее мне нужно реализовать иерархию подобную той где вк хранит картинки? https://pp.vk.me/c619226/v619226289/1e206/EcVH8rg6ITg.jpg может кто подскажет как это реализовано у них? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2014, 22:31 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
AndreTM, БД не катит, задача поставлена именно хранение файлов непосредственно на диске ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2014, 22:34 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
tramadol, посмотри как squid файлы хранит ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2014, 22:47 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Почитай про elliptics Яндекс его использует для хранения картинок. По одному файлу в папке перебор. Для миллиона достаточно двух уровней: несколько тысяч подпапок, в каждой несколько тысяч файлов. Миллион файлов не пробовал, 5-10 тысяч нормально обрабатываются в одной папке. Затестить несложно: нагенери файлов и замеряй тормоза. По-хорошему лучше БД использовать, содержимое файлов туда не обязательно грузить, а вот список файлов с точным расположением даст ускорение поиска места хранения файла. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 07:05 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
tramadolнужно решить проблему хранения нескольких миллионов файлов на диске. файлы нужно будет добавлять, читать, и удалять. первое что пришло в голову это реализовать иерархию папок в виде бинарного дерева, в каждой папке хранить один файл, и еще 2 папки на соседние ноды соответственно, и так далее. вот только не совсем понятно как потом удалять файлы, так как будут оставаться пустые папки. подскажите какие еще есть варианты решения данной задачи? Современные файловые системы приблизились уже к БД. У них есть журналы транзакций. Снапшоты. Восстановление после сбоя и различные варианты Software Raid и LVM в коробке. Посмотри к примеру Sun/ZFS https://ru.wikipedia.org/wiki/ZFS Количество файлов в директории ограничено 2^56. Никаких бинарных деревьев не нужно придумывать. Логическая структура должна отражать только бизнес-задачу в ракурсе "запросов". А если дополнительно создавать структуры symlinks то можно делать даже нечто вроде "индекса". Но если ты действительно прогрузишь в 1 директорию несколько млн. файлов то заходить в нее файловым браузером не стоит. Он подвиснет. Возможно. Но это не проблема твоей задачи или файловой системы. Это только проблема конкретного файлового браузера. Пожалуй это единственный недостаток большого количества файлов в папке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 11:05 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Dima TПочитай про elliptics Яндекс его использует для хранения картинок. По одному файлу в папке перебор. Для миллиона достаточно двух уровней: несколько тысяч подпапок, в каждой несколько тысяч файлов. Миллион файлов не пробовал, 5-10 тысяч нормально обрабатываются в одной папке. Затестить несложно: нагенери файлов и замеряй тормоза. По-хорошему лучше БД использовать, содержимое файлов туда не обязательно грузить, а вот список файлов с точным расположением даст ускорение поиска места хранения файла. ну вопервых, точное расположение файла не намного ускорит доступ к нему. от того что вы знаете что в папке1 в папке2 лежит файл3 не означает что система знает где его искать. ей всеравно надо считать данные корневого каталога - не выж один умный програмист, а и тот кто писал ОС - стоит команда - если не существует папки1 выход иначе читаем адрес расположения данных папки1, читаем шдд с нового места - аналогично смотрим существует ли папка2, и если да то читаем где её данные, и только в её даных проверив что файл3 существует идём в нужное место на шдд и читаем. в реальности это только первый раз долго, второй раз заглянуть в туже папку будет быстрее - ибо идёт кеширование файловой системы. итого - если у тебя в корне 30 папко в каждой по до 10, и в каждой до 100 файлов, и в одной из них 10000 файлов и у тебя быстро, вовсе не означает что при 10000 папок в каждой по 10000 файлов у тебя будет быстро работать в многопользовательском режиме система. ЗЫ у меня хранение файлов идёт в подпапках 3 шестнадцетиричные цифры...тоесть 4096 подпапок. сейчас проверил... по ним раскидано 1.6+млн файлов. если скажете что замерять по времени доступа - замерю. (хдд сам счас не интересуюсь, ибо хранилище распределённое, и сетевые задержки счас узкое место а не винчестер) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 11:06 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
tramadolAkina, это не коммерческий проект а просто задачка в целях обучения. C этого надо было начинать. tramadolпервое что пришло в голову Первое, что ДОЛЖНО БЫЛО прийти в голову - это тщательно изучить, как обстоят дела с хранением большого количества файлов в существующих ФС, хотя бы самых распространённых. Изучить техническую документацию, понять, как именно выполняются хранение и поиск, даже как будут болтаться головы по диску и как на эту болтанку влияет кэширование контроллера диска и ОС. Вы же сгенерили на пустом месте идею (из категории "ляпнуть хоть что-то") и бросились задавать вопросы. Так не учатся. PS. Извините за некоторую резкость суждения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 11:58 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
mayton https://ru.wikipedia.org/wiki/ZFS Количество файлов в директории ограничено 2^56. Никаких бинарных деревьев не нужно придумывать. Логическая структура должна отражать только бизнес-задачу в ракурсе "запросов". А если дополнительно создавать структуры symlinks то можно делать даже нечто вроде "индекса". Но если ты действительно прогрузишь в 1 директорию несколько млн. файлов то заходить в нее файловым браузером не стоит. Он подвиснет. Возможно. Но это не проблема твоей задачи или файловой системы. Это только проблема конкретного файлового браузера. +1 Медленное чтение будет, если действительно загрузить в одну директорию миллион файлов. Но если в одной директории хранить около 1000 файлов, в 1000 директорий получится миллион, без особой задержки, для любой ФС/файлового браузера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 13:13 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
alex564657498765453ну вопервых, точное расположение файла не намного ускорит доступ к нему. от того что вы знаете что в папке1 в папке2 лежит файл3 не означает что система знает где его искать. Знает. Каталог у NTFS хранится в виде дерева. Получение информации о файле (стартовый кластер/запись в MFT) на основе точного имени получается за O(log N). Для неточного имени нужно полное сканирование каталога, это O(N). Почувствуй разницу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 15:04 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakovalex564657498765453ну вопервых, точное расположение файла не намного ускорит доступ к нему. от того что вы знаете что в папке1 в папке2 лежит файл3 не означает что система знает где его искать. Знает. Каталог у NTFS хранится в виде дерева. Получение информации о файле (стартовый кластер/запись в MFT) на основе точного имени получается за O(log N). Для неточного имени нужно полное сканирование каталога, это O(N). Почувствуй разницу. не точное имя - это как? речь шла о ...как я подумал, что человек щитает, что если он знает точное имя файла с полным путём, то сразу система знает где его искать...аля хеш от полного пути и в базе сразу видим адресс. и расписал, что всёравно процесс итерационный...по каждой папке в глубину будет ити обработка... тоесть что выполнять команды сд пока не доёдешь до нужной папки и потом кат - вывод файла, что сразу задать кат полный путь, пропуская издержки самих вызовов сд, а сконцентрировавшись на операциях чтения с шдд самой файловой системы(файловая система читает а не мы читаем фс) - число чтений и что именно считываеться будет одинаково... и когда я говорил что для одной папки с 10000 быстро не означает 10000 папок и 10000 файлов в каждой будет быстро - речь шла имено о работе кеша файловой системы. одна большая папка - лежит себе этот большой кусок в памяти и лежит. при 10000 больших кусков все в кеш не вместиться, и получиться что на каждый файл(предположительно в разных папках) мы будем проходить всё дерево... я к чему виду...что экономия получиться на уменьшении числа прыжков по фс. вот и получаем - что для таких задач, лучше искать файловую систему ращитаную на большое число файлов...и такие фс не с увеличеным кешем для приколов с подкаталогами, а с индексацией, для того чтоб в одной папке лежало много файлов, а в кеше лежал индекс, что по имени файла мы знаем сразу какой кусок списка каталога считать вместо лишнего прыжка из папки в подпапку. а дерево нтфс - это её слабое место! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 15:17 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
alex564657498765453, всмысле нтфс самая медленая из распространёных ФС для работы с деревом папка в паке и разбросаны файлы под нагрузкой ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 15:18 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
а всё изза того, что О(Н) сздесь никселу ни к городу. пример find -type f | grep -c './' в обоих случаях О(Н) но для 100 000 файлов подобная процедура проходила..точно не помню но до минуты...я ждал но не долго(сервер был тоже под нагрузкой) сегодня для 1.6 млн под такойже нагрузкой сервер и данная команда уже и за 6 минут не справилось устал ждать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 15:21 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
alex564657498765453не точное имя - это как?FindFirst/FindNext. Ну или readdir в юниксах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 15:54 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Многие из присутсвующих мыслят категориями FAT16/32/DOS. В современных фс поиск блоков файла по маршруту связан с несколькимими поисками строки в B+Tree (NTFS) или HTree (ext2/ext3). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 16:10 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Двоичное дерево не отменяет необходимость полного чтения каталога для целого ряда сценариев. P.S. Прежде чем поминать DOS всуе - полезно почитать msdn ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 16:23 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovДвоичное дерево не отменяет необходимость полного чтения каталога для целого ряда сценариев. P.S. Прежде чем поминать DOS всуе - полезно почитать msdn Извини я не понял при чём тут msdn. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 16:27 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovДвоичное дерево не отменяет необходимость полного чтения каталога для целого ряда сценариев... что значит "сценария" и "необходимость полного чтения каталога" ? понятно, что зайти в такой директорий FAR'ом или эксплорером может быть достаточно долго, когда пойдет создание говно-GUI для ляма файлов. Но к файловой системе это никакого отношения не имеет. Сами же операции с файлами (открыть файл и так далее) от кол-ва файлов в директории сильно зависеть не должны, в отличие от FAT Автор свои требования назвал "добавлять, читать, и удалять". Подозреваю, что NTFS для данных сценариев замечательно миллион файлов переварит. Директории по > 50 тысяч файлов на компьютере Pentium 166 с 16 Mb RAM на NT 2000 жили замечательно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 16:44 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
При том, что FindFirst/FindNext как были частью файлового API DOS, OS/2, Windows - так и остались в его составе. Кроме того, рассуждая об алгоритмической эффективности двоичного поиска не стОит забывать, что создание файла требует проверки существования имени, что, в свою очередь, требует сериализации в многопоточной среде, что, в свою очередь, существенно влияет на скорость создания новых файлов в "длинных" каталогах. А так - да, O(log(n)) - весьма быстро. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 16:50 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevАвтор свои требования назвал "добавлять, читать, и удалять". Подозреваю, что NTFS для данных сценариев замечательно миллион файлов переварит. Директории по > 50 тысяч файлов на компьютере Pentium 166 с 16 Mb RAM на NT 2000 жили замечательноЭто всё потому, что при таких ресурсах существенно многопоточный доступ был весьма проблематичен. Со своей стороны могу сказать, что в реальной системе от хранения файлов в одном каталоге отказались практически сразу. Хотя за пятьдесят тысяч файлов это "хранилище" перевалить успело. В дальнейшем не выёживались и сделали иерархическую структуру. Хотя и с корявым ключом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 16:55 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovПри том, что FindFirst/FindNext как были частью файлового API DOS, OS/2, Windows - так и остались в его составе.... Если требуется по бизнесу создать список всех миллиона файлов, что FindFirst/FindNext в 1 директории в лям файлов, что тысяча циклов FindFirst/FindNext в каждом из тысячи директориев по тысячи файлов - подозреваю время будет одинаковое ))) Basil A. SidorovКроме того, рассуждая об алгоритмической эффективности двоичного поиска не стОит забывать, что создание файла требует проверки существования имени, что, в свою очередь, требует сериализации в многопоточной среде, что, в свою очередь, существенно влияет на скорость создания новых файлов в "длинных" каталогах. Что то уж очень умное ))) В целом мысль уловил.... но это уже от нагрузки зависит. Если происходит сотни/тысячи созданий файлов в секунду, возможно разница будет принципиальная Но, мне кажется, что в файловой системе затыки произойдут значительно раньше. === По большей части, решение определяется набором требуемых операций. Если просто хранилище файлов и их отдача - думаю разница не большая. Если требуется какие-то другие работы - резервирование, заходить в директории FAR'ом, архивировать, переность. То, возможно тысяча директориев по тысячи файлов будет удобнее. НО может быть и наоборот , когда одна директория хоть пусть и в миллион файлов будет удобнее. IMHO & AFAIK ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 17:01 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevЕсли требуется по бизнесу создать список всех миллиона файлов, что FindFirst/FindNext в 1 директории в лям файлов, что тысяча циклов FindFirst/FindNext в каждом из тысячи директориев по тысячи файлов - подозреваю время будет одинаковое )))В тысяче (отдельных) каталогов можно организовать многопоточное построение листинаг. На SSD или приличной СХД - будет выигрыш.НО может быть и наоборот , когда одна директория хоть пусть и в миллион файлов будет удобнее.Не могу придумать ни одного разумного сценария. Из неразумных - только один: "Да мы вообще не заморачивались". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 17:06 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevВ целом мысль уловил.... но это уже от нагрузки зависит. Если происходит сотни/тысячи созданий файлов в секунду, возможно разница будет принципиальнаяПроблема может возникнуть не из-за того, что большая нагрузка, а из-за того, что (никак) несогласованные операции могут (и, вероятно, будут) создавать большие пики при незначительном (в среднем) числе операций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 17:10 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Basil A. Sidorov...Из неразумных - только один: "Да мы вообще не заморачивались". При ограниченных сроках и бюджете, имплиментация более менее адекватной реализация фичи "хранить в тысячи директориев" может быть более неразумна ))), чем "просто не заморачиваться". И потратить усилия на что нибудь более бизнес ценное. Но я уже говорил, что лично мы, в результате, вообще все положили в БД Oracle и перестали "заморачиваться" с файло-помойкой ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 17:11 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Basil A. Sidorov... Мысль уловил. Согласен, что в ряде случаев тут может возникнуть бутылочное горлышко Но из-за чего и как это можно решать, это нужно смотреть на конкретном примере и/или тесте. Чисто "теоретические" рассуждения тут IMHO не катят. Лично я не знаю. Не сталкивался. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 17:16 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
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 и хватит реальные имена хранились в бд ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 17:17 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
ааа если 65536 каталогов-листьев, то при 256 файлах в каталоге получается 16 миллионов файлов файловая система ntfs - сервера на win2000 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 17:19 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Обсуждение max-files-per-directory on NTFS http://superuser.com/questions/446282/max-files-per-directory-on-ntfs-vol-vs-fat32 Автор приводит пруфы. Не читал. По нашему сабжу. Цена спора идёт о чём? Создавать ли Код: sql 1. Или класть Код: sql 1. Или возможные варианты с суб-строками, в различных пропорциях. Думаю что файловой системе на базе NTFS будет пофигу какой вариант. Лишь бы количество файлов в 1 каталоге (или корне) не превышало 4,294,967,295. Варианты с dir1/dir2... могут быть более юзабельны. В них есть "контетекст" от которого Application может получить различные оптимизации. Например работая с физ-лицом мы можем получить HANDLE (io.File) объект директории или "текущий узел" в ФС работать соотвествтенно без ненужных оверхедов глобального поиска. Генерировать из файлового имени хеш или ключ с линейной гистограммой считаю ненужным занятием. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 18:37 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Файл должен получать номер по порядку создания и этот номер, преобразованный в строку и дополненный слева нулями до фиксированной длины, должен использоваться в качестве имени файла внутри хранилища. Сами файлы должны храниться в двухуровневой иерархии: первый уровень - до тысячи каталогов относительно "базы" хранилища, второй - до тысячи вложенных каталогов второго уровня, в каждом из которых уже и размещается до тысячи файлов. Трансформацией путей и имён хранилища в имена, которые будут использоваться вне хранилища должна заниматься база. Иначе легко попасть на грабли с (не)чувствительностью к регистру и с локальными кодировками. P.S. То, что сову можно натянуть на глобус, ещё не значит, что надо закладывать хранение (хотя бы) десятков тысяч имён в одном каталоге. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 20:18 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Вы описываете конкретное решение, какой-то конкретной задачи с конкретными требованиями. При других начальных требованиях, все, начиная с "Файл должен получать номер..." может оказаться ошибочным. не все так однозначно ( C ) дочь офицера IMHO & AFAIK ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 20:31 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Basil A. Sidorov....P.S. То, что сову можно натянуть на глобус... что, насколько я знаю, называется фистинг. Вполне себе используемая около сексуальная практика ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 20:33 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevВы описываете конкретное решение, какой-то конкретной задачи с конкретными требованиямиПри хранении миллиона файлов особых вариантов нет. На самом деле. Это вам любой кэширующий прокси скажет :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 20:57 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
всем спасибо за комментарии. на самом деле мне вчера тоже в голову пришла идея которая уже упоминалась здесь. идея заключается в том чтобы брать md5 хеш у имени файла и на его основе генерировать иерархию папок. вот только еще не понял что для NTFS будет более производительней работать, большая высота дерева папок и в конечной папке по 1 файлу, или минимальная высота дерева и в каждой папке по несколько десятков тысяч файлов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 23:31 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Несколько сотен файлов в каталоге и высота "какая получится". Тысяча файлов и два уровня каталогов позволяют сохранить до миллиарда файлов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2014, 23:37 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
tramadol, что тебе даёт md5 в данном конкретном случае? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2014, 00:11 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
mayton, при записи, равномерное распределение файлов по каталогам. при чтении и удалении, доступ к файлу за O(1) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2014, 00:33 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
tramadolпри записи, равномерное распределение файлов по каталогам. при чтении и удалении, доступ к файлу за O(1)1. "But how?" (ц) английский анекдот; 2. Не зависит от имени файла. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2014, 00:35 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Basil A. Sidorov, не совсем понял что вы хотите услышать. или может канешно я чего то не понимаю еще ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2014, 00:38 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Каким образом MD5, превращённый в строку "подскажет" в каком каталоге должна находиться "эта строка"? С какого перепугу время поиска файла зависит от его имени? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2014, 00:40 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovКаким образом MD5, превращённый в строку "подскажет" в каком каталоге должна находиться "эта строка"? например, отделяем от полученного имени 2-3 группы по 2-3 цифры, группы и дадут путь (md5 запишем в виде строки с основанием скажем 16 или 36) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2014, 01:08 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Basil A. Sidorov, например: сохраняем файл file1.txt, берем мд5 хеш от его имени 826e8142e6baabe8af779f5f490cf5f5, генерируем путь по которому он файл будет храниться rootFolder\826\e814\2e6baabe8af779f5f490cf5f5.txt читаем или удаляем файл, получаем имя удаляемого файла file1.txt, берем мд5 хеш от его имени 826e8142e6baabe8af779f5f490cf5f5, удаляем или читаем файл по адресу rootFolder\826\e814\2e6baabe8af779f5f490cf5f5.txt ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2014, 01:11 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Изопропилнапример, отделяем от полученного имени 2-3 группы по 2-3 цифры, группы и дадут путь (md5 запишем в виде строки с основанием скажем 16 или 36)Это всё, конечно, зашибись, но если нумеровать файлы последовательно, то (потенциальный) миллиард даёт девять десятичных цифр и компактное дерево глубиной два уровня. Использование MD5 потребует организовывать дерево для (потенциальных) 2**128 файлов. Это сильно разреженное дерево совсем другой глубины. Оно надо? А главное - зачем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2014, 01:15 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
tramadolсохраняем файл file1.txt, берем мд5 хеш от его имениВ какой кодировке берём? Что делаем, если сегодня отдали имя file1.txt, а завтра запрашивают имя FILE1.TXT? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2014, 01:26 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Basil A. Sidorov, вы имеете в виду кодировку символов? а какое это имеет значение? если сохранили file1.txt а хотят удалить FILE1.TXT говорим что нету такого файла ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2014, 01:36 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
ну или переводим имя файла в нижний кейс и удаляем файл ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2014, 01:38 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
tramadolвы имеете в виду кодировку символов? а какое это имеет значение?Принципиальное. file1.txt в US-ASCII, UTF16 и UTF-32 - три разные последовательности байт.если сохранили file1.txt а хотят удалить FILE1.TXT говорим что нету такого файлаТ.е. у всех виндовых пользователей должен произойти разрыв мозгов и шаблонов? А что будем делать, если два пользователя пытаются сохранить два разных файла под одинаковым именем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2014, 01:43 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovТ.е. у всех виндовых пользователей должен произойти разрыв мозгов и шаблонов? нуда, это я протупил, тогда изначально берем md5 из имени в нижнем регистре Basil A. SidorovА что будем делать, если два пользователя пытаются сохранить два разных файла под одинаковым именем? как вариант, сравнивать размеры? тут нужно подумать, но это уже нюансы дизайна программы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2014, 01:55 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Дизайн может быть один: на самом начальном этапе естественный ключ (имя) превращается в суррогатный (монотонно растущий номер). Хранилище работает только с суррогатным ключом, а связка двух ключей (естественного и суррогатного) хранится и обрабатывается отдельно. После этого не имеет ни малейшего значения "отщипываем" мы группы символов от упорядоченного номера или от псевдослучайного хэша. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2014, 02:06 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Я так и не услышал никакого обоснования по поводу функции MD5 применительно к файловой системе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2014, 12:00 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevBasil A. SidorovДвоичное дерево не отменяет необходимость полного чтения каталога для целого ряда сценариев... что значит "сценария" и "необходимость полного чтения каталога" ? понятно, что зайти в такой директорий FAR'ом или эксплорером может быть достаточно долго, когда пойдет создание говно-GUI для ляма файлов. Но к файловой системе это никакого отношения не имеет. Сами же операции с файлами (открыть файл и так далее) от кол-ва файлов в директории сильно зависеть не должны, в отличие от FAT Автор свои требования назвал "добавлять, читать, и удалять". Подозреваю, что NTFS для данных сценариев замечательно миллион файлов переварит. Директории по > 50 тысяч файлов на компьютере Pentium 166 с 16 Mb RAM на NT 2000 жили замечательно вы в своём коде как открываете файл? с проверкой существования или без? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2014, 12:29 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevBasil A. Sidorov...Из неразумных - только один: "Да мы вообще не заморачивались". При ограниченных сроках и бюджете, имплиментация более менее адекватной реализация фичи "хранить в тысячи директориев" может быть более неразумна ))), чем "просто не заморачиваться". И потратить усилия на что нибудь более бизнес ценное. Но я уже говорил, что лично мы, в результате, вообще все положили в БД Oracle и перестали "заморачиваться" с файло-помойкой ))) это ерунда... при любом лимите времени, а особено если нету времени дублировать код то будет чтото типа будет функция сохранения файла по имени используемого в работе с файлом., которая будет вызывать функцию - которая определит путь сохранения... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2014, 12:35 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
alex564657498765453вы в своём коде как открываете файл? с проверкой существования или без?Где-то появилось файловое API не возвращающее ошибок? Или выросло поколение самонадеянных программистов, никогда не совершающих ошибки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2014, 21:18 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
tramadolAkina, это не коммерческий проект а просто задачка в целях обучения. использую обычную Win 7 на NTFS а зачем учиться на идиотских задачах? кому нужны миллионы файлов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2014, 20:46 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
MasterZivкому нужны миллионы файлов?Не сказать, чтобы каждому встречному, но - нужны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2014, 21:41 |
|
||
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#18+
MasterZivкому нужны миллионы файлов? Например, HTTP кэш. В проекте, где я участвую, типичный кэш содержит десятки миллионов файлов. Можно конечно хранить кэш в СУБД, но в готовых СУБД есть не нужные для этой задачи оверхеды, а в самописной - сложность реализации, с учетом всех нюансов работы (защита от падений, работа с дисковым кэшем и пр). Файлы - нормальный компромис. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2014, 05:43 |
|
||
|
|

start [/forum/topic.php?all=1&fid=16&tid=1341166]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
151ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
89ms |
get tp. blocked users: |
1ms |
| others: | 232ms |
| total: | 514ms |

| 0 / 0 |
