【问题标题】:How do I cache a large dataset that takes several minutes to return?如何缓存需要几分钟才能返回的大型数据集?
【发布时间】:2011-05-12 21:46:25
【问题描述】:

这是背景,我有一个来自供应商/合作伙伴的 Web 服务,它返回我用来显示数据的大型 XML 文档。很简单。问题是该服务需要几分钟才能执行。供应商在一个方法调用中将整个规范化数据库作为 XML 文档返回,而且速度很慢。愚蠢的供应商,但我无法控制。

我有两个问题:

  1. 在哪里缓存它?磁盘、数据库、内存(我倾向于将其放在磁盘上。它太大且无法访问到足以存储在内存中。将它放在数据库中可能正确,但我不想编写 ETL 并在某处运行作业。)

  2. 如何缓存它?我不能让它过期并让下一个请求刷新缓存,因为它需要很长时间。我需要在缓存重建时提供陈旧的数据。我可以想到几种方法,但没有一种方法看起来简单或非常优雅。我想做一些简单的事情;我不是在寻找有史以来最好的工程解决方案。

这是我的计划...请告诉我我是个白痴,并提出一些我忽略的更简单的建议。

      将 XML 写入磁盘
      同时将文件名和某种过期炸弹写入缓存(显然文件名不会过期很长时间)
      在我的工作线程中,尝试从缓存中读取我的炸弹
      如果缓存过期(我的炸弹爆炸了)然后生成一个线程来获取并保存 XML
      同时,从缓存中获取文件名并在构建新 XML 时读取旧 XML
      当新文件完成后,从缓存中过期旧文件名并将文件名写入缓存

    这对我来说听起来很荒谬,必须有更好的方法。

    我正在使用 .Net 和 IIS6,如果需要,我可以将 XML 粘贴到 SQL Server 中。

    【问题讨论】:

    • 为什么不能将这些数据存储在内存中?您要存储的对象有多大?
    • 为什么你不能只延长 iis 的连接超时时间,以便有足够的时间下载整个文件?这个文件到底有多大?!
    • 该对象有几 MB 大小,我承认它并不大,但它的访问频率也不够高,以至于我想将它缓存在内存中。我已经考虑过接受打击,我仍然可能会朝那个方向发展。我已经更改了超时,但我不能让用户等待 90 秒来呈现数据,所以我需要在缓存重建时为用户提供一些服务。

    标签: .net xml caching


    【解决方案1】:

    您可以创建一个新数据库和一个计划作业来定期获取这些数据并将它们存储到数据库中。然后,您可以直接从数据库而不是 Web 服务提供实际需要的数据。

    【讨论】:

    • 我考虑过这样做,但是 SQL 作业是另一个必须管理的故障点,添加另一个数据库是另一个需要维护的对象。直到一年前,这些数据都在内部托管。与供应商合作的部分原因是不必在内部维护数据或构建接口来管理数据。我们要做的就是渲染数据。
    • 另外一件快速的事情,如果我将它粘贴到 SQL 中,我会将整个对象粘贴到 SQL 中。我不会将其解构为标准化形式。这是一个我没有多少时间或资源的项目。除了缓存之外,我已经完成了一切,我不想花时间重建我的数据访问层。我不是要偷懒,而是要务实。
    • @Jay,你能告诉我们更多关于那个物体的信息吗?你说那个对象有几MB大小?您需要在视图中显示整个对象,还是只需要显示该对象的某个部分? 90 秒的数据渲染时间太长了。
    • 当然,该对象本质上是一个标准化的 DB,序列化为 XML 并通过 Web 服务提供。数据模型将是一个主表,与其他表有几个外键关系,其中一些表有自己的外键关系。嵌套的级别可能是 4-5 深。坦率地说,它不是一个伟大的网络服务(不是一个伟大的供应商)。我不需要一次所有的数据,但没有有用的方法来提取我需要的东西。返回数据子集的方法会遗漏重要字段或需要在循环中进行调用。其中一个示例是返回联系人列表。
    • 抱歉不得不继续...无论如何,我可以得到一个过滤的联系人列表,但我没有得到列表的元数据,所以我必须进行后续调用以获取相关的元数据接触。老实说,这是一个糟糕的服务,可能位于设计不当的数据库上。我不确定为什么服务返回基础对象的速度如此之慢,但确实如此。最好的情况是 45 秒,最坏的情况是差不多两分钟。一旦我从他们那里获得了对象并且正在使用磁盘或数据库中的本地副本,它就会飞起来(因此我的问题是关于如何缓存这些东西)。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多