Какова наилучшая структура каталогов для обработки большого количества загруженных изображений? - PullRequest
2 голосов
/ 24 мая 2011

Я создаю веб-сайт, который требует загрузки фотографий профиля для каждого пользователя, а также версий с измененным размером. Я буду использовать mysql для хранения идентификаторов и другой информации для изображений. Я никогда не хочу иметь дело с перестановкой статических файлов, поэтому давайте просто предположим, что этот сайт получает тысячи пользователей. Мне интересно, какова будет лучшая структура каталогов для хранения изображений?

Ранее я видел несколько упомянутых способов:

1) md5 (image_id), тогда, если хеш равен 49f68a5c8493ec2c0bf489821c21fc3b, структура будет / 49 / f6 / 8a / 5c / 84/93 / ec / 2c / 0b / f4 / 89/82 / 1c / 21 / fc / 3b.jpg (или ..... 3b / filename.jpg). Таким образом, кажется, что он мог бы справиться со многими, но похоже, что он может создать несколько слишком много каталогов. МОЖЕТ ли вариация на этот метод?

2) / год / месяц / день / (возможно час) /id.jpg

Так что же делать?

Ответы [ 4 ]

3 голосов
/ 24 мая 2011

Развертывание подкаталогов по уникальному хешу, как это, является хорошим решением, но число подкаталогов в вашем примере way слишком много. Каждый двухсимвольный подкаталог может поддерживать 256 записей, поэтому, если у вас будет 5000 пользователей, вы получите только около 20 файлов на каждый подкаталог при переходе на один уровень глубины, что вполне разумно. Два уровня глубины легко справятся с миллионами пользователей.

Кроме того, я бы не вырезал имя файла до тех символов, которые остались в хэше. Используйте полный хэш для имени файла, независимо от того, сколько уровней вы пройдете. С файлами будет намного проще управлять, если вам нужно (например) переместить их в новый магазин. Т.е., не делай этого:

49/f68a5c8493ec2c0bf489821c21fc3b.jpg

Сделайте это:

49/49f68a5c8493ec2c0bf489821c21fc3b.jpg
0 голосов
/ 24 мая 2011

Если я сохраняю изображения с именем файла в качестве просто идентификатора, я склонен использовать следующую структуру:

/0/1.jpg
/500/501.jpg
/1000/1001.jpg
/1500/1501.jpg

Идея состоит в том, чтобы создавать папки не более чем из 500 изображений с нумерацией базы.папка в качестве отправной точки.Это не требует каких-либо специальных полей БД или хэширования, и вы можете выбрать более или менее 500.

0 голосов
/ 24 мая 2011

изображений / первые два символа md5 (user_id) / user_id / *. Jpg

Таким образом, у вас нет каталогов с тысячами других файлов / каталогов, и вы избежите слишком большого количества вложенных деревьев

, например

images/a9/1000/foo.jpg
images/a9/1000/bar.jpg
images/a9/107/baz.jpg
images/1f/24/goo.jpg
0 голосов
/ 24 мая 2011

Я обычно храню ключ в БД рядом с записью изображения в таком формате:

userid/md5(image_id)_time.ext

Это хорошо, потому что не дает людям возможности «украсть» всю вашу коллекцию, не выполняя кучу работы. Кроме того, это помогает определить конфликт, если вы обновляете исходную картинку и хотите сохранить «старую» в течение некоторого времени (что может быть полезно в определенных обстоятельствах). Кроме того, вы можете установить его никогда не истекает, так как вы никогда не будете обновлять его снова. Вам, возможно, придется периодически заходить и сбрасывать «старые» файлы, но это другое дело.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...