Программирование для Azure / CDN

Мы находимся в процессе переноса локального приложения в облако Azure. Внутренние корпоративные пользователи регулярно загружают полноразмерные изображения через интерфейс администратора на наш веб-сайт (теперь они будут отправляться в хранилище BLOB-объектов Azure). Сайт несет ответственность за создание изображений правильного размера по запросу. Итак, что происходит прямо сейчас (в локальной среде):

1) Пользователь загружает полноразмерный файл.

2) Когда уменьшенная версия запрашивается через обработчик HTTP GetImage (т.е. http://www.site.com/GetImage.aspx?imageid=15&height=100&width=100) обработчик проверяет, создавали ли мы ранее версию этого изображения такого размера. Если это так, он записывает его непосредственно в поток ответов. Если нет, требуется секунда, чтобы изменить его размер, сохранить его в каталоге «/iamges/cache» и записать измененный размер изображения в поток ответов.

3) В следующий раз, когда этот файл запрашивается в этом размере, он возвращает ранее созданное изображение.

Поэтому я хочу реализовать механизм того же типа, используя Azure и хранилище BLOB-объектов, но у меня есть несколько проблем:

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

2) Допустим, изображения нужного мне размера не существует (т. е. блоб /images/cache/image_15_100_100.jpg не существует — id #15, 100x100 пикселей). Итак, я однажды отправил запрос в CDN, чтобы узнать, существует ли он. Теперь мне нужно загрузить, возможно, полноразмерное изображение размером 5-10 МБ (в отличие от быстрого чтения из нашей локальной файловой системы), загрузить это изображение размером 5-10 МБ в память, изменить его размер и повторно загрузить его в CDN. Это требует много времени, особенно когда я могу получить 10-15 таких изображений по одному запросу.

Я знаю, что Azure является относительно новым продуктом, но есть ли что-то близкое к «наилучшей практике» для такого типа взаимодействия с хранилищем BLOB-объектов? Есть ли другой подход, который я мог бы рассмотреть? Это просто кажется большим количеством накладных расходов для изменения размера изображения, поэтому я полагаю, что должен что-то упустить или упустить из виду другое решение.


person Scott    schedule 10.01.2011    source источник
comment
Предопределены ли возможные запросы на размер изображения или они полностью произвольны?   -  person Omar    schedule 10.01.2011
comment
На данный момент они в некоторой степени предопределены, но бизнес-требования гласят, что мы должны иметь возможность изменять размер до любого размера на лету. Я думал о предварительной загрузке их в правильных размерах уже. :)   -  person Scott    schedule 10.01.2011
comment
Почему бы не использовать Azure SQL для хранения больших двоичных объектов и метаданных, включая ссылки на последнюю загрузку изображения определенного размера, если кто-то в той же сети запрашивает изображения, которые вы можете получить через локальную сеть, кэшировать локально и т. д.? У вас все равно будут загружаемые изображения   -  person Lloyd    schedule 10.01.2011
comment
У нас есть более 40 ГБ изображений. Это было бы непомерно дорого для SQL Azure, учитывая, что максимальный размер их базы данных составляет 50 ГБ и стоит почти 500 долларов в месяц.   -  person Scott    schedule 10.01.2011


Ответы (1)


Хорошо, я думаю, здесь много чего происходит. Мой ответ основан на следующих предположениях:

  • Окончательное использование этих изображений должно отображаться на веб-сайте.
  • Упомянутый выше веб-сайт работает на Azure.
  • Вы хотите использовать CDN для ускорения доступа к изображениям
  • Вы используете клиентскую библиотеку хранилища .Net.

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

  1. Вы правы, в клиентской библиотеке .Net нет встроенного метода, позволяющего проверить, существует ли большой двоичный объект. Но при выполнении .FetchAttributes() изображение фактически не загружается, а просто пытается получить информацию о заголовке (во многом аналогично тому, когда вы перечисляете все большие двоичные объекты в контейнере), большие двоичные объекты фактически не загружаются, пока вы не вызовете один из методов .DownloadX().

  2. Вашему коду на стороне сервера не нужно говорить, чтобы использовать какие-либо функции CDN. Он должен просто общаться с вашими изображениями в хранилище BLOB-объектов, как с любым старым BLOB-объектом. Единственный раз, когда вам нужно использовать URL-адреса CDN, — это когда вы указываете путь к изображениям на отображаемой странице.

  3. Вы не хотите, чтобы ваш веб-сайт возвращал поток изображения, вы хотите, чтобы он указывал на URL-адрес в CDN, содержащий изображение. CDN сможет справиться с гораздо большей нагрузкой, чем любой веб-сайт, который вы можете создать. Затем веб-сайт может проверить, существует ли большой двоичный объект, и если он существует, просто верните URL-адрес. Если он не загружает полное изображение, измените его размер, сохраните, а затем верните URL-адрес. Хотя доступ к изображению из хранилища больших двоичных объектов не такой быстрый, как чтение с локального диска, он все же довольно быстрый, особенно для файлов размером ‹10 МБ, о которых вы говорите.

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

person knightpfhor    schedule 10.01.2011