|
|
|
алгоритм для хранилища файлов
|
|||
|---|---|---|---|
|
#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 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=38797552&tid=1341166]: |
0ms |
get settings: |
7ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
165ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
| others: | 199ms |
| total: | 444ms |

| 0 / 0 |
