Дизайнерское решение для хранения и извлечения изображений

Question

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

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

b.) Хорошо ли иметь все изображения в каталоге и иметь над ним виртуальную файловую систему, и приложение получит доступ к изображениям из каталога

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

Редактировать 1: Каждое изображение заменяется новой записью каждые 12 часов, поэтому, насколько я могу подумать, иметь их в базе данных не очень хорошая идея, но как лучше будет использовать хранилище данных и индексировать эти изображения?

Редактировать 2: Да, мы планируем запустить приложение в кластере. И если мы попытаемся использовать хранилище данных (если это хороший вариант), то совместимо ли оно с C # & ASP.NET?

ps: я использую SQL Server для хранения этих изображений.

Answer 1

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

• Если вам нужна необработанная скорость , то плоские файлы - явный победитель.Независимо от того, используете ли вы Apache или IIS, они оба оптимизированы для быстрой обработки статического содержимого на основе файлов.Все высокопроизводительные сайты знают об этом и будут хранить большую часть своего контента с учетом динамической обработки, но затем будут «публиковать» отдельные части своего динамического контента;в статических версиях;к их веб-ферме на периодической или управляемой событиями основе.Хотя для этого требуется небольшая оркестровка, это можно сделать дешево и реально снизить нагрузку на сервер базы данных, внутреннюю сеть и т. Д. В качестве простого примера можно выполнить публикацию в папке с динамическим анализом корня этой структуры.когда вы будете готовы публиковать обновления, напишите новую папку, а затем измените корневой путь.Нет простоя, дешево и просто.В связи с этим для извлечения всей этой информации из внутреннего хранилища потребуется загрузить эти данные в память.В конечном итоге это приведет к увеличению времени сбора мусора и, следовательно, будет означать, что ваше приложение работает медленнее, даже если вы используете многопроцессорное / базовое озеленение.

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

• Учитывая безопасность ... В зависимости от того, что представляют эти изображения,плоские файлы неизбежно приводят к опасениям по поводу атак канонизации, перечисления грубой силы структур папок, доступных для просмотра, воспроизведения файлов cookie, URL-адресов, состояния просмотра и т. д. Если вы используете собственную модель безопасности на основе ролей или утверждений, вы можете столкнуться с использованием плоских файловстановится несколько болезненным, так как вам придется сопоставить ограничения безопасности файловой системы с логическими / контекстными ограничениями безопасности.Подобные проблемы часто приводят меня к предпочтению структурированного хранилища.

Идея вышеупомянутого кэширования хороша и может помочь создать некоторое промежуточное положение в отношении того, как часто вы действительно обращаетесь к своей базе данных., хотя это не поможет с проблемами, связанными с потреблением памяти, GC и т. д. Вы могли бы использовать встроенные механизмы кэширования, хотя Cache / Grid, который поддерживает резервные хранилища, был бы намного лучше, если бы вы могли себе это позволить (например, NCache,ScaleOut и т. Д.).Они обеспечивают хорошую масштабируемость / избыточность, а также могут использоваться для разгрузки хранилища состояния сеанса, состояния просмотра и многого другого.

Надеюсь, это поможет.

Answer 2

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

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

public class myPhototHandler: IHttpHandler
{    

    public bool IsReusable {
        get { return true; }
    }

    public void ProcessRequest(System.Web.HttpContext context)
    {

            if (Context.User.Identity.IsAuthenticated) {
                var filename = context.Request.QueryString("f") ?? String.Empty;
                string completePath = context.Server.MapPath(string.Format("~/App_Data/Photos/{0}", filename));
                context.Response.ContentType = "image/jpeg";
                context.Response.WriteFile(completePath);             
            }

    }

}

Чтобы узнать, как настроить обработчик, прочитайте этот пост и другие похожие посты.

Answer 3

У вас есть 2 варианта

1) Сохраните двоичный файл в базе данных. Поле VARBINARY (MAX) будет хорошим выбором типа данных. 2) Сохраните путь к изображению, хранящемуся на диске, в базе данных. NVARCHAR (MAX) будет хорошим выбором для типа данных.

Есть, конечно, за и против обоих решений. Не зная больше о ваших требованиях Трудно посоветовать, какой из них лучший.

Answer 4

Рассматривали ли вы кеширование ваших изображений, чтобы уменьшить время прохождения в оба конца на сервер SQL? Кэширование может быть целесообразным в браузере (через HTTP-заголовки ) и / или в обработчике HTTP, обслуживающем изображение (через System.Web.Caching ).

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

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

Answer 5

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

Вот так я и сделал на своем сайте.

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