производительность — несколько небольших каталогов или один огромный каталог с именами файлов php mysql
Это полностью теоретический вопрос.
у меня есть хранение фотографий сайт, на котором фотографии загружаются пользователями, зарегистрированными на сайте.
Вопрос
- Какой из подходов быстрее?
- И лучше в долгосрочной перспективе, когда мне нужно использовать много компьютеров и
жесткие диски? - Есть ли другой подход, который еще лучше?
Теперь я подумал о два подхода выполнения этого материала.
Ожидается, что файлы, загруженные на мой сервер, будут огромными ~> 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/ каталоги будут содержать подкаталоги файлов, загруженных пользователем.
Это создаст много подкаталогов с именем как 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/hd/'.$src_of_picstable а также lowq файлы, использующие '/pictures/low/'.$src_of_picstable
Решение
Я бы не предложил подход единого каталога по двум причинам. Во-первых, если вы планируете иметь много изображений, ваш каталог станет действительно большим. И поиск одного изображения вручную займет намного больше времени. Это понадобится, когда вы отлаживаете что-то или тестируете новые функции.
Вторая причина для нескольких каталогов заключается в том, что вы можете создавать меньшие резервные копии части вашей галереи. И если у вас действительно большая галерея (скажем, несколько терабайт), одного жесткого диска может быть недостаточно, чтобы вместить их все. С несколькими каталогами вы можете монтировать каждый каталог на отдельном жестком диске и таким образом обрабатывать почти бесконечный размер галереи.
Мой любимый подход — структура каталогов YYYY / MM / type-of-image. Таким образом, вы можете определить, когда вы представили какую-то ошибку, просматривая месяц за месяцем. Также вы можете делать ежемесячные резервные копии без дублирования избыточных файлов. Также делаю ежеквартальные снимки всей галереи на всякий случай.
Что касается типа изображения, есть несколько типов изображений, которые мне могут понадобиться, такие как исходное изображение, миниатюра, миниатюра, обычное изображение и т. Д. Таким образом, я могу просто поменять тип изображения и получить другой размер изображения.
Что касается вас, я бы предложил подход YYYY / MM / type-image / user_id, где вы можете легко найти все загруженные пользователем файлы в одном месте.
Другие решения
Правильный способ ответить на вопрос — проверить его.
Что будет быстрее, будет зависеть от количества файлов и лежащей в основе файловой системы; ext3,4 с большим удовольствием справится с очень большим количеством файлов в одном каталоге (dentries atr управляется в индексе HTree). Некоторые файловые системы просто используют простые списки. Другие имеют разные способы оптимизации доступа к файлам.
Ваша первая проблема масштабирования будет состоять в том, как управлять набором файлов на нескольких дисках. Простое расширение одной файловой системы на множество дисков — плохая идея. Если у вас много каталогов, то у вас может быть много точек монтирования. Но это не очень хорошо работает, когда вы получаете террабайты данных.
Однако, что содержание индексированный независимость от хранилища файлов означает, что не имеет значения, что вы сейчас выбираете для хранилища файлов, потому что вы можете легко изменить сопоставление файлов с расположением позже, не перемещая существующий набор данных.