代码之家  ›  专栏  ›  技术社区  ›  Jason Jackson

是否有一种设计模式用于处理互联网上的大型数据集?

silverlight-3.0 design-patterns silverlight wcf c#
  •  13
  • Jason Jackson  · 技术社区  · 16 年前

    我正在寻找一种设计模式,它可以通过internet处理大型数据集,并定期更新这些对象。我正在开发一个应用程序,它将在UI中一次显示数千条记录。此外,这些对象上的各种属性非常短暂,需要在客户机上更新,以使用户了解系统中这些记录的变化状态。我对如何解决这个问题有一些想法,但我认为可能有一种设计模式(或多种模式)可以处理这种类型的场景。

    限制:

    1. 这方面的客户端是用Silverlight编写的。
    3. 我将能够限制正在更新的数千个对象的部分。然而,我需要用户能够“缩小”上下文,允许粒度更新到显示所有数千个对象的上下文。我设想,当对象离开足够的缩放上下文时,将再次禁用对象的更新。

    关于如何解决全部或部分问题的想法?就像我提到的,我已经在考虑一些想法了,但是到目前为止,我还没有整理出任何东西给我一个关于这个项目成功的好感觉。

    1. 通过internet加载大量记录(~5k)。
    2. 保持这些对象的子集(~500)在internet上更新到最新状态。

    有几种设计模式可以用于其他任何事情。

    编辑2:

    编辑3:跟进推送技术。

    正如我所怀疑的,Silverlight WCF双工实现 comet-like push . 这不会扩展,而且有很多文章都是关于它在现实世界中如何不扩展的。

    Silverlight中的套接字实现在几个方面受到了破坏。在我们的场景中,它看起来是无用的,因为web服务器可能位于任何给定的客户端防火墙后面,该防火墙不允许非标准端口,Silverlight套接字也不允许在80443上连接,等等。

    我仍在考虑以某种有限的方式使用WCFduplex方法,但看起来投票将是答案。

    我发现 this pattern (PDF)

    全部的 数据预先处理,然后发送更改增量(可能需要子系统中的一些附加代码来提供更改通知)。这可能是我的第一个方法。我还在找。感谢到目前为止的所有想法。

    8 回复  |  直到 16 年前
        1
  •  2
  •   monksy    16 年前

    proxy design pattern 是有助于将数据从一点传输到另一点的模式。代理设计模式将允许您将远程对象视为本地对象。

        2
  •  2
  •   Buzz    16 年前

    2建议的解决方案可以是

    2) 使用Flyweight+代理模式。

        3
  •  2
  •   Doug L.    16 年前

    我想知道您是否可以首先减少进入客户端屏幕的数据量?无论如何,你不能同时看到5000个数据点。如果你需要滚动查找重要的内容,可以考虑先过滤掉不重要的内容。考虑一些用户界面设计(仪表板和仪表类型的东西),以便用户只看到故障点。然后他们可以钻进去,并根据需要采取行动。

        4
  •  1
  •   FrenchData    16 年前

    在这里我发现了一篇文章,它似乎解释了如何在Silverlight2中创建套接字 Silverlight 2 and System.Net.Sockets.Socket

    我还没有深入阅读过它(这对我来说太晚了一点),但它似乎可以用于您的情况。我看到的主要限制是您的silverlight应用程序只能连接到下载它的服务器。

    Silverlight using socket

    我希望这会有所帮助

        5
  •  1
  •   philfreo    16 年前

    当你在设计时,我想你会遇到一些DPs,这些DPs可能会在一个小的层面上帮助你,但是这个巨大的东西应该如何工作的细节更多的是一个一般的(和有趣的)设计问题。

    也许稍微澄清一下你的问题可以帮助人们对这个系统的总体设计提出建议。此外,一旦你投入了一些设计/努力,提出了一个关于这应该如何工作的高级设计,你就可以征求批评/建议。对于一个人来说,很难完全将此作为对StackOverflow问题的回答。:)

        6
  •  1
  •   PL.    16 年前

    1. 系统状态由来自多个数据源的数据表示。因此,查询状态的代价很高。
    2. 描述系统状态的数据量很大。因此,查询描述该状态的所有数据的成本很高。

    解决这些问题的标准模式是引入中间层并使用增量更新状态。例如。:

    1. 显然,您不希望Silverlight客户端直接与后端系统通信。这不仅不可能,而且效率也很低,因为每个客户机都可以询问相同的数据源有关其状态的信息。为了避免这种标准解决方案,需要引入一个中间层来聚合来自所有后端数据源的数据,并为客户端提供公共接口。因此,后端数据源只会根据需要进行轮询(可以在中间层中针对每个数据源进行配置),而且客户端不必处理这些备份数据源的细节。此外,您还可以基于客户端最常见的查询,在中间层实现数据索引。

    2. 假设每个记录都有ID,客户端应该只请求自上次更新以来的增量。许多模式之一是使用时间戳。例如,当客户端初始化时,它请求系统的状态,中间层发送带有时间戳的状态。当客户机需要更新某些记录时,它会在请求中提供ID以及上次更新的时间戳。因此,中间层将只发送自最后一个时间戳以来的更改,并且只发送请求的ID。如果对象有15个属性,并且自上次时间戳以来仅更改了其中的3个属性,则更新将仅包含这3个属性的值。

    至于推送与投票,推送并不是自动的最佳解决方案。这实际上是一个权衡客户机需要更新的频率和客户机/中间层之间的通信量的问题。例如,如果状态更改频繁但稀疏(例如,一次只影响几个属性),并且不需要立即更新客户机的状态,则客户机可能希望更改累积,而不是接收每个更新,因此轮询更可取。

        7
  •  0
  •   andyp    16 年前

    我认为您可能遗漏了一些东西:自从Silverlight3以来,就有了将数据推送到客户端的能力。 Here 这是一篇可能会有帮助的文章。

        8
  •  0
  •   Community Mohan Dere    9 年前

    1. 我使用bean来表示那个大数据图。这就消除了 XML的传输。无论如何,我只关心数据的一个子集,尽管它是一个相当重要的子集。通过将数据扁平化为一个bean,我认为我已经将序列化对象的大小减少到原始对象图的20-25%左右。
    2. 现在,后端上的几乎所有数据都将有一个上次修改时的字段。我能为所有的大数据得到这个。有一些数据不会有这种情况,但是查询性能和数据聚合的实际问题已经用这种情况解决了。作为其他数据库的通用解决方案,在许多数据库管理系统中实现起来似乎相当简单。
    3. 我正在编写新的API来检索在提供的日期时间之后更新的数据。这允许我仅从后端系统查询新的和更改的对象(这是调用这些API的web服务,Silverlight调用web服务)。
    4. 那个 在30秒内有很多变化。处理所有这些的web服务调用对初始加载调用的反应与轮询相同。它所关心的只是检索比给定时间更新的数据。
    5. 我编写了一个从处理查询和轮询的ObservableCollection继承的集合。使用此集合的客户端代码提供查询数据的委托。日期以页的形式异步返回。我还没有确定页面大小。它会一直重新查询页面,直到服务器返回小于最大页面大小的页面。该集合还提供了有关如何确定集合中最新对象的最新日期的信息。它会定期轮询更新,以查找比集合中最新项目更新的更新。实际上,这个“最新日期”实际上是一个对象,包含原始对象图各个部分的几个日期。如果某项从集合中存在的服务器返回,则集合中的该项将使用该返回的数据进行更新。我这样做,而不是插入新项目和删除旧的,因为它在更多的数据绑定情况下工作。

    我仍然有一个关于我执行这个的问题 I have posted here .

    推荐文章
    关于   移动版
    代码之家 - 一站式码农服务社区
    沪ICP备11025650号