1

我正在寻找构建用于存储/处理数据的后端的最有效方法。基本上，数据被发送到服务器，解析然后保存到数据库。然后根据数据库中的其他数据对其进行一些处理，然后通过电子邮件或短信发出警报。

平台是 .NET，数据库是 SQL Server 2005 或 2008。

IE

  1. 温度传感器向服务器发送 4 个字节的数据。
  2. 服务器将数据转换为实际值，例如 20。
  3. 然后将该值保存到 SQL 服务器数据库。
  4. 然后根据表中为该传感器设置边界的行检查该值，即 0-50
  5. 如果超出范围，则会发出警报。（通过短信或电子邮件发送。）

这一切看起来都非常简单，但我正在寻找最好的方法，因为理想的情况是这一切都“实时”发生，并且每秒可能有 100 或 1000 个请求。我想利用 SQL 2005/08 的一些“新”功能，例如我几乎没有经验的 Service Broker、CLR 集成、触发器等。

步骤 1 和 2 已经完成。

考虑到排队事务的数量，使用服务代理或 MSMQ 是否明智？鉴于我需要查找边界数据，我应该在什么时候处理警报数据？我有一些想法，我希望如何处理数据，但不确定要使用的最佳技术/方法。

我的想法是（从第 3 步开始）是将数据提交给服务代理，后者又调用 CLR 过程来处理数据上的“业务逻辑”。或者我是否使用触发器将数据添加到服务代理以处理数据？服务代理可以直接调用 CLR 过程吗？考虑到我想以更多的事件驱动而不是轮询来处理数据，使用服务代理是否是正确的想法？

从我在 Service Broker 上看到的示例来看，您似乎需要有代码来接收数据，而我真正想做的就是将数据添加到队列中并自动清空队列（将警报数据处理为它这样做）。

我可以通过标准存储过程来完成所有这些工作，但我想尽可能少地使用存储过程，而是使用 CLR 集成，因为业务逻辑将比示例中复杂得多。

鉴于服务代理处理排队和线程，我认为它可能是调用 CLR 过程来处理警报数据并发送短信或电子邮件的好选择？

请给我看光！谢谢！

4

3 回答 3

3

dportas 和 SPE109 提供了很好的建议，如果功能齐全的事件监控解决方案对您来说是可行的。

不过，我可以回答您提出的有关 Service Broker 的具体问题：

  • Service Broker 可以处理您指定的数据速率。Remus Rusanu 是 Microsoft Service Broker 背后的主要人员之一，他使用廉价的商品硬件实现了每秒远远超过 1000 个事件的消息吞吐量。
  • 无论您是使用批处理流程提交到 Service Broker 还是触发器，很大程度上取决于偏好以及它如何适合您的工作流程。任何一种方法都可以工作。
  • 如果您使用 Service Broker，则可以使用内部激活过程（标准 SQL 存储过程）或外部激活器（单独的过程）。我没有外部激活的经验，但是对于内部激活，您必须编写一个 SQL 过程，当消息进入给定队列时，Service Broker 将调用该过程。该过程可以调用 CLR 过程来对收到的消息数据执行操作。

一个更基本的问题是：Service Broker 为您提供的“标准”方法（将数据保存到数据库，然后每秒轮询一次并批处理传入的事件）没有提供什么？

当您需要消息持久性和排序时，当您在 SQL Server 实例之间进行通信时，或者当您可以利用它的机制为您完成大部分工作时，Service Broker 非常有用。在这种情况下，鉴于您的问题陈述，听起来持久性和排序并不特别重要。您希望密切关注数据并在违反边界条件时发出警报。除非对消息处理的顺序有依赖性，否则我认为轮询批处理可以更简单地完成工作，并且没有 Service Broker 的设置开销。

于 2011-06-30T12:46:00.633 回答
2

看看复杂事件处理解决方案领域。有来自 OsiSoft（PI 系统）、Streambase、Oracle 等的领先产品。Microsoft 拥有 Streaminsight，尽管这是第一代产品，并且不保证交付或支持持久性。

于 2011-06-30T09:40:12.623 回答
0

听起来您可能想看看 Streaminsight http://www.microsoft.com/sqlserver/2008/en/us/r2-complex-event.aspx。我不能说我对此了解太多，但如果你用谷歌搜索 Allan Mitchell 和 Streaminsight 或查看 SQLIS.com，他已经使用它制作了许多演示视频。

于 2011-06-30T09:29:50.570 回答