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

Question

Я пишу приложение, которое позволяет пользователям загружать изображения на сервер. Я ожидаю, что около 20 изображений в день все jpeg и, вероятно, не отредактированы/изменены. (Это еще один вопрос, как изменить размер изображений на стороне сервера перед сохранением. Возможно, кто-то может отказаться от ресурса .NET для этого в комментарии или так далее). Интересно, какое лучшее место для хранения загруженных изображений.

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

• Или сохраните изображение в таблице, используя тип данных «изображение» или «двоичные данные» на сервере базы данных.

Я вижу преимущества и недостатки обоих. Мне нравится a), потому что я могу легко переместить файлы и просто изменить запись в таблице. С другой стороны, мне не нравится хранить бизнес-данные на веб-сервере, и я действительно не хочу подключать веб-сервер к любому другому источнику данных, который содержит бизнес-данные (по соображениям безопасности). Мне нравится b), потому что вся информация находится в одном месте и легко доступен по запросу. С другой стороны, база данных скоро станет очень большой. Аутсорсинг этих данных может быть более сложным.

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

Answer 7

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

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

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

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

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

Images/2008/12/17/.jpg

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

EDIT: Простое примечание к 2017 году, в более поздних версиях SQL Server, есть новые опции для обработки большого количества BLOB, которые должны избегать недостатков, которые я обсуждал.

Answer 8

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

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

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

Answer 9

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

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

Answer 10

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

Плюсы:

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

Минусы:

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

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

Answer 11

Вариант A.

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

Answer 12

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

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

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

Answer 13

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

Answer 14

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

Answer 15

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

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

Answer 16

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

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

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

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

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

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

Answer 17

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

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

---

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

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

Answer 18

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

Answer 19

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

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

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

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

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

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

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

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

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

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

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

1. Перенести от доли хостинг VPS. Недостаточно? Затем более высокий, перейдя на «Выделенный».

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

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

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

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

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

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

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