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

Ответ 1

Я вообще храню файлы в файловой системе, так как это то, что там есть, хотя есть исключения. Для файлов файловая система является наиболее гибким и эффективным решением (обычно).

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

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

Ответ 2

Единственное преимущество для варианта B - наличие всех данных в одной системе, но это ложная выгода! Вы можете утверждать, что ваш код также является формой данных и, следовательно, также может храниться в базе данных - как вам это понравится?

Если у вас нет уникального случая:

• Бизнес-логика принадлежит коду.
• Структурированные данные относятся к базе данных (реляционные или нереляционные).
• Массовые данные относятся к хранилищу (файловая система или другое).

Нет необходимости использовать файловую систему для хранения файлов. Вместо этого вы можете использовать облачное хранилище (например, Amazon S3) или Infrastructure-as-a-service поверх него (например, Uploadcare):

https://uploadcare.com/upload-api-cloud-storage-and-cdn/

Но хранение файлов в базе данных - плохая идея.

Ответ 3

Flickr использует файловую систему - они обсуждают причины здесь

Ответ 4

У нас были клиенты, которые несколько раз настаивали на опции B (хранилище баз данных) на нескольких разных серверах, и мы всегда возвращались к опции A (хранилище файловой системы).

Большие BLOB файлы, подобные этому, не были обработаны достаточно хорошо даже SQL Server 2005, который является последним, с которым мы его попробовали.

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

Еще одно замечание: если вы используете хранилище на базе NTFS (сервер Windows и т.д.), вы можете подумать о том, как найти тысячи и тысячи файлов в одном каталоге. Я не уверен, почему, но иногда файловая система не справляется с этой ситуацией. Если кто-нибудь знает об этом, я бы с удовольствием это услышал.

Но я всегда стараюсь использовать подкаталоги, чтобы немного разобраться. Дата создания часто хорошо подходит для этого:

Изображения/2008/12/17/.jpg

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

РЕДАКТИРОВАТЬ: Простое примечание к 2017 году, в более поздних версиях SQL Server, есть новые опции для обработки большого количества BLOB, которые должны избегать недостатков, которые я обсуждал.

Ответ 5

Недавно я создал приложение PHP/MySQL, в котором хранятся файлы PDF/Word в таблице MySQL (до 40 МБ на файл).

Плюсы:

• Загруженные файлы реплицируются на сервер резервного копирования вместе со всем остальным, не требуется отдельная стратегия резервного копирования (спокойствие).
• Настройка веб-сервера немного проще, потому что мне не нужно иметь папку uploads/folder и сообщать обо всех моих приложениях, где они есть.
• Я могу использовать транзакции для редактирования, чтобы улучшить целостность данных. Мне не нужно беспокоиться о потерянных и потерянных файлах.

Минусы:

• mysqldump теперь занимает время looooong, потому что в одной из таблиц содержится 500 Мбайт данных.
• В целом не очень эффективная память/процессор по сравнению с файловой системой.

Я бы назвал свою реализацию успешной, она заботится о требованиях к резервному копированию и упрощает компоновку проекта. Производительность отлично подходит для 20-30 человек, которые используют приложение.

Ответ 6

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

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

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

Ответ 7

Определенно измените размер изображения и проверьте его формат, если сможете. Были случаи, когда вредоносные файлы загружались и обслуживались невольными хостами - например, GIFAR уязвимость позволяла скрывать вредоносные java апплет в файле GIF, который затем сможет читать файлы cookie в текущем контексте и отправлять их на другой сайт для атаки на межсайтовый скриптинг. Изменение размера изображений обычно предотвращает это, так как оно искажает встроенный код. Хотя эта атака была исправлена ​​с помощью патчей JVM, наивно обслуживая двоичные файлы без их очистки, вы получаете доступ к целому ряду уязвимостей.

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

Ответ 8

Большинство вариантов реализации - это вариант A.

С помощью опции B вы открываете целую большую банку whoop4ss, когда вы собираете эти биты из базы данных во что-то, что может отображаться в браузере... Кроме того, если db не работает, изображения недоступны.

Я не думаю, что пространство - это слишком большая проблема... Терративные диски - это пара сотен долларов.

Мы реализуем с опцией А, потому что у нас нет времени или ресурсов для выполнения варианта В.

Ответ 9

В SQL Server 2008 существует гибридный подход, называемый filestream datatype, о котором говорилось в RunAs Radio # 74, который похож на лучшее из обоих миров. У большинства людей нет 2008 года, но если вы это сделаете, этот вариант выглядит довольно круто.

Ответ 10

Мы используем A. Я бы поместил его на общий диск (если только вы не планируете запускать более одного сервера).

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

Ответ 11

Абсолютно, положительно вариант А. Другие отметили, что базы данных, как правило, плохо справляются с BLOB, независимо от того, предназначены ли они для этого или нет. Файловые системы, с другой стороны, живут для этого. У вас есть возможность использовать разделение RAID, распространение изображений на нескольких дисках, даже распространение их по географически разрозненным серверам.

Еще одно преимущество - резервное копирование/репликация базы данных будет чудовищным.

Ответ 12

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

Ответ 13

Вариант A.

После загрузки изображения вы можете проверить формат и изменить его размер перед сохранением. Существует ряд примеров кода .Net для изменения размеров изображений на http://www.codeproject.com. Например: http://www.codeproject.com/KB/cs/Photo_Resize.aspx

Ответ 14

Из соображений безопасности также рекомендуется избегать проблем, вызванных IE Content Sniffing, который позволяет злоумышленникам загружать JavaScript внутри файлов изображений, который может быть выполнен в контексте вашего сайта. Таким образом, вы можете каким-либо образом преобразовать изображения (обрезать/изменять их размер) перед их сохранением, чтобы предотвратить такую ​​атаку. Этот ответ содержит некоторые другие идеи.

Ответ 15

Ну, у меня есть аналогичный проект, где пользователи загружают файлы на сервер. По моему мнению, вариант a) является лучшим решением, благодаря которому он более гибкий. Что вам нужно сделать, так это хранить изображения в защищенной папке, классифицированной подкаталогами. Главный каталог должен быть настроен администратором, так как контент не должен запускать сценарии (очень важные) и (читать, писать), чтобы они не были доступны в HTTP-запросе.

Надеюсь, это поможет вам.

Ответ 16

Это в основном я.

• Сохраняйте загруженное изображение во временном каталоге или в памяти.
• Обработать это изображение перед его постоянным хранением. 2.1. Коррекция цвета 2.2. Компресс 2,3. Создайте несколько копий на основе размеров изображения 2,4. Переименуйте с помощью .xl,.lg,.md,.sm и т.д. Суффиксы
• Упакуйте все обработанные файлы изображений (из одного файла) внутри папки с именем папки как id, которая будет храниться в базе данных для любой строки/документа вместе с image file name (или может быть случайным именем в качестве имени изображения).
• Создайте папку yyyy/mm/d path, если она не существует. Например, 2016/08/21. Помните этот путь и сохраните в базе данных для того же документа и строки.
• Переместите изображение id в папку path. (Папка пути может быть расположена в папке /var/web -content.)
• Сбросить буфер памяти или удалить временный файл.

Когда вам нужно получить доступ к любому изображению, указанному в документе, у вас есть путь и идентификатор папки, кроме изображений. Например /var/web-content/{{path}}/{{id}}/image-file-name.sm.jpg

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

Ответ 17

Я знаю, что это старый пост. Но многие посетители этой страницы не имеют ничего общего с вопросом. Особенно для новичков.

Как загружать и хранить изображения или файлы на нашем веб-сайте.

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

• Изображения поступают от администратора для динамического блога. Как правило, эти изображения были оптимизированы до загрузки, конечно.

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

Не обращая внимания на пункт № 1 выше, быстрое решение для элемента № 2 может быть временно разрешено следующими советами, если у нас нет функциональности оптимизатора изображений на нашем веб-сайте:

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

• Используйте функцию изображения обрезки, чтобы пользователи могли загружать изображения. Это ограничит размер изображения, даже пользователи загружают очень большой файл. Конечное изображение является результатом обрезанного изображения. Мы можем определить размер на стороне сервера и принять только, например, 500Kb или ниже.

Теперь это временно. Для окончательного решения вопрос повторяется:

• Как работать с большим хранилищем изображений?
• Изменить размер или изменить расширение.
• Как большой или средний веб-сайт или электронная коммерция обрабатывают хранилище файлов для своих изображений?

Что мы можем сделать тогда:

• Перенос с share VPS. Недостаточно? Затем более высокий, перейдя на "Выделенный".

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

• Простым способом является использование службы хранения файлов CDN.

Хорошо, 1 и 2 немного дороже. Но нет, я думаю, это лучшее решение.

Некоторые службы CDN позволяют хранить ваш веб файл столько, сколько захотите. Вопрос, как загрузить файл на CDN с нашего сайта?

Не волнуйтесь, как только вы зарегистрируетесь, как правило, бесплатно, вы получите руководство, как загрузить файл и получить свою ссылку с вашего сайта. Вы получите API и многое другое. Это легко.

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

Надеюсь, что это поможет новичкам.

Ответ 18

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

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

В большинстве случаев это вопрос предпочтения, но если вы переходите на вариант A, просто сделайте так, чтобы в каталогах не было слишком много файлов. Если вы выберете вариант B, сделайте таблицу с данными BLOBed в своей собственной базе данных и/или группе файлов. Это поможет в обслуживании, особенно в резервных копиях/восстановлении. Ваши обычные данные, вероятно, довольно малы, в то время как ваши данные изображения будут огромными с течением времени.

Ответ 19

Это зависит от ваших требований, особого объема, пользователей и частоты поиска. Но для малого или среднего офиса лучшим вариантом является использование приложения, такого как Apple Photos или Adobe Lighroom. Они специализированы для хранения, каталогизации, индексирования и организации такого рода ресурсов. Но для крупных организаций с высокими требованиями к хранению и большим количеством пользователей рекомендуется создать экземпляр Платформы управления контентом с помощью Digital Asset Management, например Nuxeo или Alfresco; оба предлагают очень хорошие ресурсы, управляют очень большими объемами данных с помощью упрощенных методов для их извлечения. И очень важно: для обеих платформ есть бесплатный (открытый исходный код).