Хранить изображения (jpg, gif, png) в файловой системе или БД?

Question

Возможные Дубликаты:
Which is more secure: filesystem or database?
User images - database vs. filesystem storage
store image in database or in a system file ?

Я не могу решить, какой из них я должен следовать. Можете ли вы, ребята, высказать некоторые мнения? Должен ли я хранить мои изображения в файловой системе или БД? (Я хотел бы, чтобы другие от кражи моих изображений)

При ответе на этот вопрос, пожалуйста, включает в себя сравнение безопасности, спектакли и т.д.

Спасибо.

---

Точный дубликат:User Images: Database or filesystem storage?
Точный дубликат:Storing images in database: Yea or nay?
Точный дубликат:Should I store my images in the database or folders?
Точный дубликат:Would you store binary data in database or folders?
Точный дубликат:Store pictures as files or or the database for a web app?
Точный дубликат:Storing a small number of images: blob or fs?
Точный дубликат:store image in filesystem or database?

Answer 1

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

Я предлагаю придерживаться проверенной и надежной системы хранения пути к файлу или каталога в БД и хранения файлов на диске. Вот почему:

• Файловую систему проще в обслуживании. Некоторые мысли должны быть включены в структуру и организацию изображений. то есть каталог для каждого клиента и подкаталог для каждого [Атрибут-X] и другой подпапки для каждого [Атрибут-Y]. Сохранение слишком большого количества изображений в одном каталоге приведет к замедлению доступа к файлу (т. Е. К сотням тысяч).
• Если идея хранения в БД является контрмерой против потери файловой системы (то есть диск опускается или каталог удаляется случайно), то я бы встретил предложения о том, что при использовании элемента управления источником нет проблем с получением потерянных/отсутствующих/удаленных файлов.
• Если вам когда-либо понадобится масштабировать и перейти к сценарию распространения контента, вам придется вернуться в файловую систему или выполнить большой экстракт, чтобы выталкивать провайдеров.
• Также говорится: «Храните структурированные данные в базе данных». У Microsoft есть статья о Managing Unstructured Data.
• Если проблема безопасности является проблемой, файловая система имеет целую структуру с ACL. Повторное использование колеса под защитой может оказаться вне сферы действия бизнес-требований.

Большое количество дискуссий на эту тему также находится по адресу:

• Question 3748
• Question 561447

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

Если среда может поддерживать SQL Server 2008, вы можете иметь лучшее из обоих миров с их новым типом данных FileStream в SQL 2008.

• В статье MSDN рекламирует FileStream datatype in SQL 2008 как высокая производительность.
• SQL Skills has a great article with some SQL 2008 Filestream performance measurements.
• Вот статья, касающаяся varbinary vs. FileStream and performance of both datatypes.
• Если вы являетесь подписчиком SQL Mag, вы можете увидеть отличный номер article at SQL Mag on SQL 2008 FileStream.
• Microsoft Research article:To Blob or Not To Blob

Я хотел бы видеть исследования в реальных сценариях с большими базами пользователей, таких как Flickr или Facebook.

Опять же, все это восходит к вашим бизнес-требованиям. Удачи!

Answer 2

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

Answer 3

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

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

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

Answer 4

Возможно, вам придется получить целую кучу «но файловая система - это DB». Это не один из них.

Выбор файловой системы зависит от многих факторов, например, есть ли у сервера права на запись в каталог? (И да, я видел серверы, на которых apache не мог писать в DocumentRoot.)

Если вам нужна 100% кросс-совместимость между платформами, тогда вариант Database - лучший способ пойти. Он также позволит вам хранить метаданные, связанные с изображениями, такие как идентификатор пользователя, дату и даже альтернативные версии одного и того же изображения (например, кэшированные миниатюры).

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

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

Answer 5

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

Для решения AWS к этому, например, вы должны:

• магазин изображения на S3
• Сохранить ключ S3 в базе данных
• Serve yourimages на S3 через CloudFront (Amazon CDN)

Answer 6

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

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

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

Answer 7

Сохраните их в FileSystem, сохраните путь к файлу в БД.

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

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

Answer 8

Если проблема заключается в масштабируемости, вы можете получить огромные потери, перемещая вещи в базу данных. Вы можете объединять веб-серверы через DNS, но добавляя накладные расходы как процесса CGI, так и поиска базы данных для каждого изображения - безумие. Это также делает вашу базу данных намного сложнее в обслуживании и ваши изображения, которые намного сложнее обрабатывать.

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

Answer 9

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

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

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

Answer 10

Это зависит от того, сколько изображений вы собираетесь обрабатывать, и что вы должны с ними делать. У меня есть приложение, которое должно временно хранить от 100 тыс. До нескольких миллионов изображений в день. Я пишу их в смежных блоках 2gb в файловой системе, сохраняя идентификатор изображения, имя файла, начальную позицию и длину в базе данных.

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

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

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

Answer 11

Храните файлы на файловом сервере и храните примитивные данные в базе данных. Хотя файловые серверы (особенно на основе HTTP) хорошо масштабируются, серверам баз данных нет. Не смешивайте их вместе.

Answer 12

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

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

База данных хороша для хранения указателей (путей к файлам) к фактическим данным.