Изображения в базе данных против файловой системы

Question

У нас есть проект, в рамках которого мы будем создавать целую бэкэнд-систему CMS, которая будет питать всю нашу экстрасеть и интрасеть одним пакетом. Вопрос, на который я пытался найти ответ, заключается в том, что лучше: хранить изображения в базе данных (SQL Server 2005), чтобы у нас была целостность, иметь единый план репликации и т. Д. ИЛИ хранить в файловой системе?

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

Наше беспокойство заключается в следующем:

• Целостность данных
• Репликация данных
• Несколько разрешений
• Скорость базы данных в сравнении с файловой системой
• Загрузка базы данных в сравнении с файловой системой
• Управление данными и резервное копирование

Есть ли у кого-нибудь похожая ситуация или есть какие-либо предложения о том, что было бы рекомендовано? Заранее спасибо за помощь!

Answer 1

Была опубликована прекрасная исследовательская статья Microsoft Research под названием Для Blob или не для Blob , где они рассмотрели все виды переменных и воздействий.

Их нахождение в конце:

• размером до 256 КБ, BLOB-объекты хранятся в базе данных более эффективно, чем в файловой системе
• для 1 МБ и более, файловая система более эффективна
• между ними бросок

С момента публикации этого документа SQL Server 2008 также добавил атрибут FILESTREAM, который делает хранение данных в файловой системе, но под контролем транзакций, реальностью. Настоятельно рекомендуется проверить это!

Answer 2

Этот вопрос возникает часто - см. этот ТАК. Результат поиска.

Нет единственно правильного ответа - это зависит от обстоятельств.

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

Answer 3

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

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

В предложениях по сохранению пути в БД отсутствует реальная проблема, которая повторяется на нескольких машинах.

Answer 4

Ваши проблемы разбиты на два лагеря. Следующие проблемы касаются хранения документов в базе данных:

• Целостность данных
• Репликация данных
• Несколько разрешений
• Управление данными и резервное копирование

Эти проблемы (вероятно) в пользу хранения документов в файловой системе:

• Скорость базы данных в сравнении с файловой системой
• Загрузка базы данных в сравнении с файловой системой

Итак, решите, что важнее всего, и выберите соответственно.

Answer 5

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

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

Несколько моментов, почему вы должны рассмотреть файловую систему

1. Браузер выполняет всю работу, и вы извлекаете выгоду из кэширования прокси изображений и т. д.
2. В ответ на вышесказанное вы легко можете использовать сети доставки контента (CDN)
3. Репликация данных изображения легко с помощью таких инструментов, как rsync и т. Д.
4. Время обработки (т. Е. ЦП) значительно оптимизировано

Answer 6

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

Встроенное / BLOB-хранилище

Upside : упрощает архитектуру и реализацию, упрощает резервное копирование и восстановление или миграцию системы; просто сделайте дамп, сделайте резервную копию, экспортируйте (какой бы ни был термин для вашего вида БД) и переместите его в новую базу данных. Управление версиями / согласованность обрабатываются БД, поэтому допускает восстановление на определенный момент времени. Безопасность и контроль доступа также более понятны, поскольку доступ к BLOB-изображению является неотъемлемым атрибутом доступа к общему ряду. Перемещение изображения за пределы БД и предоставление возможности серверу HTTP извлекать его, хотя и лучше для параллелизма и масштабируемости, могут иметь проблемы с гарантией того, что люди не смогут взломать URL-адреса и запросить изображения, которыми они не владеют. Если вы размещаете их вне БД, убедитесь, что любая из ваших политик безопасности охватывает контроль доступа к изображениям между пользователями. Либо аутентификация вашего HTTP-сервера должна интегрироваться с общей аутентификацией системы, либо ваша программа HTTP-сервера, которая обслуживает изображения, использует какой-то механизм сеанса, чтобы гарантировать, что HTTP-запрос действителен. Это очень большая проблема в мультитенантных базах данных. Меньше проблем в одноцелевых однопользовательских системах с простой аутентификацией.

Недостатки : Для действительно ДЕЙСТВИТЕЛЬНО больших баз данных резервное копирование и восстановление становятся разочаровывающими, или даже проблемными и дорогостоящими, поскольку в противном случае у вас может быть небольшой базовый набор данных, у вас может быть много ГБ или ТБ образа данные. Рассматривать все это как единую согласованную базу данных хорошо с точки зрения целостности, но плохо для резервного копирования, если вы не используете СУБД с корпоративным качеством, настраиваемым резервным копированием и восстановлением хранилища данных (например, Oracle RMAN и скользящие резервные копии).

Всегда учитывайте время восстановления в любой системе. Если ваши требования к хранилищу составляют <несколько гигабайт, скажем даже 50-100 ГБ, и у вас запланировано достаточно места для резервного копирования, встроенное хранилище будет чище. Кроме того, разделение проблем и предоставление файловой системе своей работы становится ключевым преимуществом. Нет ничего хуже, чем пытаться восстановить, восстановить и открыть огромную базу данных ради небольшой ошибки данных. Время восстановления было бы моей самой большой проблемой. </p>

Answer 7

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

Вы другие пункты, хотя:

• Целостность - БД, поэтому базы данных существуют по сравнению с плоскими файловыми системами.

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

• Из образа БД можно выполнить несколько разрешений, однако это увеличивает затраты на обработку. Кроме того, чем выше разрешение, тем больше размер, тем дольше сеть ожидает. Множество разрешений уступает место скорости.

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

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

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

Answer 8

Я не буду хранить изображения в базе данных по одной причине (мой ответ приходит с сервера sql):

Я бы не хотел, чтобы кэш данных SQL Server заполнялся простыми изображениями для веб-сайта. Я хочу, чтобы в кеше данных были данные. Также, если у вас многоуровневая архитектура, гораздо проще передать URL-адрес изображения, чем двоичный объект двоичных данных. Где вы сталкиваетесь с проблемами, хотя, если вы хотите, чтобы определенные люди видели изображения (безопасность).

Answer 9

Я бы;

1) Назначьте уникальный идентификатор (GUID) каждому изображению 2) Отметьте / назовите изображение с этим GUID 3) Хранить GUID в ОС (Файловая система) 4) Сохраните указатель полного имени файла (FQN) в базе данных.

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

Answer 10

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

Недостатки файловой системы

- Не реплицируется автоматически

-Можно усложнить репликацию, имея разные физические местоположения для каждого экземпляра

- медленно с очень большим количеством файлов

Вверх к файловой системе

-Если вы храните несколько очень больших файлов, он будет работать немного лучше.