【发布时间】:2011-01-11 06:20:57
【问题描述】:
我们正在将本地应用程序迁移到 Azure 云。内部企业用户通常通过管理界面将全尺寸图像上传到我们的网站(这些现在将被发送到 Azure blob 存储)。该站点负责在请求时创建正确的图像尺寸。所以现在发生的事情(本地环境)是这样的:
1) 用户上传完整大小的文件。
2) 当通过 GetImage HTTP 处理程序(即http://www.site.com/GetImage.aspx?imageid=15&height=100&width=100)请求较小的版本时,处理程序会检查我们之前是否创建了该尺寸的该图像的版本。如果是这样,它将直接写入响应流。如果没有,则需要一秒钟来调整大小,将其保存到“/iamges/cache”目录并将调整大小的图像写入响应流。
3) 下次以该大小请求该文件时,它会返回先前创建的图像。
所以我想使用 Azure 和 Blob 存储实现相同类型的机制,但我有几个问题:
1) 我不能简单地检查是否存在 blob。我必须先下载 blob,然后调用 FetchAttributes 以查看它是否引发异常。但是,这样做实际上会下载图像。那么这不会使图像请求的数量增加一倍(一个是查看它是否存在,另一个是向用户显示)?
2) 假设图像不存在我需要的大小(即 blob /images/cache/image_15_100_100.jpg 不存在 -- id #15, 100x100 像素)。因此,我向 CDN 发出了一次请求,以查看它是否存在。现在我必须下载一个 5-10 MB 的全尺寸图像(而不是从我们的本地文件系统中读取它,速度很快),将 5-10 MB 的图像加载到内存中,调整它的大小并重新上传到CDN。这似乎很耗时,尤其是当我可以在一个请求中获得 10-15 张这样的图像时。
我知道 Azure 相对较新,但是对于这种与 blob 存储的交互,是否有任何接近“最佳实践”的方法?我可以考虑另一种方法吗?这对于调整图像大小来说似乎有很多开销,所以我想我一定是遗漏了一些东西或忽略了另一个解决方案。
【问题讨论】:
-
可能的图像大小请求是预先确定的还是完全任意的?
-
目前它们在某种程度上是预先确定的,但业务需求表明我们需要能够即时调整大小。我已经考虑过以正确的尺寸预加载它们。 :)
-
为什么不使用 Azure SQL 来存储 Blob 和元数据,包括对特定大小的最后一个图像下载的引用,如果同一网络上的某人请求图像,您可以通过本地网络检索它,本地缓存等?您仍然可以下载图片
-
我们有超过 40GB 的图像。考虑到 SQL Azure 的最大数据库大小为 50GB 并且每月花费近 500 美元,这对于 SQL Azure 来说过于昂贵。