Для начала я немного занимаюсь разработкой, и меня попросили поработать над структурой каталогов для всего обслуживаемого контента и над масштабируемостью хост-серверов (балансировка нагрузки и т. Д.).
На данный момент существует около 500 тыс. Файлов, но ожидается, что он будет продолжать расширяться, каждый файл должен быть уникальным, но некоторые из них являются просто более ранними версиями того же файла. Все файлы также будут храниться в базе данных sql с дополнительной информацией о файлах. Каждый файл содержит тег с его идентификатором, например file.coder.project Каждый файл содержит тег с идентификатором ревизии, например: 1, 2 или 14 и т. Д.
Пока файлы были в этой структуре (строка также хранится в db):
File\coder\project\file.coder.project.rev-md5.ext
(кодер файла и проект не являются буквально сегментами, это просто пример)
Проблема в том, что некоторые подпапки будут заполнены больше, чем другие, и меня беспокоят проблемы репликации на нескольких серверах. Я обсуждал переключение его на сокращение значения его md5sum или sha до уровня 3/4 и просто обновление базы данных (не проблема, очень просто)
Планируемым процессом синхронизации будут сценарии lsyncd и rsync, так как база данных все равно будет реплицирована.
Ищете другие рекомендации или идеи, или md5 / sha, вероятно, лучше для уменьшения плотности папок? Будет ли любой метод влиять на время загрузки / чтения файла при доступе, даже если полный путь уже известен?
Все системы будут Ubuntu с ext3 или ext4
У метода хранения файлов на основе хешей есть много преимуществ, но вы должны обязательно разрезать хеш на достаточно частей, чтобы каталоги не были слишком большими. Насколько я помню, для EXT3 прямое открытие определенного подкаталога в каталоге, заполненном 15 000 подкаталогов, занимает больше времени, чем для каталога, содержащего всего 2 000 подкаталогов. Не уверен насчет ext4.
Поскольку первые несколько цифр хэшей значительно уникальны, разделение хэша на 5 частей, где первые 4 части - это 3 символа хеша, а последняя часть больше, чем это, сохранит этот первый уровень каталога под 'очень большим размеры. Прямой доступ к файлам в такой структуре должен быть довольно быстрым с обеими версиями EXT.