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

Question

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

Answer 5

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

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

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

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

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

Answer 6

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

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

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

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

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

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

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

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

Answer 7

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

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

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

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

Answer 8

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

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

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

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

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

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

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

Answer 9

Спасибо за быстрый ввод, у нас есть только около 5-10 ГБ изображений на данный момент, и во многом это потому, что у нас несколько разрешений одного и того же изображения.

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

Еще раз спасибо за все вклады!

Answer 10

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

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

Answer 11

Я мог бы;

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

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