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

Question

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

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

Наши опасения со следующим:

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

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

Answer 1

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

Их вывод в конце:

• Размер до 256 кб, в базе данных хранятся капли более эффективно, чем в файловой системе
• Для 1 МБ и большее, файловая система более эффективна
• между ними это броска

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

Answer 5

Что ж, если ваши две лучшие потребности являются целостность и репликацию, то ответ определенно DB.

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

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

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

• Многочисленные разрешения могут быть выполнены с изображения DB, однако это добавляет затраты на обработку. Кроме того, чем выше разрешение, тем больше размер, тем дольше сеть ожидает. Несколько резолюций торгуют пространством для скорости.

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

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

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

Answer 6

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

Встроенное / блобиточное хранилище

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

Недостаток: Для действительно больших баз данных резервное копирование и восстановление разочаровывают или даже проблематичны и дорого, потому что там, где у вас может быть небольшой набор данных основной данных, у вас может быть много данных GB или туберкулеза изображений. Обработка все это как одна последовательная база данных является хорошей с точки зрения целостности, но плохо для резервных копий, если вы не используете DBMS с качеством корпоративного качества, накопленным хранилищем данных и восстановлением (пример - Oracle RMAN и Rolling Backups).

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

Answer 7

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

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

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

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

Answer 8

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

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

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

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

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

Перевернусь к файловой системе

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

Answer 9

Я бы;

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

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

Answer 10

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

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