1

这是我面临的一个设计疑问，我收集了 1500 张要在 ASP.NET 页面上显示的图像，要显示的图像因页面而异，这些图像的数量会随着时间的推移而增加来，

a.) 将图像保存在数据库中是个好主意，但是从数据库中获取图像的往返时间可能很长。

b.) 将所有图像都放在一个目录中，并在其上拥有一个虚拟文件系统，并且应用程序将从目录中访问图像是否很好

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

编辑 1： 每 12 小时每张图片都会被其新条目替换一次，因此就我能想到的而言，将它们放在数据库中可能不是一个好主意，但是使用数据存储和索引这些会更好图片？

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

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

4

5 回答 5

2

All of the previous comments are really good... In the absence of very specific requirements we have to make broad generalizations to illustrate your options. Here are a few examples.

  • If raw speed是您所需要的，那么平面文件无疑是赢家。无论您使用的是 Apache 还是 IIS，它们都经过优化，可以非常快速地提供基于静态文件的内容。高性能网站都知道这一点，并且会在考虑动态处理的情况下存储大部分内容，然后会“发布”部分动态内容；在静态版本中；定期或基于事件驱动的网络农场。尽管它需要一些编排，但它可以廉价地完成，并且可以真正减少数据库服务器、后端网络等的负载。举个简单的例子，发布到一个文件夹，该结构的根目录被动态评估。当您准备好发布更新时，编写一个新文件夹，然后更改根路径。没有停机时间，便宜又容易。在相关说明中，从后端存储中提取所有这些信息将需要您将这些内容加载到内存中。这最终将转化为垃圾收集的更多时间，因此意味着您的应用程序会变慢，即使您使用的是多处理器/核心园艺。

  • 如果您需要对图像的组织/曝光方式进行细粒度控制，那么文件夹可能不是最合适的。例如，如果您需要组织单个用户的图像，并且需要跟踪图像周围的大量元数据，那么数据库可能是一个不错的选择。话虽如此，您的数据库团队可能会因此而讨厌您，因为从数据库管理的角度来看，这会带来许多挑战。此外，如果您使用的是 ORM，您可能会遇到一些麻烦，并且可能会发现由于隐藏的代理对象、二级缓存等原因，您的内存占用量会增长到不可接受的水平。这一切都可以缓解，所以请注意并确保您分析您的应用程序。话虽如此，结构化存储（如数据库）更适合此用例。

  • Considering security... Depending on what these images represent, flat files inevitably lead to concerns about canonicalization attacks, brute-force enumeration of browsable folder structures, replaying cookies, urls, viewstate, etc. If you're using a custom Role-based or Claims-based security model you may find using flat files becomes somewhat painful since you'll have to map filesystem security constraints to logical/contextual security constraints. Issues like these often lead me to favoring a structured store.

前面提到的缓存想法是一个很好的想法，可以帮助您在实际访问数据库的频率方面建立一些中间立场，尽管它对与内存消耗、GC 等相关的问题没有帮助......您可以使用内置在缓存机制中，尽管支持后备存储的缓存/网格会更好，如果你能负担得起（例如 NCache、ScaleOut 等）。这些提供了很好的可扩展性/冗余性，还可以用于卸载会话状态、视图状态等的存储。

希望这可以帮助。

于 2010-05-14T18:04:38.363 回答
1

你基本上有2个选择

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

这两种解决方案当然各有利弊。在不了解您的要求的情况下，很难建议哪种方法是最好的。

于 2010-05-14T15:23:59.783 回答
1

我不喜欢将图像存储在数据库中 - 而只是将链接（路径/文件名/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);             
            }

    }

}

有关设置处理程序的重要资源，请查看此博客文章和其他相关文章。

于 2010-05-14T15:29:10.663 回答
0

我不会使您的解决方案过于复杂。在数据库中存储图像的缺点是数据库膨胀和备份的存储要求，尤其是如果图像只能保存 12 小时。如果有疑问，请保持简单，这样当需求发生变化时，您无论如何都没有投入那么多时间。

这就是我在我的网站上所做的。

  • 将图像存储在文件夹中。
  • 如果您想控制用户看到的文件名，或使用条件逻辑，请使用 HttpHandler 来提供图像，否则只需在 img 标记中使用其完整路径和文件名。
  • 如果您正在谈论大容量的大型网站，也许可以考虑使用内容交付网络。
于 2010-05-14T15:48:46.177 回答
0

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

Storing images in SQL server can be convenient because you don't have to worry about maintaining pointers to the file system. However, the size of your database will obviously be much larger which can make backups and maintenance more complex. You might consider using a different file group within your database for your image tables, or a separate database altogether, so that you can maintain row data separate from image data.

Using SQL server also means you'll have easy options for concurrency control, partitioning and replication, should they be appropriate to your application.

于 2010-05-14T15:55:38.240 回答