Where should I store photos? File system or the database?

Asked
Viewd5951

10

Possible Duplicate:
storing uploaded photos and documents - filesystem vs database blob

I am starting to develop a web app, the primary purpose of which is to display photos. The users will be able to upload photos as well.

The first question that came up was where to store the photos: on the file system or the database.

I will be using a Windows box to host the site. The database is MySQL and the backend code is in C# utilizing ASP.NET MVC.

  • @Locksfree Could be thousands of images. Could be more, depending on whether people actually use the site.

    AngryHacker09 октября 2009, 23:56
  • let the holy war begin….

    Muad'Dib09 октября 2009, 23:19

10 ответов

29

Файловая система, конечно, если вы не хотите написать статью на thedailywtf. Самый простой способ - упорядочить фотографии по свойству, которое вы можете получить из самого файла, например по его хэшу SHA-1. Затем просто сохраните хеш в базе данных, привязанный к первичному ключу фотографии и другим атрибутам (кто ее загрузил, дату загрузки и т. Д.).

Также неплохо разделить фотографии в файловой системе, чтобы у вас не осталось миллионов файлов в одном каталоге. У вас будет что-то вроде этого:

 storage/00/e4/f56c0de1c61fdb926e79e8a0a65bd12930c9.jpg
storage/25/9a/ec1c55bfb660548a6770238668c4b117d92f.jpg
storage/5d/d5/4b01d98f17a9ad9dd1526b49ba39b5aa37a1.jpg
storage/63/49/6f740b6c284ce6685dc17d473a7360ace249.jpg
storage/b1/75/066d178188dde110149a8422ab651b0ee615.jpg
storage/b1/20/a2b7d02b7b0c43530677ab06235382a37e20.jpg
storage/da/39/a3ee5e6b4b0d3255bfef95601890afd80709.jpg
 

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

  • The SHA-1 hash idea for creating directories and filenames is brilliant. Answer accepted.

    AngryHacker10 октября 2009, 05:28
3

Я бы использовал что-то вроде Amazon S3.

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

4

Если вы используете SQL Server 2008, существует тип данных Filestream, который решает большинство упомянутых проблем, связанных с увеличением размера БД. Он обрабатывает все раздражающие детали синхронизации между файловой системой и таблицей.

Найдите здесь сообщение в блоге по этой теме: Хранить любые данные в SQL Server 2008 (Katmai)

  • Кстати, этот пост был чисто информационным… :)

    Siewers09 октября 2009, 23:51
2

Когда у вас есть база данных BLOB-объектов, жизнь становится проще. Вам следует забыть о кошмаре управления файловой системой.

Идентификатор
ВАРБИНАР

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

  • Yea, that should be the primary objective of any software architecture…Make “life so easy” for the developer. Forget about the operations people that have to deal with a multi-terabyte database or the user that have to wait for images to get out of a server that was made for storing DATA not images.

    Jim Blizard09 октября 2009, 23:27
  • A file system IS a database–one that happens to be designed from the outset to store files/documents as opposed to the small, repeated fields relational stores were originally intended for. You CAN make a workable solutions with an RDBMS but you’ll find a greater variety of natural and intuitive tools for dealing with files when they’re in a file system.

    steamer2513 октября 2009, 21:26
  • Sometimes a mantra is, in fact, axiomatic. Sometimes people repeatedly “spew” the truth and sometimes the brave contrarian souls who rail against these truism are flat out wrong.

    Jim Dennis09 октября 2009, 23:38
  • Вы, ребята, указали неверную причину для отказа от хранения двоичных данных. Это та самая старая мантра, которую извергали годами.

    ChaosPandion09 октября 2009, 23:33
  • Until you need to back up your database, and, surprise, it’s got thousands of gigs of binary garbage mixed in with the metadata.

    John Millikin09 октября 2009, 23:23
  • Скажите, пожалуйста, как использовать файловую систему более эффективно или масштабируемо?

    ChaosPandion09 октября 2009, 23:35
  • … если вас больше интересует простота разработки или академические соображения, чем практические вопросы масштабируемости и некоторые ИТ-аспекты ремонтопригодности.

    Jim Dennis09 октября 2009, 23:34
3

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

4

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

Кроме того, у Amazon S3 или других облачных провайдеров есть свои преимущества. Например, S3 + Amazon CloudFront обеспечит хорошую производительность. CloudFront кэширует ваши файлы на серверах по всему миру, поэтому они будут очень легко / быстро доступны из любого места. НО, если мы говорим о фотографиях и сайт становится популярным, ваши счета могут быть довольно высокими.

Для S3 Amazon взимает плату за хранилище и за передачу в облако или из облака. Для CloudFront за передачу .

2

У нас было аналогичное решение для проекта, над которым я работаю. Неоспоримая особенность заклинивания информации (изображений и других объектов типа BLOBy) в БД заключается в том, что вероятность того, что кто-то удалит / изменит что-то (намеренно или непреднамеренно), меньше. Но это не тот выбор, который мы сделали. Вместо этого у нас есть информация о пути, хранящаяся в БД, и мы используем ее для ссылки на данные через UNC-путь. Пути к данным хранятся в двух частях - части, которая ссылается на расположение данных относительно того, на каком компьютере они находятся, и части, которая указывает, на каком компьютере находится эта группа данных. Когда нам нужно переместить данные, мы можем обновить соответствующую информацию о пути.

Конечно, быстро получить данные, не вынимая из БД. В конечном итоге это стало решающим фактором.

3

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

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

  • также можно сделать в файловой системе. Не нужно помещать изображения в БД.

    Jim Blizard09 октября 2009, 23:24
  • «Тоже можно сделать»? Это довольно кратко. Вы хотите сказать, что автоматическая репликация возможна? Я так полагаю; кто-то должен был написать систему репликации файлов. Но если у вас уже настроена репликация базы данных, может быть проще просто засунуть туда фотографии, чем настраивать и отлаживать две отдельные системы репликации. Вы не согласны?

    steveha09 октября 2009, 23:27
3

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

  • Я бы сказал, что это чертовски веская причина.

    ChaosPandion09 октября 2009, 23:44
  • The only reason to even consider storing them in the DB, IMO.

    peterchen09 октября 2009, 23:41
3

Обычно люди хранят двоичные данные, такие как изображения, в файловой системе, а не в базе данных. Они ссылаются на путь файловой системы из базы данных. Получение BLOB (больших двоичных объектов) из базы данных происходит медленнее, чем предоставление веб-серверу возможности обслуживать статические файлы из файловой системы.