Каков наилучший способ хранения изображений пользователей с помощью PHP и MySQL?

Мне было интересно, что является лучшим способом для хранения изображений пользователей, таких как аватар и т. Д., Используя PHP и MySQL? С чего начать? И есть ли хорошая статья об этом?

Solutions Collecting From Web of "Каков наилучший способ хранения изображений пользователей с помощью PHP и MySQL?"

«Лучшее» зависит от вашей цели.

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

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

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

Отредактировано для добавления

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

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

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

  • Proxying и If-Modified. Поскольку веб-запросы: Apache может обрабатывать If-Modified-Since HTTP-заголовки для вас и возвращать ответ 304, и это самая лучшая производительность, которую вы можете получить. Прокси-серверы обратной прокси и прокси, размещенные в интернет-провайдерах, попытаются воспользоваться этим.

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

  • Простота схемы. Если вы разрешаете загрузку файлов, вам также необходимо будет добавить метаданные о типе MIME, размере файла, высоте и ширине. Если сам файл не соответствует типу MIME в таблице, вам нужно закодировать выбор из таблицы и передать его в /usr/bin/file . Это может быть намного проще для shell_exec( "/usr/bin/file /path/to/mumble" ) .

  • Thumb-nailing: загрузка пользовательских изображений, вероятно, должна быть закреплена пальцами, и это часто намного проще сделать асинхронным с фактическим веб-запросом. Это действительно не забавно, когда какой-то хороший пользователь пытается загрузить файл фотошопа 150 МБ, предоставленный им своим профессиональным фотографом-приятелем, а ваш экземпляр apache переходит в OOM при попытке загрузить библиотеку ImageMagick в пространство памяти веб-рабочего. Это действительно не масштабируется для работников Apache. Создайте рабочее задание / cron за пределами Apache для обработки этой работы.

  • Повреждение таблицы: Ничего себе, вы действительно не хотите калечить всех аватаров пользователей, если ваш индексный файл MySQL загружается, и вам нужно выполнить автономный ремонт таблицы в этой таблице.

  • Резервное копирование и восстановление: вы не хотите блокировать большую таблицу с помощью mysqldump. Использование rsync сэкономит вам много времени и даст вам большую гибкость. Таблицы обычно восстанавливают целую таблицу, а таблицы времени обычно не резервируются небольшими частями.

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

 <img src="<path>/users_images/<user_id>/thumb.gif" /> 

Если бы я был вами, я бы просто сохранил изображение где-то в вашем каталоге сайтов, а затем сохранил ссылку на изображение в MySQL, если вы действительно хотите сохранить его в базе данных, я бы прочитал его в строке, а затем base64_encode () а затем сохранить его в базе данных.

Будут всевозможные небольшие проблемы, с которыми вам придется столкнуться, сохраняя их в базе данных, вам придется создавать сценарии, чтобы эхо их эхо-эффект, а загрузка сервера и базы данных будет значительно увеличена. Если бы я был вами, я бы просто сохранил ссылку.

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

Предполагая, что ваши пользовательские аватары хранятся в: htdocs / images / avatars / И пользователь apikot имеет аватар «avatar.jpg», который хранит его пользователя в базе данных, тогда вы можете скомпилировать следующий URL-адрес при создании тега изображения: «/ htdocs / изображения / аватары / avatar.jpg».

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

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

Создайте поле типа BLOB и вставьте результат file_get_contents ($ ImageFile)