1. 首页
  2. 问答
  3. 用于ASP.NET应用程序中搜索结果的缓存体系结构

用于ASP.NET应用程序中搜索结果的缓存体系结构

2009-10-12 28 views
12

在ASP.NET系统中缓存昂贵搜索结果的好设计是什么？用于ASP.NET应用程序中搜索结果的缓存体系结构

任何想法都会受到欢迎...特别是那些不需要发明我们自己的复杂基础设施的想法。

下面是相关问题的一些总体要求：以几百结果记录

  • 每个搜索是相对昂贵和费时执行

    • 每个搜索结果可以生产从零包括：（5-15秒在数据库中）
    • 结果必须在客户端显示之前进行分页，以避免用户信息过载
    • 用户希望能够在返回的结果中进行排序，过滤和搜索
      • 个
    • 用户期望能够在搜索页面之间快速切换导致
    • 用户期望能够在任意数量的页面选择
    • 用户期望比较精力充沛的表现一次搜索有多个项目（通过复选框）完成

    我看到在哪里以及如何实现缓存一些可能的选项：

    1.在服务器（在会话或应用程序缓存）的缓存，使用回传或Ajax的面板，以促进有效的分页，排序，过滤器ng和搜索。

    • 的观光：从ASP.NET基础设施
    • 缺点容易实现，体面的支持：在服务器上非常健谈，内存密集型，数据可以被缓存超过所需的时间;禁止负载平衡做法

    2.缓存在服务器（如上所述），但使用的是被移出的存储器的一段时间后，以减少在服务器上存储的压力可序列化结构

    • PROS：高效使用服务器内存;使用负载平衡扩展的能力;
    • CONS：.NET基础结构的有限支持;当数据结构发生变化时可能很脆弱;给数据库增加额外的负载;显着更复杂

    3.在客户端缓存（使用JSON或XML序列化），使用客户端JavaScript进行分页，排序，筛选和选择结果。

    • 的观光：用户体验可以接近 “富客户端” 的水平;大多数浏览器可以本地处理JSON/XML - 体面库操纵存在（例如jQuery的）
    • CONS：初始请求可以采用很长的时间来下载;客户端机器上占用大量内存;将需要的手工制作的Javascript在一定程度上实现使用的数据的压缩/编码表示在客户机上

    4.缓存 - 回调到服务器切换时的页面，排序，过滤和搜索解码。

    • PROS：服务器最小化存储器的影响;只要客户需要，州就可以生存;在客户端略有改善存储器使用超过JSON/XML
    • CONS：大型数据集的客户端/服务器之间来回移动;与使用JSON/XML的纯客户端缓存相比，性能降低（由于网络I/O）;更为复杂的实施 - 从.NET /浏览器

    5.一些替代缓存方案我还没有考虑有限的支持...

    • 来源

    2009-10-12 LBushkin

    +1

    建议：对您的原始标题“搜索结果缓存”进行一些搜索。只在你的场景中进行缓存，是自己动手做的。去过也做过;搜索很困难。只是在说。 – jro 2009-10-22 16:49:43

    +1

    就数据库查询而言，5-15秒是很长的时间。也许你应该把重点放在改进数据库查询（使用“内部连接”而不是“外部连接”，使用“内部连接”而不是“where”过滤器）上。另请考虑使用全文索引。 – 2009-10-26 08:48:43

    回答

    12

    ＃1，你有没有使用状态服务器考虑（甚至SQL服务器）还是共享缓存机制？有从plentygoodones到choose，并Velocity越来越非常成熟 - 不久可能会RTM。缓存失效方案基于用户是否创建新的搜索，除了搜索分页之外是否还有其他页面，以及最终标准超时（20分钟）在将缓存除草为最小尺寸时应该相当成功。

    参考文献：

    来源

    2009-10-12 19:03:28

    +0

    SharedCache对我们来说效果很好，性能方面一直在击败Velocity。您可能还想将Memcached添加到列表中，但您必须编写自己的库以通过.NET访问它 – BozoJoe 2010-10-07 20:54:07

    1

    既然你说任何想法，欢迎：

    我们一直在使用企业库缓存相当成功从LINQ结果缓存结果集。

    http://msdn.microsoft.com/en-us/library/cc467894.aspx

    它支持自定义缓存过期，所以应该支持满足你的需要（与自定义代码一点点）那里。如果搜索的隐私很重要，它也有不少支持商店，包括加密支持商店。

    这是相当全面的功能。

    我的建议是的＃1和＃3组合：

    1. 缓存服务器上的查询结果。
    2. 使结果以整页形式和JSON视图形式提供。
    3. 缓存在客户端动态检索的每个页面，但每次页面更改时发送一个REQUEST。
    4. 使用ETAG做客户端缓存失效。

    来源

    2009-10-12 19:04:27

    0

    看看SharedCache - 它使1/2非常容易，并在负载平衡系统中正常工作。免费，开放源代码，我们已经使用它约一年没有问题。

    来源

    2009-10-12 19:05:08 nitzmahone

    3

    在“备选”缓存方案下提出一个想法。这不会用给定的缓存架构来回答您的问题，而是回到您的搜索应用程序的原始要求。

    即使如果/当你实现你自己的缓存，它的效果可以小于最佳 - 尤其是你的搜索索引的规模增长。随着索引增长，缓存命中率将下降。在某个拐点处，由于搜索和缓存专用资源，您的搜索实际上可能会减慢。

    大多数搜索子系统都实现了自己的内部缓存体系结构，以此作为提高运行效率的手段。 Solr是一个基于Lucene的开源搜索系统，它拥有自己的内部缓存以提供快速操作。还有其他的搜索系统可以为你工作，他们采取类似的策略来缓存结果。

    我会建议你考虑一个单独的搜索架构，如果你的搜索索引工作的需要，作为缓存，或在自由文本关键字搜索的基础是有效地实现复杂的操作。

    来源

    2009-10-12 19:58:11 jro

    5

    如果您能够等到2010年3月，.NET 4.0会附带一个新的System.Caching.CacheProvider，它承诺提供大量的实现（如上所述的磁盘，内存，SQL Server/Velocity）。

    有技术here好的幻灯片。然而，它有点“滚动你自己”或很多事实。但是当框架发布时，可能会有很多封闭和开源供应商为Provider模型编写。

    为你的国家的六分，有几个问题作物达

    • 什么是包含在搜索结果中？只是字符串数据或与每个结果关联的大量元数据？
    • 你正在搜索的曲集有多大？

    多少内存将使用存储在RAM整个集合？或者至少拥有最受欢迎的10到100个搜索字词的缓存。在第一次搜索之后进行智能和缓存相关搜索可能是另一个想法。

    5-15秒的结果是一个漫长的时间等待一个搜索，所以我假定这是一个expedia.com搜索，其中多个源被查询和大量的信息返回某种类似。

    从我有限的经验来看，客户端唯一缓存方法的最大问题是Internet Explorer 6 or 7。只有服务器和HTML是我的首选，并将缓存中的整个结果集用于分页，并在一段合理的时间后过期。但是你可能已经尝试过了，看到服务器的内存被吃掉了。

    来源

    2009-10-22 15:24:45

    0

    在思考您的选择时，请考虑没有用户想要翻阅数据。我们强迫他们作为试图在HTML浏览器之上构建应用程序的工具，这本质上不能很好地扩展。我们已经发明了各种各样的骇客来伪造应用程序状态，但它本质上是一个破碎的模型。

    因此，请考虑在Silverlight或Flash中将其实施为实际的富客户端。您不会击败用户体验，并且缓存比常规网页中实际大得多的数据非常简单。根据预期的用户行为，您的整体带宽可能会得到优化，因为到服务器的往返行程只会得到一个紧凑的数据集，而不是任何ASP.NET开销。

    来源

    2009-10-29 06:08:07

    相关问题

     相关问题