Делать или не делать: хранить изображения в базе данных

Ответ 1

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

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

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

Кроме этого, не делайте этого.

Ответ 2

Плюсы размещения изображений в базе данных.

• Сделки. Когда вы сохраняете blob, вы можете зафиксировать его точно так же, как и любой другой фрагмент данных БД. Это означает, что вы можете зафиксировать blob вместе с любым из связанных метаданных и быть уверенным, что они синхронизированы. Если у вас закончилось дисковое пространство? Никакой фиксации. Файл не был загружен полностью? Никакой фиксации. Глупая ошибка приложения? Никакой фиксации. Если сохранение изображений и связанных с ними метаданных, согласованных друг с другом, важно для вашего приложения, то транзакции, которые может предоставить БД, могут быть благом.

• Одна система для управления. Нужно ли создавать резервные копии метаданных и капли? Резервное копирование базы данных. Нужно их повторить? Репликация базы данных. Нужно оправиться от частичного сбоя системы? Перезагрузите БД и сверните журналы вперед. Все преимущества, которые DB приносят в данные в целом (сопоставление томов, управление хранением, резервное копирование, репликация, восстановление и т.д.), Относятся к вашим блокам. Более согласованность, удобство управления.

• Безопасность. Базы данных имеют очень мелкозернистые функции безопасности, которые можно использовать. Схемы, роли пользователей, даже такие вещи, как "только чтение", чтобы обеспечить безопасный доступ к подмножеству данных. Все эти функции работают с таблицами, содержащими капли.

• Централизованное управление. Связанные С# 2, но в основном у администраторов баз данных (как будто они не имеют достаточной мощности), можно управлять одной базой данных. Современные базы данных (особенно более крупные) очень хорошо работают с крупными установками на нескольких машинах. Единый источник управления упрощает процедуры, упрощает передачу знаний.

• Большинство современных баз данных обрабатывают капли просто отлично. Благодаря первоклассной поддержке blobs в вашем уровне данных вы можете легко сбрасывать капли из БД клиенту. Хотя есть операции, которые вы можете сделать, это будет "сосать" весь blob все сразу, если вам не нужен этот объект, тогда не используйте его. Изучите интерфейс SQL для своей БД и используйте его возможности. Нет причин относиться к ним как к "большим струнам", которые обрабатываются монолитно и превращают ваши капли в большие, запоминающиеся воспоминания, кэш-атаки, разбивающие бомбы.

• Так же, как вы можете настроить выделенные файловые серверы для изображений, вы можете настроить выделенные серверы blob в своей базе данных. Дайте им выделенные тома диска, выделенные схемы, выделенные кеши и т.д. Все ваши данные в БД не совпадают или ведут себя одинаково, нет причин настраивать их все равно. Хорошие базы данных имеют прекрасный уровень контроля.

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

Многие наивные реализации просто захватывают blob и сбрасывают их оптом по сокету. Но у HTTP есть несколько важных функций, хорошо подходящих для потоковой передачи изображений и т.д. В частности, кеширование заголовков, ETags и пакетная передача позволяют клиентам запрашивать "фрагменты" blob.

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

Например, кто-то запрашивает файл spacehuttle.jpg, созданный 1 января 2009 года. Это заканчивается кэшированием в файловой системе в дате запроса, скажем, 1 февраля 2009 года. Позже изображение очищается из кеша (Политика FIFO или что-то еще), а кто-то, позже, 1 марта 2009 года снова запрашивает его. Ну, теперь у него есть "дата создания" 1 марта 2009 года, хотя все время его создания было действительно 1 января. Итак, вы можете видеть, особенно если ваш кэш много оборачивается, клиенты, которые могут использовать if- Модифицированные заголовки могут получать больше данных, чем они на самом деле нуждаются, так как сервер ДУМАЕТ, что ресурс изменился, когда на самом деле это не так.

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

Но дело в том, что это что-то, чтобы продумать всю проблему, чтобы быть "хорошим гражданином в Интернете", и сэкономить вам и вашим клиентам потенциальную пропускную способность и т.д.

Я только что прошел через все это для Java-проекта, обслуживающего видео из БД, и все это работает.

Ответ 3

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

Например, в моей старой работе у нас было приложение, в котором пользователи прикрепляли изображения к нескольким различным точкам отчета, который они пишут, и эти изображения должны были быть распечатаны, когда это было сделано. Эти отчеты были перенесены через репликацию SQL Server, и она представила бы БОЛЬШУЮ головную боль, чтобы попытаться управлять этими изображениями и файловыми путями через несколько систем и серверов с любой степенью надежности. Хранение их в базе данных дало нам все это "бесплатно", и инструменту отчетности не приходилось обращаться к файловой системе, чтобы получить изображение.

Ответ 4

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

Microsoft SQL 2008 дает вам лучшее из обоих миров с функцией FileStream - возможно, стоит проверить. http://technet.microsoft.com/en-us/library/bb933993.aspx

Ответ 5

Одним из преимуществ хранения изображений в базе данных является то, что он переносится по всем системам и не зависит от расположения файловой системы.

Ответ 6

Самое простое/наиболее эффективное/наиболее масштабируемое решение - хранить ваши изображения в файловой системе. Если безопасность вызывает беспокойство, поместите их в место, недоступное веб-серверу, и напишите script, который обрабатывает безопасность и обслуживает файлы.

Предполагая, что ваш сервер/сервер приложений и сервер БД - это разные машины, вы сделаете несколько обращений, поставив изображения в БД: (1) Задержка в сети между двумя машинами, (2) накладные расходы БД, (3) потребление дополнительное DB-соединение для каждого обслуживаемого изображения. Меня больше беспокоит последний момент: если на вашем сайте будет много изображений, ваши веб-серверы будут потреблять много соединений с БД и могут исчерпать пулы подключений.

Ответ 7

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

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

Ответ 8

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

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

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

Ответ 9

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

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

Ответ 10

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

Просто не делай этого!

Ответ 11

Это действительно похоже на проблему KISS (пусть это простая глупость). Файловые системы созданы для упрощения хранения файлов изображений, но это нелегко сделать в базе данных и легко испортить данные. Зачем использовать производительность и все трудности в sql и рендеринге, когда вы можете просто беспокоиться о безопасности файлов? Вы также можете обрабатывать смешанные системы с NFS или CIFS. Файловые системы - это зрелые технологии. Гораздо проще, надежнее.

Ответ 12

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

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

Ответ 13

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

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

Ответ 14

• для данных
• файловая система для файлов