Sql 连续规则匹配模式

我有一个被分析的连续消息流。分析返回不同的变量，如作者、主题、情绪、字数和一组不同的单词。系统中的用户可以定义规则，当规则匹配时，将触发警报。规则应存储在sql数据库中。规则是来自消息分析的单个条件的结合，即

字数>15&&topic='StackOverflow'&&topic>2.0&&word set包含'great'

。每个允许的规则标准在消息分析结束时提供，之后将触发规则验证，并在Java中实现

---

每个消息都必须检查系统中所有用户定义的所有规则，这会占用大量计算能力（目前每秒有10多条消息，需要检查的规则将超过10.000条）。是否有一个共同的模式来加速匹配过程，也许这样可以并行地检查规则，除了逐个检查之外？在纯SQL中是否有可能做到这一点，不同类型规则的模式会是什么样子？

您考虑的可能不仅仅是匹配的吞吐量。例如，您需要维护规则

但是，让我们假设一组静态规则和消息，其中包含满足所有规则所需的所有字段。使用SQL，结构将以

消息

表开始。此表将有一个

insert

触发器。insert触发器将负责匹配规则。最好的方法是什么

由于每秒有10多条消息，即使每个匹配是单线程的，您的处理也将本质上是并行的。我不确定你需要付出多少努力才能使比赛并行化。数据库中的并行性通常来自SQL语句内部，而不是它们之间

有各种各样的解决办法。例如，您可以将规则编码为巨型存储过程中的代码。这将是一个需要维护的噩梦，可能会超过存储过程的长度限制，并且可能会非常缓慢

另一个疯狂的想法。将规则的匹配消息存储在表中，对于该规则，使用约束仅加载匹配的消息。然后，您的过程看起来像是一个无数的insert语句

更重要的是，您将进一步使用以下代码：

select *
from rules
where . . . 

结果集将具有匹配规则。

where

子句可能类似于：

select *
from rules r
where @wordcount > coalesce(r.wordcount, 0) and
      @topic = coalesce(r.topic, @topic) and
      . . .

也就是说，所有规则的所有可能比较都将出现在

where

子句中。此外，这些规则将经过预处理，以确定它们需要哪些条款

您甚至可以省去外部变量，直接访问查询：

select *
from rules r cross join inserted i
where i.wordcount > coalesce(r.wordcount, 0) and
      i.topic = coalesce(r.topic, @topic) and
      . . .

---

所以，是的，这在SQL中是可行的。而且，您可以并行地进行匹配。您只需要做一些工作，以使规则的格式适合于数据库比较。

我在C中解决了一个类似的问题，尽管没有使用SQL

为了便于移植，我将规则作为序列化XML存储在数据库中

在应用程序启动时，或者当规则表发生更改（强制刷新规则缓存）时，我从数据库加载所有规则，并将它们反序列化到相应的类中

然后，当数据进入每个应用服务器时，我对传入的数据执行规则，并为传递规则执行相应的操作。（当时我正在应用服务器上执行proc中的操作，但现在我会将其转储到队列中。）

---

这样做的好处是可以将计算分散到应用程序集群中，而不必在数据库机器上保持所有的吸吮周期。

SQL通常用于关系数据库。这个系统中的关系数据库在哪里？用户定义的规则存储在哪里？您看过事件流查询工具吗？我不确定是否有“保存”查询的机制，但也许您可以序列化它们或将用于生成查询的EQL存储在数据库中。听起来SQL只是一个错误的答案。@Thomas我不明白为什么你需要找出哪些规则是相关的。只需将规则检查并行化，并将每个分析与每个规则相匹配。如果规则匹配，则触发可能导致更复杂处理的事件。如果规则不匹配，就完成了。Storm似乎可以帮助您将数据并行化到各种流查询语言实例中，每一个类似Esper的实例都运行一部分规则。你只需要在系统关闭时序列化规则，并在启动时重新加载它们。因为我不熟悉Storm，而且我唯一使用的流查询工具是Esper，所以我确实找到了。由于Esper语句具有Java对象的表示形式，看起来您可以像任何其他对象一样序列化它们，并在实例之间移动它们，或在系统重新启动后重新加载它们。感谢这些建议，最大的问题是实际将规则适配为通用数据库格式，因为它们在本质上可能非常不同（不同的运算符、数值或比较集等）@Thomas…这就是顾问存在的原因。