Оптимальная структура веб-папок для ~ 250 000 изображений

Question

У меня будет около 200 000 изображений в качестве части моего сайта. Каждое изображение будет сохранено 3 раза: полный размер, уменьшенное изображение, уменьшенное изображение. Размер полноразмерных изображений составляет от 50 до 500 КБ.

Обычные технологии: Linux, Apache, MySQL, PHP на VPS.

Каков оптимальный способ их хранения для быстрого поиска и отображения через браузер ??

Должен ли я хранить все в одной папке? Нужно ли хранить полноразмерные изображения в одной папке, пиктограммы в другой и т. Д.? Должен ли я хранить изображения в папках по 1000 и сохранять индекс, в котором находится изображение?

Спасибо за любой совет. Альберт.

Answer 1

Я бы использовал разделенную структуру каталогов, три или четыре уровня в глубину, идея равномерно распределить все файлы по многим каталогам, чтобы обеспечить главным образом простое обслуживание и быстрый доступ.

Как это сделать? Существуют различные альтернативы:

• Взятие первых символов имен изображений
• Взятие первых символов хэша имени
• Последние цифры секунд с 1970 года, когда была добавлена ​​картинка
• Получение последних символов идентификатора изображения в базе данных (если таковой существует)

Предположим, у нас есть IMG8993_full.jpg, IMG8993_thumb.jpg, IMG8993_smallthumb.jpg

Тогда мы могли бы иметь, например:

/images/I/M/G/8/IMG8993:
IMG8993_full.jpg
IMG8993_thumb.jpg
IMG8993_smallthumb.jpg

Answer 2

Если ваши пользователи не перейдут в открытую папку со списком каталогов ваших изображений, я не думаю, что структура папок значительно увеличит или уменьшит скорость поиска для ваших пользователей. Как уже говорили другие люди, убедитесь, что индексация включена. Однако на вашем месте я бы хотел написать (или скопировать и вставить) сервис, который динамически обслуживает изображения, а не хранить их непосредственно в структуре вашего веб-файла. Рассмотрите возможность использования LibGD в PHP - он должен быть предварительно установлен на большинстве серверов LAMP.

Недостатки:

• Подача изображений через службу будет немного медленнее, чем предоставление прямых ссылок
• Если вы используете внутреннее хранилище изображений, такое как база данных, оно может привести к сбою и сделать все ваши изображения временно недоступными

Преимущества:

• Вы сэкономите место на диске, динамически изменив размеры изображений на миниатюры, и упростив обслуживание
• Как правило, скорость процессора дешевле, чем объем памяти

Используя переписывание URL, вы можете даже превратить ужасные URL, такие как

/imageServer.php?userID=12345imageId=67890&size=full

во что-то более гладкое и прозрачное для ваших пользователей:

/jeremyZX/images/myPhoto.jpg
/jeremyZX/images/tn/myPhoto.jpg

Это придаст вид всей структуре каталогов изображений, тогда как они действительно хранятся в любом формате бэкэнда, который вам нужен.

Answer 3

С такими номерами вы можете или не можете столкнуться с пределом inode, установленным на вашем сервере. Это может быть проблематично в зависимости от того, кто контролирует этот ящик.

В общем, я бы придумал какую-то схему, чтобы разделить их на более управляемые размеры. Даже запуск ls в каталоге такого размера потребует целых возрастов для сортировки и отображения всего этого.

Answer 4

Что бы вы ни делали, убедитесь, что в файловой системе включена индексация каталогов (вы должны выбрать файловую систему, которая поддерживает ее - но все они делают)

На практике, скажем, на ext3, это не проблема, так как она включена по умолчанию в более новых системах. Вы можете узнать с помощью tune2fs (читайте человека)

Answer 5

Зависит от того, как вы их индексируете, и как их извлекать.

Нет ничего особенного против того, чтобы хранить их все в одной папке, но управлять им становится сложно. Если вы храните их по имени файла, а имена файлов распределяются достаточно нормально, вы можете захотеть, чтобы подпапки разделялись по первой букве имени и т. Д. Если вы индексируете по дате добавления, вы можете разделить их по .

Насколько я знаю, не существует более "быстрого" или "более медленного" способа хранения изображений для поиска в браузере.