Привет. Имеется папка, в которой лежат миллионы файлов. Если важно - это фотки на сайте. Есть мнение, что держать такое количество файлов в одной папке (плоским списком, без вложений) - не труъ. На многих сайтах можно увидеть, что урлы на кртинки имеют вид типа /images/37/12/8472746723.jpg То есть, вместо того чтобы складывать весь миллион картинок в папку /images, в папке создается, например, 1000 других папок, и картинки уже раскладываются по ним, и тогда в каждой отдельновзятой папке будет порядка 1000 картинок. Сценарии работы с картинками в вебе таковы, что самая частая операция - чтение или запись картинки по абсолютному пути, или проверка ее наличия на диске. Реже - удаление. Очень редко - итерирование (обычно это только для вебмастерских нужд, а не для пользовательской функциональности). Итак, вопросы: 1. Действительно ли есть смысл разбивать большую свалку файлов на дерево папок? Если да, то почему (с технической точки зрения)? 2. Если да, то какой разумный лимит сверху на количество папок и количество файлов в одной папке? ФС - Ext4. 3. Сам для себя пока что сделал так: один дополнительный этаж из 4096 папок, и в них уже картинки. Имя файла - md5, имя папки, в которой он лежит - первые три символа его md5. То есть пути выглядят так: /images/959/9594efd8a45a95249c93008526f14137.jpg. Самих корневых папок (с 4096 дочерними в каждой) - 3-4 штуки. Такое норм?
1. А что будет во время выдачи отфильтрованной выборки? какие расходы по времени и по поглащаемой оперативке? Эти миллионы как беруться, разом или через ленивость? 2. Метод который будет обходить рекурсивный? что будет со стэком? 3. А что в замерах время\память?
q2e74, итерирование (перебор, запрос списка) - это все делается раз в год по админско-вебмастерским нуждам. Даже если эта работа будет жрать слишком много ресурсов - это не страшно, поскольку это делается очень редко и обычно одним человеком. Интересует прежде всего прямой доступ по абсолютному пути - сохранение новой картинки или чтение существующий - то есть юзерские операции. Обход, фильтрация - это все юзерам не нужно. Что касается замеров - в вебе обычно так получается, что одни и те же казалось бы одинаковые действия дают очень разный результат при синтетических тестах и под реальной нагрузкой. И это не та проблема, которую хочется решать по мере ее возникновения Еще вопрос вдогонку: возможно различные подходы к организации папок имеют разную надежность в смысле восстановления данных, если вдруг что-то пошло не так, или, скажем, винт начал сыпаться? У меня на серваке зеркалирующий software RAID на два винта. Возможно это важно.
Добрый день. Это не мнение, а суровая реальность. Хотя лично я начал делить файлы на иерархию по другой детской причине: ФТП отказывается адекватно работать. Однако. https://habr.com/ru/post/157613/ Так что на лицо тонкости реализации. Яркий пример того, как одни кривые руки приводят к необходимости создавать новые костыли. Такие дела (с)
Ты знаешь там ещё опции играют роль. И флаги когда mkfs делаешь. И флаги монтирования тоже. Поищи как настроить ext4 под много мелких файлов. --- Сообщение объединено, 3 окт 2019 --- Во: " Создание файловой системы Для маленьких файлов: mkfs -t ext4 -m 0 -O dir_index,filetype /dev/vg_name/vol tune2fs -o journal_data_writeback /dev/vg_name/vol Для больших файлов: mkfs -t ext4 -m 0 -T largefile4 -O extents,filetype,has_journal,sparse_super /dev/vg_name/vol tune2fs -o journal_data_writeback /dev/vg_name/vol "
Имеет смысл. Это положительно сказывается на времени поиска файла в каталоге. Большинство файловых систем хранят каталоги как просто список dirent'ов. Соответственно, для поиска файла надо делать последовательное чтение каталога. Большое количество dirent'ов - дольше чтение - дольше время открытия файла. Практика показала, что хранение в одном каталоге больше 10000 файлов начинает сильно сказываться на производительности. Малоэффективно. Лучше не генерировать md5, а завести какой-то последовательный счётчик (или псевдорандомный, как результат умножения последовательного на простое число (4-5 десятичных знаков)), форматировать его значение в десятичном или шестнадатеричном виде фиксированной длины и бить уже это значение как строку по три символа, начиная с хвоста.
Садко. 1.Тогда пользователю надо будет находить нужную папку, в дереве папок? Или как? Компуктер же одинаково будет искать. Только папок больше будет, дополнительная нагрузка??? 2.Если в консольном режиме, на экст4 вроде не должно сказываться. Когда были Экст2 и 3, тогда писали специальные ФС, под сервера. А на экст4 (если я не ошибаюсь), уже делают файловые хранилища.
Что проще для вас - начать читать книгу с начала, пока вы не найдёте нужную главу, или посмотреть в оглавление, сразу открыть книгу на нужной странице? Для большой книги очевидно лучше способ 2. Для рассказа на пару страниц сгодится и способ 1. А учитывая то, что компьютер чаще всего работает по алгоритму 1, то вывод можно сделать простой: минимизировать единовременно прочитываемый объём данных. Все файловые системы работают примерно по одному и тому же принципу. Отличие только в наличии дополнительных механизмов. Насколько помню, конкретно ext* файловые системы чувствительны к количеству файлов в каталоге, при этом XFS - нет.
В ext4 используется hashed b-tree, время поиска файла выражается O(log n), то есть логарифмическое время. В википедии хорошо сказано: https://ru.wikipedia.org/wiki/Временная_сложность_алгоритма То есть влияет ли число файлов в папке на время доступа к каждому в ext4 - да, влияет. Сильно ли влияет - теоретически не сильно, точно не пропорционально числу файлов. Что такое мнение - тезис, не подкрепленный аргументом. А прежде чем решать проблему, лучше сначала убедиться, что она есть.
f13nd, хорошее замечание. https://en.wikipedia.org/wiki/HTree Есть в том числе и на ext3, и на ext2 (но не включено по умолчанию). Это действительно может ускорить открытие. Однако с просмотром каталога могут возникнуть проблемы. Файловым менеджерам типа mc уже на 10к записей начинает крышу сносить. Поэтому, _DEN_, если хотите универсальное решение, то лучше всё же построить иерархию.
