Несколько маленьких каталогов или один огромный каталог с именами файлов php mysql

Question

Несколько маленьких каталогов или один огромный каталог с именами файлов php mysql

0

Это полностью теоретический вопрос.

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

Вопрос

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

Теперь я подумал о двух подходах к достижению этого.

Ожидается, что файлы, загруженные на мой сервер, будут ~ 100 миллионов

Подход 1

Эти файлы /pictures/hd/ & /pictures/low/ содержат все файлы, загруженные пользователем.

$newfilename  =  $user_id.time().$filename; //$filename = actual filename of uploaded file
$src = '/pictures/hd/'.$newfilename; //for hd pics

Вставка этого в mysql путем

insert into pics('user_id','src')VALUES('$user_id','$newfilename')

Подход 2

Эти два /pictures/hd/ & /pictures/low/ directories будут содержать подкаталоги файлов, загруженных пользователем.

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

if (!is_dir('/pictures/hd/'.$user_id.'/')) {
   mkdir('/pictures/hd/'.$user_id.'/');         
 }
$newfilename  =  $user_id.'/'.$user_id.time().$filename; //$filename = actual filename of uploaded file
$src = '/pictures/hd/'.$newfilename; //for hd pics

Вставка этого в mysql путем

insert into pics('user_id','src')VALUES('$user_id','$newfilename')

поиск

При извлечении изображения я могу использовать столбец src в моей таблице pics чтобы получить имя файла и изучить файл hd, используя файлы '/pictures/low/'.$src_of_picstable hd/'/pictures/hd/'.$src_of_picstable и lowq, используя '/pictures/low/'.$src_of_picstable

Slim Shady 06 март 2015, в 14:04

Источник

Теги:

php

2 ответа

Ещё вопросы

symcbean · Answer 1 · 2015-03-10T21-37-00.000Z

Правильный ответ на вопрос - проверить его.

Это быстрее будет зависеть от количества файлов и файловой системы underlyng; ext3.4 вполне с удовольствием справится с очень большим количеством файлов в одном каталоге (dentries atr управляется индексом HTree). Некоторые файловые системы просто используют простые списки. У других есть разные способы оптимизации доступа к файлам.

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

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

insanebits · Answer 2 · 2015-03-06T10-04-00.000Z

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

Вторая причина для нескольких каталогов заключается в том, что вы можете создавать небольшие резервные копии части своей галереи. И если у вас действительно большая галерея (скажем, несколько терабайт), одного жесткого диска может быть недостаточно, чтобы содержать их все. С несколькими каталогами вы можете монтировать каждую директорию на отдельный жесткий диск и таким образом обрабатывать почти бесконечную галерею размеров.

Мой любимый подход - структура каталога YYYY/MM/type-of-image. Таким образом, вы можете заметить, когда вы представили какую-то ошибку, глядя месяц за месяцем. Также вы можете создавать ежемесячные резервные копии без дублирования избыточных файлов. Также ежеквартальные снимки всей галереи на всякий случай.

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

Что касается вас, я бы предложил подход YYYY/MM/type-of-image/user_id, где вы могли бы легко найти все загруженные пользователем файлы в одном месте.

Йо, а что если я приготовлю это как type-of-image/YYYY/MM/user_id ?