在SQL中发布/订阅模式

Question

背景:

我们有一个大的(1500万)物品表,全天频繁更新(平均每天300K变化).待处理的更改存储在临时表中,作业全天运行以从此表中读取更改,进行更新并将更改标记为已处理.

许多其他应用程序使用items表中的数据来执行各种任务.通常,这些任务是预定的和密集的,因为它们涉及将实时数据与旧快照进行比较,并相应地更新其他系统.例如,我们在易趣上列出项目,并将实时项目数据与我们现有的列表进行比较,看看我们是否需要插入任何新的易趣列表,删除我们已售出的商品,更新数量等.因为数据太大,大多数这些应用程序很少运行,大部分时间都会过时.

我的问题:

我们正在考虑使用Service Broker实现发布者/订阅者模式.目标是在项目更改时发布消息,其他各种系统(如我们的eBay应用程序)可以订阅.这将使我们能够更接近实时地进行更细粒度的更新,而不是涉及查询所有数据的大型且不频繁的更新,而不仅仅是更改的内容.但是,在使用Google之后,似乎这不是一个常见的数据库模式,而且会引发危险信号.这不是Service Broker的有效用法(尽管我在Pro/Sql Server 2008 Service Broker上发现了一小部分关于Pub/Sub)吗？这个问题通常如何解决？这似乎是一个普遍的问题.

TL; DR:

目标:当单个项目发生变化时,以动态,松散耦合的方式更新各种系统.

问题:使用Service Broker实现的发布/子样式解决方案是否可以在高容量设置中实现可行的解决方案？

Answer 1

这不是一种常见的数据库模式，因为大多数关系数据库都严重缺乏开箱即用的能力。如果 SQL Server 没有 Service Broker，它也会如此。

Service Broker 的一位开发人员谈论 Service Broker 如何应对大多数公司转向 NoSQL 解决方案的挑战。

据我了解，Service Broker 旨在完全满足您的需求。它甚至可以在数据发生变化时运行自定义应用External Activation程序。