Question

这是一个设计上的疑问，我有一个1500个图像的集合，将在asp.net页面上显示，要显示的图像从一个页面到另一个页面不同，这些图像的数量将增加时间到了，

a。）将图像放在数据库上是一个好主意，但从数据库中获取图像的往返时间可能很长。

b。）将所有图像放在目录上并在其上有一个虚拟文件系统是好的，应用程序将从目录中访问图像

我们是否特别在传统数据库中采用任何设计策略来获取具有最少往返时间的图像，除了使用传统数据库之外是否存在任何解决方案？

编辑1： 每隔12小时，每个图像都被其新条目替换，因此将它们放在数据库上可能不是我想象的好主意，但使用数据存储并索引这些图像有多好？

编辑2： 是的，我们计划在群集上运行该应用程序。如果我们尝试使用数据存储区（如果它是一个很好的选择）那么它是否与C＃兼容？ ASP.NET？

ps：我使用SQL Server来存储这些图像。

Answer 1

之前的所有评论都非常好......如果没有非常具体的要求，我们必须进行广泛的概括来说明您的选择。以下是一些例子。

如果原始速度是您所需要的，那么平面文件就是明显的赢家。无论您使用的是Apache还是IIS，它们都经过优化，可以非常快速地提供基于静态文件的内容。高性能网站都知道这一点，并会将大部分内容存储在动态处理中，但会“发布”其动态内容的选定部分;在静态版本;以定期或事件为基础到他们的Web场。虽然它需要一些编排，但它可以廉价地完成，并且可以真正减少数据库服务器，后端网络等的负载。作为一个简单的示例，发布到动态评估该结构的根目录的文件夹。当您准备发布更新时，请编写新文件夹，然后更改根路径。没有停机时间，便宜，容易。在相关的说明中，从后端存储中提取所有这些信息将需要您将这些内容加载到内存中。这最终将转化为垃圾收集的更多时间，因此即使您使用的是多处理器/核心园艺，也意味着您的应用程序会更慢。
如果您需要细粒度控制而不是图像的组织/曝光方式，那么文件夹可能不是最合适的。例如，如果您需要组织单个用户图像，并且需要跟踪图像周围的大量元数据，那么数据库可能非常适合。话虽如此，您的数据库团队可能会讨厌您，因为从数据库管理的角度来看，这会带来许多挑战。此外，如果您正在使用ORM，则可能会在执行此操作时遇到一些问题，并且由于隐藏的代理对象，二级缓存等原因，可能会发现您的内存占用增长到不可接受的水平。这一切都可以减轻，所以请注意确保您描述您的申请。话虽如此，结构化存储（如数据库）更适合这种用例。
考虑安全性 ...根据这些图片所代表的内容，平面文件不可避免地会导致对规范化攻击，可浏览文件夹结构的强力枚举，重放Cookie，网址，视图状态的担忧如果您使用自定义的基于角色或基于声明的安全模型，您可能会发现使用平面文件会变得有些痛苦，因为您必须将文件系统安全性约束映射到逻辑/上下文安全性约束。这些问题经常使我偏向于结构化商店。

前面提到的缓存理念很好，可以帮助创建一些关于实际命中数据库频率的中间立场，尽管它对内存消耗，GC等相关问题没有帮助......你可以虽然支持后备存储的Cache / Grid如果能负担得起（例如，NCache，ScaleOut等），它会使用内置的缓存机制。这些提供了良好的可伸缩性/冗余性，还可用于卸载会话状态，视图状态等等的存储。

希望这有帮助。

Answer 2

你基本上有2个选项

1）将二进制文件存储在数据库中。 VARBINARY（MAX）字段将是数据类型的不错选择。 2）将路径存储到数据库中存储在磁盘上的映像。 NVARCHAR（MAX）将是数据类型的不错选择。

当然，这两种解决方案都有所不同。在不了解您的要求的情况下很难建议哪种方式最好。

Answer 3

我不想将图像存储在数据库中 - 而只是将链接（路径/文件名/ ID等）存储到正确的图像中。

然后，如果您实现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);             
            }

    }

}

有关设置处理程序的绝佳资源，请查看this blog post以及其他相关帖子。

Answer 4

我不会过分复杂你的解决方案。将图像存储在数据库中的缺点是备份的数据库膨胀和存储要求，特别是如果图像仅适用于12小时。如果有疑问，请保持简单，因此当需求发生变化时，您无需投入那么多时间。

这就是我在网站上的表现。

将图像存储在文件夹中。
如果您想控制用户看到的文件名，或使用条件逻辑，请使用HttpHandler提供图像，否则只需在img标记中使用其完整路径和文件名。
如果您正在谈论高容量的大型网站，也许可以考虑使用内容分发网络。

Answer 5

您是否考虑过缓存图片以减少到SQL服务器的往返时间？缓存可能适合浏览器（通过HTTP Headers）和/或提供图像的HTTP处理程序（通过System.Web.Caching）。

在SQL Server中存储图像非常方便，因为您不必担心维护指向文件系统的指针。但是，数据库的大小显然会大得多，这会使备份和维护变得更加复杂。您可以考虑在数据库中为映像表或单独的数据库使用不同的文件组，以便可以将行数据与图像数据分开。

使用SQL服务器还意味着，如果它们适合您的应用程序，您将拥有简单的并发控制，分区和复制选项。

存储 - 获取图像的设计解决方案

5 个答案: