Яке найкраще місце для зберігання завантажених зображень, бази даних SQL або дискової файлової системи?

Я пишу заявку, яка дозволяє користувачам завантажувати зображення на сервер. Я очікую приблизно 20 зображень на день у форматі jpeg і, ймовірно, не редагувався / не змінювався розмір. (Це ще одне питання, як змінити розмір зображень на стороні сервера перед зберіганням. Можливо, хтось може, будь ласка, залишити .NET ресурс для цього в коментарі чи так). Мені зараз цікаво, що найкраще місце для зберігання завантажених зображень.

• Збережіть зображення як файл у файловій системі та створіть запис у таблиці з точним шляхом до цього зображення.

• Або збережіть саме зображення в таблиці, використовуючи тип даних "зображення" або "двійкові дані" сервера баз даних.

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

Я, як правило, зберігаю файли у файловій системі, оскільки для цього є, хоча є і винятки. Для файлів файлова система є найбільш гнучким та ефективним рішенням (як правило).

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

Щодо безпеки - я зазвичай зберігаю файли в каталозі, що знаходиться поза коренем документа (недоступний через http-запит) і подаю їх через скрипт, який спочатку перевіряє правильність авторизації.

Єдиною перевагою для параметра B є наявність усіх даних в одній системі, але це хибна вигода! Ви можете стверджувати, що ваш код також є формою даних, а тому також може зберігатися в базі даних - як би ви цього хотіли?

Якщо у вас є якийсь унікальний випадок:

• Логіка бізнесу належить до коду.
• Структуровані дані належать до бази даних (реляційні або нереляційні).
• Масові дані належать у сховищі (файлова система чи інше).

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

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

Але зберігання файлів у базі даних - погана ідея.

Flickr використовувати файлову -Вони обговорити причини тут

Я знаю, що це стара публікація. Але багато відвідувачів цієї сторінки не мають нічого спільного з питанням. Особливо для новачків.

Як завантажити та зберігати зображення чи файли на нашому веб-сайті:

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

1. Зображення надходять від адміністратора динамічного блогу. Зазвичай ці зображення були оптимізовані перед завантаженням.

2. Зображення від користувачів, якщо користувачі можуть завантажувати зображення, такі як аватар. Або користувачі можуть створювати вміст блогу та розміщувати деякі зображення з текстового редактора. Такого роду зображення важко передбачити розмір. Користувачі можуть завантажувати великі зображення лише для невеликого вмісту, змінюючи розмір перегляду, але не змінюючи розмір зображення.

Ігноруючи пункт № 1 вище, швидке рішення для предмета № 2 можна тимчасово вирішити за допомогою наступних порад, якщо у нас немає функціоналу оптимізації зображень на нашому веб-сайті:

1. Не дозволяйте користувачам безпосередньо завантажувати текстовий редактор, перенаправляючи їх у галерею зображень. На цій сторінці користувачі повинні завантажити файл заздалегідь, перш ніж вони зможуть вбудувати вміст. Цей метод називається менеджером файлів.

2. Використовуйте функцію обрізання зображень, щоб користувачі завантажували зображення. Це обмежить розмір зображення, навіть якщо користувачі завантажують дуже великий файл. Остаточне зображення є результатом обрізаного зображення. Ми можемо визначити розмір на стороні сервера і приймати лише наприклад 500 Кбіт або менше.

Тепер це лише тимчасово. Для остаточного вирішення питання повторюється:

• Як обробити велике сховище зображень?
• Змініть розмір або змініть розширення.
• Як великий або середній веб-сайт або електронна комерція обробляють файлосховище для своїх зображень?

Що ми можемо зробити тоді:

1. Міграція з розміщення акцій VPS. Недостатньо? Потім більш високий, перейшовши на Виділений.

2. Створіть власний сервер для зберігання файлів. Гугл, щоб це зробити. Це не так складно, як ви думаєте. Деякі люди роблять це для свого веб-сайту.

3. Найпростіший спосіб - це послуга зберігання файлів CDN.

Гаразд, 1 і 2 - це трохи дорого. Але немає 3 я думаю, що це найкраще рішення.

Деякі служби CDN дозволяють зберігати стільки веб-файлів, скільки вам потрібно.

Питання: "як завантажити файл в CDN з нашого веб-сайту?"

Не хвилюйтесь, як тільки ви зареєструєтесь, як правило, безкоштовно, ви отримаєте вказівки щодо завантаження файлу та отримання їх посилання з / на ваш веб-сайт. Ви отримаєте API та багато іншого. Це легко.

Деякі постачальники надають нам безкоштовний сервіс протягом 14 днів з обмеженою пам’яттю та пропускною здатністю. Але це буде добре для початкової точки. Єдина проблема полягає в тому, що "люди ніколи не намагаються".

Сподіваюся, це допоможе новачкам.

У нас клієнти кілька разів наполягали на варіанті B (зберігання бази даних) на декількох різних компонентах, і ми в кінцевому підсумку завжди поверталися до варіанту A (зберігання файлової системи).

Такі великі BLOB, як і раніше, недостатньо добре обробляються навіть SQL Server 2005, і це остання версія, яку ми спробували.

Зокрема, ми побачили серйозні набряки, і я думаю, можливо, проблеми з блокуванням.

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

Але я завжди намагаюся використовувати підкаталоги, щоб трохи розбити речі. Час створення часто для цього добре працює:

Зображення / 2008/12/17 / .jpg

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

РЕДАКТУВАННЯ: Лише коротка примітка для 2017 року, в останніх версіях SQL Server з’являються нові варіанти обробки безлічі BLOB, які повинні уникнути недоліків, про які я обговорював.

EDIT: Коротка примітка до 2020 року, зберігання Blob в AWS / Azure / тощо також є варіантом вже багато років. Це чудово підходить для багатьох веб-проектів, оскільки це дешево і часто може спростити певні проблеми навколо розгортання, масштабування на декількох серверах, налагодження інших середовищ при необхідності тощо.

Нещодавно я створив додаток PHP / MySQL, який зберігає файли PDF / Word у таблиці MySQL (до цих пір становить 40 Мб на файл).

Плюси:

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

Мінуси:

• mysqldump тепер займає довгий час, оскільки в одній із таблиць є 500 МБ файлових даних.
• Загалом не дуже ефективна пам'ять / процесор порівняно з файловою системою

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

Я використовую завантажені зображення на своєму веб-сайті, і я б точно сказав варіант а).

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

Це також допомагає зняти ім’я файлу користувача будь-яких дивних символів, щоб уникнути майбутніх ускладнень.

Визначально змініть розмір зображення та перевірте його формат, якщо зможете. Були випадки, коли шкідливі файли завантажуються та обслуговуються невідомими хостами - наприклад, вразливість GIFAR дозволяє вам приховати шкідливий аплет java у файлі GIF, який потім зможе прочитати файли cookie у поточному контексті та надіслати їх на ще один сайт для міжсайтової атаки сценаріїв. Зміна розмірів зображень зазвичай перешкоджає цьому, оскільки він змінює вбудований код. Хоча ця атака була виправлена ​​патчами JVM, наївне обслуговування бінарних файлів без їх очищення відкриває вам цілий ряд уразливостей.

Пам’ятайте, що більшість сканерів на віруси можуть працювати лише проти файлової системи - якщо ви зберігаєте свої бінарні файли в БД, ви не зможете дуже легко запустити сканер проти них.

У SQL Server 2008 існує такий собі гібридний підхід, який називається тип даних файлового потоку який говорили в радіо RunAs № 74 , який схожий на найкращий з обох світів. Більшість людей не мають домовленостей 2008 року, але якщо це зробити, цей варіант виглядає досить здорово

В основному це я і роблю.

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

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

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

Більшість реалізацій - це варіант А.

З опцією B ви відкриваєте цілу велику банку whoop4ss, коли ви перетворюєте ці біти з бази даних на щось, що може відображатися в браузері ... Крім того, якщо db знижений, зображення недоступні.

Я не думаю, що простір занадто багато питання ... Диски Terabyte зараз - це кілька сотень доларів.

Ми реалізуємо варіант A, оскільки у нас немає часу та ресурсів, щоб зробити варіант B.

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

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

Якщо настане час, коли для вас це не буде масштабуватись, ви можете дослідити механізми кешування.

Абсолютно позитивно варіант А. Інші згадували, що бази даних, як правило, не справляються з BLOB, незалежно від того, вони призначені для цього чи ні. Файлові системи, з іншого боку, живуть для цього матеріалу. У вас є можливість використовувати RAID-смугасті зображення, поширюючи зображення на декілька дисків, навіть поширюючи їх на географічно розрізнені сервери.

Ще одна перевага - резервне копіювання / реплікація вашої бази даних буде жахливим.

Варіант А.

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

З міркувань безпеки також найкраща практика уникати проблем, спричинених Sniffing вмісту IE, який може дозволити зловмисникам завантажувати JavaScript у файли зображень, які можуть виконуватись у контексті вашого веб-сайту. Тому ви можете хоч якось перетворити зображення (обрізати / змінити розмір) перед їх збереженням, щоб запобігти подібному нападу. Ця відповідь має деякі інші ідеї.

Ну, у мене є подібний проект, коли користувачі завантажують файли на сервер. З моєї точки зору, варіант a) є найкращим рішенням, оскільки він є більш гнучким. Що потрібно зробити, це зберігання зображень у захищеній папці, класифікованій за підкаталогами. Основний каталог повинен бути налаштований адміністратором, оскільки вміст не повинен запускати скрипти (дуже важливо) та (читати, записувати), захищені, щоб вони не були доступними для запиту http.

Я сподіваюся, що це вам допоможе.

Якщо це невеликі файли, які не потрібно буде редагувати, то варіант B - це не поганий варіант. Я вважаю за краще це писати логіку для зберігання файлів і вирішення шалених проблем структури каталогів. Мати багато файлів в одному каталозі - погано. емкай?

Якщо файли великі або потребують постійного редагування, особливо в таких програмах, як офіс, то варіант А - найкращий варіант.

У більшості випадків це питання переваги, але якщо ви перейдете на варіант А, просто переконайтеся, що в каталогах немає занадто багато файлів у них. Якщо ви вибрали варіант B, то перетворіть таблицю з даними BLOBed у власну базу даних та / або групу файлів. Це допоможе в обслуговуванні, особливо резервного копіювання / відновлення. Ваших звичайних даних, ймовірно, досить мало, тоді як ваші дані зображення з часом будуть величезними .

Це залежить від ваших вимог, особливо обсягу, користувачів та частоти пошуку. Але для малого та середнього офісу найкращим варіантом є використання такої програми, як Apple Photos або Adobe Lighroom. Вони спеціалізовані для зберігання, каталогізації, індексації та організації такого роду ресурсів. Але для великих організацій, що мають високі вимоги до зберігання та великої кількості користувачів, рекомендується створити платформу для управління вмістом за допомогою управління цифровими активами, як Nuxeo або Alfresco; обидві пропозиції дуже хороших ресурсів дійсно управляють дуже великими обсягами даних спрощеними методами їх отримання. І, що дуже важливо: для обох платформ існує безкоштовний (відкритий) варіант.