Как лучше всего хранить загруженные изображения, базу данных SQL или файловую систему диска?
var euroTour = ["France", "the Netherlands", "the UK", "Spain", "Portugal"];
var findCountry = euroTour
.map(country => country.toUpperCase())
.includes('FRANCE');
console.log(findCountry);
// A More General Solution
function includesStrCaseInsensitive(arr, str){
return arr
.map(i => i.toUpperCase())
.includes(str.toUpperCase());
}
console.log(includesStrCaseInsensitive(euroTour, 'FRANCE'));
console.log(includesStrCaseInsensitive(euroTour, 'FrANCE'));13 ответов
Я обычно храню файлы в файловой системе, так как это - то, что там для, хотя существуют исключения. Для файлов файловая система является самым гибким и производительным решением (обычно).
Существует несколько проблем с тем, чтобы хранить файлы на базе данных - файлы обычно намного больше, чем Ваша средняя строка - наборы результатов, содержащие много больших файлов, используют большую память. Кроме того, при использовании механизма устройства хранения данных, который использует блокировки таблицы для записей (ISAM, например), таблица файлов могла бы часто блокироваться в зависимости от размера / уровень файлов, которые Вы храните там.
Относительно безопасности - я обычно храню файлы в каталоге, который является за пределами корня документа (не доступный через запрос HTTP), и служите им через сценарий, который проверяет на соответствующие полномочия сначала.
Если они - маленькие файлы, которые не должны будут быть отредактированы затем, опция B не является плохой опцией. Я предпочитаю, чтобы это записи логики хранило файлы и занималось сумасшедшими проблемами структуры каталогов. Наличие большого количества файлов в одном каталоге плохо. emkay?
Если файлы являются большими или требуют постоянного редактирования, особенно из программ как офис, то опция A является Вашим лучшим выбором.
Для большинства случаев это - вопрос предпочтения, но если Вы идете опция A, просто сделайте ре, каталоги не имеют слишком многих файлов в них. При выборе опции B то заставьте таблицу с данными BLOBed быть в своей собственной базе данных и/или группе файлов. Это поможет с обслуживанием, особенно резервные/восстановления. Ваши регулярные данные являются, вероятно, довольно маленькими, в то время как Ваши данные изображения будут огромны со временем.
Опция A.
После того как изображение загружается, можно проверить формат и изменить размер его перед сохранением. Там много примеров кода .NET для изменения размеров изображений на http://www.codeproject.com. Например: http://www.codeproject.com/KB/cs/Photo_Resize.aspx
Абсолютно, положительно опция A. Другие упомянули, что базы данных обычно не имеют дело хорошо с БЛОБАМИ, разработаны ли они, чтобы сделать так или нет. Файловые системы, с другой стороны, живут для этого материала. У Вас есть опция использования чередования RAID, распространяя изображения через несколько дисков, даже распространяя их через географически разрозненные серверы.
Другим преимуществом является Ваша база данных, backups/replication, было бы чудовищно.
Мы используем A. Я поместил бы его на общий диск (если Вы не планируете выполнение больше чем одного сервера).
Если время настает, когда это не масштабируется для Вас затем, можно исследовать механизмы кэширования.
Для автоматического изменения размеров попробуйте imagemagick... это используется для многих главных систем управления содержания/фотографии с открытым исходным кодом..., и я полагаю, что существуют некоторые расширения .NET для него.
Определенно измените размер изображения и проверьте, что это - формат, если Вы можете. Были случаи злонамеренных загружаемых файлов и служили невольными хостами - например, уязвимость GIFAR позволила Вам скрывать злонамеренный апплет Java в файле GIF, который затем сможет считать cookie в текущем контексте и отправить их в другой сайт для атаки с использованием кросс-сайтовых сценариев. Изменение размеров изображений обычно предотвращает это как он munges встроенный код. В то время как это нападение было зафиксировано патчами JVM, наивно подавание двоичных файлов, не вычищая их открывает Вас до целого диапазона уязвимостей.
Помните, большинство вирусных сканеров может только работать против файловой системы - при хранении двоичных файлов в DB Вы не сможете выполнить сканер против них очень легко.
Существует вид гибридного подхода в SQL Server 2008, названный filestream типом данных, о котором говорили по Радио № 74 RunAs, которое является видом подобных лучший из обоих миров. У большинства людей нет 2008 otion, но если Вы делаете, эта опция выглядит довольно прохладной
Я использую загруженные изображения на своем веб-сайте, и я определенно сказал бы что опция a).
Еще одна вещь, которую я настоятельно рекомендовал бы, сразу изменяет имя файла от того, что пользователь назвал фотографией к чему-то более управляемому. Например, что-то с датой и временем для однозначного определения каждого изображения.
Это также помогает лишить имя файла пользователя любых странных символов для предотвращения будущих сложностей.
Мы сделали, чтобы клиенты настояли на опции B (устройство хранения данных базы данных) несколько раз на нескольких различных бэкендах, и мы всегда заканчивали тем, что возвращались к опции A (устройство хранения данных файловой системы) в конечном счете.
Большие БЛОБЫ как этот просто не были обработаны достаточно хорошо даже SQL Server 2005, который является последним, мы примерили его.
А именно, мы видели серьезное чрезмерное увеличение размера, и я думаю, возможно, блокируя проблемы.
Еще одно примечание: при использовании основанного на NTFS устройства хранения данных (Windows Server, и т.д.) Вы могли бы рассмотреть нахождение пути вокруг помещения тысяч и тысяч файлов в одном каталоге. Я не уверен, почему, но иногда файловая система не справляется хорошо с той ситуацией. Если кто-либо знает больше об этом, я хотел бы услышать его.
Но я всегда пытаюсь использовать подкаталоги для разбивания вещей немного. Дата создания часто работает хорошо на это:
Images/2008/12/17/.jpg
... Это обеспечивает достойный уровень разделения и также помогает немного во время отладки. Проводник и клиенты FTP одинаково могут дросселировать немного, когда существуют действительно огромные каталоги.
Править: Просто быстрое примечание на 2017, в более поздних версиях SQL Server, существует новые опции для обработки большого количества БЛОБОВ, которые, как предполагается, избегают недостатков, которые я обсудил.
Flickr использует файловую систему - они обсуждают причины здесь
Большинство реализаций является опцией A.
С опцией B Вы открываете целую большую банку whoop4ss, когда Вы Маршалл те биты от базы данных во что-то, что может быть отображено на браузере... Кроме того, если дб снижается, изображения не доступны.
Я не думаю, что пространство является слишком большим количеством проблемы... Диски терабайта являются парой сотни маркеров теперь.
Мы реализуем с опцией A, потому что у нас нет времени или ресурсов, чтобы сделать опцию B.
Я недавно создал приложение PHP/MySQL, которое хранит файлы PDFs/Word в таблице MySQL (целых 40 МБ за файл до сих пор).
Профессионалы:
- Загруженные файлы копируются в сервер резервного копирования наряду со всем остальным, никакая отдельная стратегия резервного копирования не необходима (душевное спокойствие).
- Установка веб-сервера немного более проста, потому что я не должен иметь загрузок / папка и сказать все мои приложения, где это.
- Я добираюсь для использования транзакций для редактирований для улучшения целостности данных - я не должен волноваться об осиротевших и недостающих файлах
Недостатки:
- mysqldump теперь занимает looooong время, потому что существует 500 МБ данных файла в одной из таблиц.
- В целом не очень память/CPU, эффективная по сравнению с файловой системой
Я назвал бы свою реализацию успехом, она заботится о резервных требованиях и упрощает расположение проекта. Производительность хорошо для 20-30 человек, которые используют приложение.