Я только что добавил прогнозирующий поиск (см. пример ниже), функция на мой сайт, который работает на Сервере Ubuntu. Это работает непосредственно от базы данных. Я хочу кэшировать результат для каждого поиска и использования, что, если это существует, еще создайте его.
Была бы какая-либо проблема со мной сохраняющий потенциал cira 10 миллионов результатов в отдельных файлах в одном каталоге? Или действительно ли желательно разделить их вниз на папки?
Пример:
там была бы какая-либо проблема со мной сохраняющий потенциал приблизительно 10 миллионов результатов в отдельных файлах в одном каталоге?
Да. Вероятно, существует больше причин, но они я могу отправить первое, что пришло на ум:
tune2fs
имеет опцию, названную dir_index
, который имеет тенденцию быть включенным по умолчанию (на Ubuntu, который это), который позволяет Вам хранить примерно 100k файлы в каталоге перед наблюдением хита производительности. Это даже не близко к файлам на 10 м, о которых Вы думаете.
ext
файловые системы имеют фиксированное максимальное количество inodes. Каждый файл и каталог используют 1 inode. Используйте df -i
для представления Ваших разделов и inodes свободный. Когда у Вас заканчивается inodes, Вы не можете сделать новые файлы или папки.
команды как rm
и ls
, когда подстановочные знаки использования разворачивают команду и будут заканчиваться со "списком аргументов слишком долго". Необходимо будет использовать find
, чтобы удалить или перечислить файлы. И find
имеет тенденцию быть медленным.
Или действительно ли желательно разделить их вниз на папки?
Да. Совершенно определенно. В основном Вы даже не можете хранить файлы на 10 м в 1 каталоге.
я использовал бы базу данных. Если Вы хотите кэшироваться, это для веб-сайта взглянуло на" solr" ("обеспечение распределенной индексации, репликации и сбалансированных с загрузки запросов").
Законченный с той же проблемой. Выполните мои собственные сравнительные тесты, чтобы узнать, можно ли поместить все в ту же папку по сравнению с наличием нескольких папок. Кажется, что Вы можете и это быть быстрее!
Двоичный поиск может легко обработать миллионы записей, настолько ищущих единственный каталог, не была бы проблема. Это сделает настолько очень быстро.
В основном при использовании системы на 32 бита записи двоичного поиска до 2 ГБ легки и хороши.
DB Berekely, программное обеспечение с открытым исходным кодом, с готовностью позволил бы Вам хранить полный результат при одной записи и встроит поиск.
Это зависит от того, что вы хотите сделать с этими 10 миллионами файлов. Если вам не нужно ничего для выполнения «списка» или «просмотра», подобного действию в каталоге хранения, а только доступ к отдельным файлам по их именам и можете однозначно предсказать их имена, Я не вижу никаких проблем с хранением такого количества файлов в одном каталоге.
С другой стороны, имейте в виду, что большинство пользовательских интерфейсов и оболочек не предназначены для эффективной обработки этой ситуации, поэтому вы знаете, что не следует использовать rm *
, а скорее ls | xargs rm
, чтобы удалить все здесь.
Обратите внимание, что количество inodes в файловой системе в стиле Unix (например, ext4) напрямую не связано с выбором плоской или иерархической структуры каталогов, потому что независимо от того, в какой каталог вы поместите файл, он будет занимать inodes. И на самом деле более глубокая структура каталогов имеет более высокие накладные расходы на потребление inode. (Таким образом, ИМО в принятом ответе ошибочно упоминается предел inode, который не поддерживает этот аргумент.)