Я управляю приложением, которое содержит хранилище файлов, в котором все файлы хранятся с именами, равными их суммам md5. Все файлы хранятся в одном каталоге. Сейчас их тысячи, но скоро на сервере должны быть миллионы файлов. Текущий сервер работает под управлением Ubuntu 11.10 в файловой системе ext4.
Кто-то сказал мне, что неразумно помещать много файлов в каталог, так как это значительно увеличит время поиска и надежность (у него была история о максимальных файлах, на которые может указывать один каталог, в результате чего получается большой связанный список). Вместо этого он предложил создать подкаталоги, например, подстроки имени файла. Однако это сделает некоторые вещи в моем приложении намного более громоздкими.
Это все еще верно, или современные файловые системы (например, ext4) имеют более эффективные способы справиться с этим и естественным образом масштабируются? Википедия содержит некоторые сведения о файловых системах, но на самом деле ничего не говорит о максимальном количестве файлов на каталог или времени поиска.
Суть проблемы заключается в том, чтобы найти нужный вам файл в индексном дескрипторе каталога. Некоторые файловые системы делают это лучше, чем другие. Некоторые масштабируются до миллиардов, но если у вас всего ... 20К файлов Добраться до эти файлы заметно быстрее. Кроме того, большое количество файлов создает проблемы для определенных инструментов и в результате может значительно усложнить задачу резервного копирования / восстановления.
Так получилось, что я столкнулся с той же проблемой в нашей собственной разработке (md5sum как имя файла, его масштабирование). Нашим разработчикам я рекомендовал разрезать нить на куски. Они пошли с группами по 4 человека, но в файловой системе, в которой мы работали в то время, даже эти многие из них могут оказаться проблематичными с точки зрения производительности, поэтому они в конечном итоге разбили группу из 3 для первых 6 троек и оставили остальные как имя файла в каталоге терминала.
Группа из 4 человек: 4976/d70b/180c/6142/c617/d0c8/9d0b/bd2b.txt
Группа из 3 человек: 497/6d7/0b1/80c/614/2c6/17d0c89d0bbd2b.txt
Это дает преимущество в том, что размеры каталогов остаются небольшими, а поскольку MD5sum довольно случайна, она создает сбалансированные деревья каталогов. Этот последний каталог вряд ли когда-либо получит больше, чем несколько файлов. И было не так уж сложно работать с нашим кодом. Мы работаем с многомиллионными файловыми проектами, поэтому масштабирование было для нас очень важно.
В ext3 и более поздних файловых систем хешированное B-дерево индексация каталога. Это очень хорошо масштабируется, если вы выполняете только операции добавления, удаления и доступа по имени. Однако я все же рекомендую разбить каталоги на части. В противном случае вы создадите опасную ловушку для инструментов (updatedb, ls, duи т. д.), которые выполняют другие операции с каталогами, которые могут взорваться, если в каталоге слишком много записей.
Современные файловые системы очень хорошо обрабатывают очень большие каталоги, даже с миллионами файлов. Но обычные инструменты - нет. Например, перечисление такого большого каталога с помощью «ls» займет довольно много времени, поскольку обычно выполняется чтение всего каталога и его сортировка (хотя вы можете использовать ls -f, чтобы избежать сортировки). Он не начнет показывать файлы, пока все не будут прочитаны. Разделение имен помогает в некоторых случаях, но не во всех (например, при репликации rsync все равно может потребоваться собрать все дерево имен).
Могу ли я предложить вместо этого использовать базу данных SQL? Это, вероятно, превратит эту воспринимаемую слабость в вашем приложении в сильную.