是否有通过互联网处理大型数据集的设计模式？

Question

我正在寻找一种通过互联网处理大型数据集的设计模式,并定期更新这些对象.我正在开发一个应用程序,它将一次在UI中显示数千条记录.此外,这些对象上的各种属性非常短暂,需要在客户端上进行更新,以使用户了解系统中这些记录的更改状态.我有一些想法如何处理这个问题,但想到可能有一个处理这种情况的设计模式(或模式).

限制:

1. 客户端就是用Silverlight编写的.
2. 对象本身不是很大(大约15个值类型和字符串属性),但查询所有数据是昂贵的.大约15个属性包含来自各种来源的数据; 没有聪明的连接语句或索引可以加快查询速度.我想在初始加载时只填充属性的一部分,然后在用户放大给定的对象分组时填充更昂贵的细节.想想谷歌地图,但不是街道和建筑物,而是显示对象.
3. 我将能够限制正在更新的数千个对象的部分.但是,我需要用户能够"缩小"允许粒度更新的上下文,以显示所有数千个对象.我想当对象离开足够的缩放上下文时,将再次禁用更新.

关于如何解决这个问题的全部或部分的想法？就像我提到的那样,我已经考虑了一些想法,但到目前为止,我所做的一切都没有让我对这个项目的成功有一个很好的感觉.

编辑:

我认为困难的部分实际上归结为两件事,我可能需要两种截然不同的模式/做法/策略:

1. 通过互联网加载大量记录(~5k).
2. 保持这些对象的子集(~500)通过互联网更新到最新.

有几种设计模式可用于其他一切.

编辑2:

感谢Silverlight中各种"推送"实现的链接.我可以发誓套接字已从Silverlight中取出,但根据下面的答案找到了Silverlight 3参考.这对我来说真的不是一个大问题,而且我没有花太多时间研究,所以我正在编辑原始文本.无论是通过民意调查还是通过推送进行更新,一般的设计问题仍然存在.很高兴知道我有选择权.

编辑3:推动技术的后续行动.

我怀疑Silverlight WCF双工实现是类似于彗星的推送.这不会扩展,并且有很多关于它在现实世界中如何不存在的文章.

Silverlight中的套接字实现以多种方式瘫痪.看起来它在我们的场景中将毫无用处,因为Web服务器可能位于任何给定的客户端防火墙后面,不允许非标准端口,并且Silverlight套接字不会连接到80,443等.

我仍在考虑以有限的方式使用WCFduplex方法,但看起来轮询将成为答案.

编辑4:找到一个模式来解决我的一半问题

我发现这个模式(PDF)说明了使用迭代器模式从服务器检索数据页并将它们呈现为一个简单的迭代器.在.Net中我想象这将实现为IEnumerable(示例代码在Java和Oracle SQL中).我特别感兴趣的是异步页面预取,基本上缓冲结果集客户端.使用5k对象时,所有内容都不会同时出现在屏幕上,因此我可以使用一种策略,即不会立即获取所有内容,而是从UI中隐藏实现细节.应用程序将检索的核心对象位于数据库中,然后需要其他查找才能完全填充这些对象.这种方法似乎是一种快速将一些数据输出到客户端的好方法.

我现在正在考虑使用这种模式+某种代理对象模式,它监听结果集的增量并相应地更新对象.这里可以采取一些策略.我可以加载所有数据前期,然后发送变化的增量(这可能需要在子系统中一些额外的代码,以提供改变的通知).这可能是我的第一种方法.我还在寻找.感谢到目前为止的所有想法.

Answer 1

我对几个好的答案投了赞成票，但提出了一个解决方案，对后端数据进行了一些更改，并提供了一种从 Silverlight 检索数据的新方法。以下是为解决这个问题正在采取的措施：

1. 我使用 beans 来表示大数据图。这去掉了很多传输XML。无论如何，我只关心数据的一个子集，尽管它是一个相当重要的子集。通过将数据扁平化到一个 bean 中，我认为我已经将序列化对象的大小减少到原始对象图的 20 - 25% 左右。
2. 几乎后端的所有数据现在都会有一个最后一次修改的字段。我能够从所有大数据中得到这个。有一些数据不会有这个，但是查询性能和数据聚合的真正问题由此解决。作为其他人的通用解决方案，在许多 DBMS 中实现起来似乎相当简单。
3. 我正在编写新的 API 来检索在提供的日期时间之后更新的数据。这允许我仅从后端系统查询新的和更改的对象（这是调用这些 API 的 Web 服务，Silverlight 正在调用该 Web 服务）。
4. 聚合 Web 服务中的更改并检测数据图的一部分是否已更改。为简单起见，如果有任何变化，我只发送整个数据图。这实际上是最难弄清楚的部分。数据图的一部分可能有新的更新时间，但图的核心对象尚未更新。我最终不得不编写 API 来查找子对象的更改，然后编写 API 来根据这些子对象（如果它们已更改）查找根对象。对象图可以与自上次轮询以来尚未更新的根对象（实际上是对象图的大部分）一起返回。Web 服务逻辑正在查询少量更改，因此即使单独的查询并不便宜，但每次轮询它们可能只会运行几次。即使在我们产品的非常大的安装中，这个查询循环也只会在每个轮询周期运行 10 或 20 次（请参阅下面的我的轮询解决方案）。虽然我们的系统非常动态，但30 秒内不会发生太大变化。处理所有这些的 Web 服务调用对初始加载调用的反应与轮询相同。它所关心的只是检索比给定时间更新的数据。
5. 我编写了一个继承自 ObservableCollection 的集合，用于处理查询和轮询。使用此集合的客户端代码提供查询数据的委托。日期以页为单位异步返回。我还没有确定页面大小。它不断重新查询页面，直到服务器返回小于最大页面大小的页面。该集合还提供有关如何确定集合中最新对象的最新日期的信息。它定期轮询是否有比集合中最新项目更新的更新。实际上，这个“最新日期”实际上是一个包含原始对象图各个部分的多个日期的对象。如果从服务器返回的项目存在于集合中，则集合中的项目将使用返回的数据进行更新。我这样做而不是插入新项目并删除旧项目，因为它适用于更多数据绑定的情况。

这种模式还可以改进。我只能将增量发送到 Silverlight 进行更改。我仍然可以尝试使用某种推送技术。但这个解决方案为我提供了一个 Web 服务调用，可以返回各种情况的数据。轮询也非常简单，只需一件事即可完成所有数据检索。没有很多活动部件。这通过相同的机制在初始数据加载期间和轮询期间处理对象状态更改。这似乎也可以很好地扩展。初始调用似乎是最昂贵的，后续调用运行得越来越快。我认为这是因为每次通过时保留在后端的数据变得越来越小。

对于我在此处发布的这一实施方式，我仍然有一个问题。

感谢您的所有建议。虽然我没有听取所有建议，但有几个想法要么直接帮助了我，要么让我思考如何实现这一目标的不同路径。