Database 如何在实体流经系统时存储与实体匹配的属性匹配规则对象？

我需要帮助找出一种存储（以及稍后检索/匹配）动态规则的好方法，这些规则可用于在对象流经工作流系统时匹配对象

在这个场景中，我正在构建一个系统，在对象最终准备好存储在另一个API中供以后使用之前，将对发布到该系统中的对象执行一系列步骤。这些步骤需要管理员进行配置；系统应该允许他们说“如果一个对象通过ABC属性，那么对它执行XYZ操作”。以下是系统流程的基本概念：

+-------+  +-----------+ +-----------+ +-----------+ +-----------+ +-------+
|       |  |           | |           | |           | |           | |       |
|       +--> Ruleset 1 +-> Ruleset 2 +-> Ruleset 3 +->   Object  +->       |
|       |  |           | |           | |           | |  Storage  | |       |
| Input |  +-----+-----+ +------+----+ +-----+-----+ +-----------+ | Final |
|  API  |        ^              ^            ^                     |  API  |
|       |  +-----+--------------+------------+-----+               |       |
|       |  |                 Rule                  |               |       |
|       |  |              Management               |               |       |
+-------+  +---------------------------------------+               +-------+

Entity 1 {
   type: "widget",
   category: "toys",
   manufacturer: "Acme",
   price: 5,
}

Entity 2 {
   type: "widget",
   category: "kitchen",
   manufacturer: "Acme",
   price: 6,
}

Entity 3 {
   type: "gadget",
   category: "tools",
   manufacturer: "XYZ Co",
   price: 10,
}

对象与配置规则的匹配需要基于属性（如下例所示）。也就是说，管理规则的人员需要能够提供一个或多个属性名称以及该属性的值，并且系统需要在具有该属性名称/值组合的对象通过该规则时运行该规则。此外，无论何时创建或编辑规则，我们都需要能够找到与新的/编辑的规则匹配的所有已持久化对象

例如，考虑以下规则已被配置：

Rule 1 {
   priority: 10,
   $match: {
      type: "gadget",
   },
   $set: {
      priceIncrease: 1.2,
   }
}

Rule 2 {
   priority: 10,
   $match: {
      type: "widget",
   },
   $set: {
      priceIncrease: 1.1,
   }
}

Rule 3 {
   priority: 100,
   $match: {
      type: "widget",
      category: "kitchen",
   },
   $set: {
      priceIncrease: 1.15,
   }
}

然后，以下三个实体通过系统：

+-------+  +-----------+ +-----------+ +-----------+ +-----------+ +-------+
|       |  |           | |           | |           | |           | |       |
|       +--> Ruleset 1 +-> Ruleset 2 +-> Ruleset 3 +->   Object  +->       |
|       |  |           | |           | |           | |  Storage  | |       |
| Input |  +-----+-----+ +------+----+ +-----+-----+ +-----------+ | Final |
|  API  |        ^              ^            ^                     |  API  |
|       |  +-----+--------------+------------+-----+               |       |
|       |  |                 Rule                  |               |       |
|       |  |              Management               |               |       |
+-------+  +---------------------------------------+               +-------+

Entity 1 {
   type: "widget",
   category: "toys",
   manufacturer: "Acme",
   price: 5,
}

Entity 2 {
   type: "widget",
   category: "kitchen",
   manufacturer: "Acme",
   price: 6,
}

Entity 3 {
   type: "gadget",
   category: "tools",
   manufacturer: "XYZ Co",
   price: 10,
}

当每个实体流经系统时，以下是匹配项：

实体一（一个玩具小部件）只匹配规则二，因为它是一个小部件

实体二（厨房小部件）匹配规则二和规则三，因为它是厨房小部件

实体三（工具小工具）与规则一匹配，因为它是小工具

我不太关心如何存储需要进行的实际操作-您可以忽略该部分；存储在数据存储区中的操作将绑定到知道在匹配规则后如何理解操作的数据结构的代码

主要关注点是：使用什么样的数据存储，使用什么样的数据模型来存储规则和实体，以便：

在实体通过系统时查找与实体匹配的规则，以及

在规则更改或添加到系统时，查找与规则匹配的实体（从已持久化的实体）

由于我们所做的一切都使用AWS，并尽可能多地使用无服务器，因此如果数据存储可以是AWS提供的托管服务，那将是一个巨大的好处。例如，是否存在用于执行此操作的现有模式：

• 关系数据库（Aurora）
• NoSQL键/值（DynamoDB/Redis）
• 图形数据库（海王星）

数据集不会很大，但也不会微不足道；数百万个实体将通过系统，并且将有数百条规则，因此这两种类型的操作都没有完整的表扫描

另外，对于如上所述的系统，正确的术语是什么？当然，已经有了这方面的设计模式/术语，但我正在努力找到正确的模式/术语

---

谢谢

你需要提供一个mcve:：@Kumar我不知道如何才能为这个提供mcve。这不是编码问题，而是设计问题。你能解释一下为什么你认为它需要一个MCVE，我会怎么做吗？另外，如果你否决了这个问题，你能重新考虑一下吗？